Newsgroup: it.comp.os.linux.sys
Titolo: Problema con DNS

Ciao,
ho un singolare problema con un server DNS.
Da qualche giorno (1-2) non riesco a risolvere gli MX di 
libero.it
Se faccio un
dig +trace -t mx 
libero.it
arrivo correttamente a destinazione e vedo i server MX associati al
dominio, ma se faccio un
dix -t mx 
libero.it
ricevo un SERVFAIL da parte del mio server dns.
Che cosa potrei controllare ? Non ne ho idea, la problematica si
presenta solo su 
libero.it
; <<>> DiG 9.4.1 <<>> mx 
libero.it
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58621
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;
libero.it
.                     IN      MX
# dig mx 
libero.it
 +trace
; <<>> DiG 9.4.1 <<>> mx 
libero.it
 +trace
;; global options:  printcmd
.                       518372  IN      NS      
c.root-servers.net
.
.                       518372  IN      NS      
m.root-servers.net
.
.                       518372  IN      NS      
g.root-servers.net
.
.                       518372  IN      NS      
h.root-servers.net
.
.                       518372  IN      NS      
b.root-servers.net
.
.                       518372  IN      NS      
f.root-servers.net
.
.                       518372  IN      NS      
d.root-servers.net
.
.                       518372  IN      NS      
j.root-servers.net
.
.                       518372  IN      NS      
k.root-servers.net
.
.                       518372  IN      NS      
e.root-servers.net
.
.                       518372  IN      NS      
a.root-servers.net
.
.                       518372  IN      NS      
l.root-servers.net
.
.                       518372  IN      NS      
i.root-servers.net
.
;; Received 272 bytes from 127.0.0.1#53(127.0.0.1) in 4 ms
it.                     172800  IN      NS      
dns.nic.it
.
it.                     172800  IN      NS      
nameserver.cnr.it
.
it.                     172800  IN      NS      
r.dns.it
.
it.                     172800  IN      NS      
c.dns.it
.
it.                     172800  IN      NS      
m.dns.it
.
it.                     172800  IN      NS      
s.dns.it
.
;; Received 326 bytes from 192.33.4.12#53(
c.root-servers.net
) in 20 ms
libero.it
.              86400   IN      NS      
ns2.libero.it
.
libero.it
.              86400   IN      NS      
ns1.libero.it
.
;; Received 95 bytes from 194.119.192.34#53(
nameserver.cnr.it
) in 17
ms
libero.it
.              300     IN      MX      10
liberomx2.libero.it
.
libero.it
.              300     IN      MX      30
mxlibero3.libero.it
.
libero.it
.              300     IN      MX      10
liberomx1.libero.it
.
libero.it
.              86400   IN      NS      
ns1.libero.it
.
libero.it
.              86400   IN      NS      
ns2.libero.it
.
;; Received 429 bytes from 193.70.192.100#53(
ns2.libero.it
) in 10 ms

 Che cosa potrei controllare ?
I log?

 I log?
Non dicono nulla di utile, è la prima cosa che ho controllato.
Leggevo che per capire la causa di un SERVFAIL bisogna attivare la
categoria query-errors nei log, cosa
che però non posso fare perchè la mia versione di bind è obsoleta e
*NON* posso aggiornarla a causa DLZ che
rompe i maroni. Quando ho aggiornato l'ultima volta ho bestemmiato in
svariate lingue per poi dover fare il
downgrade.
Per ora ho risolto impostando, in resolv.conf, un dns di google prima
del mio, in questo modo il mio nameserver
risponde alle query interrogando quello di google senza fare di testa
sua.
La cosa strana è che il trace funziona, mentre l'interrogazione
tradizionale no. Cosa cambia da un trace ad una
interrogazione standard?
Vorrei però capire cosa ha causato la problematica, visto che non
tocco quel server da molti mesi e lo stesso
identico problema si è presentato anche sul secondario.
L'upgrade di bind non è una soluzione, domani metto in piedi un
PowerDNS, con il quale mi trovo più a mio agio ma
devo capire cosa diavolo è successo al server, non mi va di
sostituirlo senza aver capito il problema.

 interrogazione standard?
Il trace eseguito dal server?
Continua a non risolvere anche dopo aver flushato la cache per 
libero.it
?
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Continua a non risolvere anche dopo aver flushato la cache per 
libero.it
?
Non risolve in alcun modo.
Devo inserire dei nameserver esterni in resolv.conf
Sembra che il nic non spari fuori i glue-records per 
libero.it
 (cosa
non vera)
e che quindi il mio server non sappia come risolvere 
ns1.libero.it
 per
continuare
l'interrogazione.
Però, interrogando direttamente i nameserver del nic, i glue-records
ci sono
ed interrogandoli manualmente, risolvono con successo.
Guarda (lavorando sul mio secondario):
it.			172800	IN	NS	
c.dns.it
.
it.			172800	IN	NS	
m.dns.it
.
it.			172800	IN	NS	
r.dns.it
.
it.			172800	IN	NS	
s.dns.it
.
it.			172800	IN	NS	
dns.nic.it
.
it.			172800	IN	NS	
nameserver.cnr.it
.
;; Received 328 bytes from 199.7.83.42#53(
l.root-servers.net
) in 69 ms
libero.it
.		86400	IN	NS	
ns2.libero.it
.
libero.it
.		86400	IN	NS	
ns1.libero.it
.
;; Received 95 bytes from 193.206.141.46#53(
r.dns.it
) in 18 ms
dig: couldn't get address for '
ns1.libero.it
': failure
Però:
# dig @
r.dns.it
 
libero.it
; <<>> DiG 9.6.0-P1 <<>> @
r.dns.it
 
libero.it
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5284
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;
libero.it
.			IN	A
;; AUTHORITY SECTION:
libero.it
.		86400	IN	NS	
ns1.libero.it
.
libero.it
.		86400	IN	NS	
ns2.libero.it
.
;; ADDITIONAL SECTION:
ns1.libero.it
.		86400	IN	A	195.210.91.100
ns2.libero.it
.		86400	IN	A	193.70.192.100
;; Query time: 18 msec
;; SERVER: 193.206.141.46#53(193.206.141.46)
;; WHEN: Sun Jan  2 22:23:16 2011
;; MSG SIZE  rcvd: 95
e quindi:
# dig @
195.210.91.100
 
libero.it
; <<>> DiG 9.6.0-P1 <<>> @
195.210.91.100
 
libero.it
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51395
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;
libero.it
.			IN	A
;; ANSWER SECTION:
libero.it
.		86400	IN	A	195.210.91.83
;; AUTHORITY SECTION:
libero.it
.		86400	IN	NS	
ns1.libero.it
.
libero.it
.		86400	IN	NS	
ns2.libero.it
.
;; ADDITIONAL SECTION:
ns1.libero.it
.		86400	IN	A	195.210.91.100
ns2.libero.it
.		86400	IN	A	193.70.192.100
;; Query time: 11 msec
;; SERVER: 195.210.91.100#53(195.210.91.100)
;; WHEN: Sun Jan  2 22:24:46 2011
;; MSG SIZE  rcvd: 111
Che sia questo (che ho notato solo ora):
";WARNING: recursion requested but not available" ?

 ";WARNING: recursion requested but not available" ?
No. Deriva solamente dal fatto che stai eseguendo una query ricorsiva
verso un server autoritativo che ha recursion disabilitata (come
dovrebbe essere anche il tuo, in altre parole).
Vedi opzione +norec di dig...


 interrogazione standard?
Uhm...
Dal man di dig:
+[no]recurse
           Toggle the setting of the RD (recursion desired) bit in the 	
	   query.
           This bit is set by default, which means dig normally sends
           recursive queries. Recursion is automatically disabled when the
           +nssearch or +trace query options are used.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_____________________________________________________________________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/
 
http://www.worldcommunitygrid.org/index.jsp
 
http://boinc.berkeley.edu/projects.php

 dovrebbe essere anche il tuo, in altre parole).
Quindi quale potrebbe essere il problema?

 Continua a non risolvere anche dopo aver flushato la cache per 
libero.it
?
Altri domini, come ad esempio 
ansa.it
 vengono risolti correttamente.
libero.it
, 
alice.it
 invece danno SERVFAIL.
Ho anche riavviato fisicamente il server, quindi non è un problema di
cache.
Proprio non ne vengo a capo, sarebbe interessante debuggare i
servfail, cosa
che però non posso fare perchè dovrei aggiornare bind.

 che però non posso fare perchè dovrei aggiornare bind.
Esistono anche gli sniffer, però...
Non ti darà visione degli "internals" di bind (e peraltro non ci hai
ancora nemmeno detto che versione esegui) ma almeno ti dà qualche
indicazione su cosa avviene durante la risoluzione fallita...
Di problemi con DNS ne puoi avere una infinità con ragioni del tutto
diverse. Senza che tu fornisca dati è del tutto impossibile indovinare a
scatola chiusa quale è il tuo problema.
Per 
libero.it
 in particolare, ad esempio, una risoluzione per gli MX
sfora gli storici 512 byte:
; <<>> DiG 9.6-ESV-R3 <<>> +bufsize=4096 mx 
libero.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29243
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 40
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;
libero.it
.                     IN      MX
;; ANSWER SECTION:
libero.it
.              126     IN      MX      10 
liberomx1.libero.it
.
libero.it
.              126     IN      MX      10 
liberomx2.libero.it
.
libero.it
.              126     IN      MX      30 
mxlibero3.libero.it
.
;; AUTHORITY SECTION:
libero.it
.              85956   IN      NS      
ns2.libero.it
.
libero.it
.              85956   IN      NS      
ns1.libero.it
.
;; ADDITIONAL SECTION:
liberomx1.libero.it
.    126     IN      A       212.52.84.177
liberomx1.libero.it
.    126     IN      A       212.52.84.178
liberomx1.libero.it
.    126     IN      A       212.52.84.179
liberomx1.libero.it
.    126     IN      A       212.52.84.180
liberomx1.libero.it
.    126     IN      A       212.52.84.181
liberomx1.libero.it
.    126     IN      A       212.52.84.182
liberomx1.libero.it
.    126     IN      A       212.52.84.183
liberomx1.libero.it
.    126     IN      A       212.52.84.184
liberomx1.libero.it
.    126     IN      A       212.52.84.185
liberomx1.libero.it
.    126     IN      A       212.52.84.190
liberomx1.libero.it
.    126     IN      A       212.52.84.191
liberomx1.libero.it
.    126     IN      A       212.52.84.170
liberomx1.libero.it
.    126     IN      A       212.52.84.171
liberomx1.libero.it
.    126     IN      A       212.52.84.172
liberomx1.libero.it
.    126     IN      A       212.52.84.173
liberomx1.libero.it
.    126     IN      A       212.52.84.174
liberomx1.libero.it
.    126     IN      A       212.52.84.175
liberomx1.libero.it
.    126     IN      A       212.52.84.176
liberomx2.libero.it
.    126     IN      A       212.52.84.176
liberomx2.libero.it
.    126     IN      A       212.52.84.177
liberomx2.libero.it
.    126     IN      A       212.52.84.178
liberomx2.libero.it
.    126     IN      A       212.52.84.179
liberomx2.libero.it
.    126     IN      A       212.52.84.180
liberomx2.libero.it
.    126     IN      A       212.52.84.181
liberomx2.libero.it
.    126     IN      A       212.52.84.182
liberomx2.libero.it
.    126     IN      A       212.52.84.183
liberomx2.libero.it
.    126     IN      A       212.52.84.184
liberomx2.libero.it
.    126     IN      A       212.52.84.185
liberomx2.libero.it
.    126     IN      A       212.52.84.190
liberomx2.libero.it
.    126     IN      A       212.52.84.191
liberomx2.libero.it
.    126     IN      A       212.52.84.170
liberomx2.libero.it
.    126     IN      A       212.52.84.171
liberomx2.libero.it
.    126     IN      A       212.52.84.172
liberomx2.libero.it
.    126     IN      A       212.52.84.173
liberomx2.libero.it
.    126     IN      A       212.52.84.174
liberomx2.libero.it
.    126     IN      A       212.52.84.175
mxlibero3.libero.it
.    126     IN      A       212.52.84.164
mxlibero3.libero.it
.    126     IN      A       212.52.84.165
ns1.libero.it
.          47185   IN      A       195.210.91.100
;; Query time: 2 msec
;; SERVER: 147.123.1.3#53(147.123.1.3)
;; WHEN: Mon Jan  3 09:40:39 2011
;; MSG SIZE  rcvd: 776
Ergo, se hai una versione di bind che usa EDNS0 di default e c'è
qualcosa che sega i datagrammi udp per la porta 53 con size >512, il tuo
nameserver non risolve.
Le versioni più recenti di bind in caso di timeout di risoluzione con
EDNS0 provvedono a ridurre il buffer size annunciato per la specifica
risoluzione a 512 byte, in modo da bypassare eventuali firewall/router
scrausi che seghino quei pacchetti; ma magari la tua versione di Bind
non lo fa. Di nuovo: senza dettagli di alcun tipo, l'unica è la sfera di
cristallo, e quella in edizione 2011 mi deve ancora arrivare.
Datti comunque una letta a
http://bofhskull.wordpress.com/2009/12/11/preoccupazioni-da-radici-firmate/
Le ragioni per cui lo scrissi erano abbastanza diverse (ma neanche
tanto) ma c'è comunque un riassunto molto stringato degli errori di
network (e non solo) più comuni che portano a problemi di risoluzione.


 
libero.it
, 
alice.it
 invece danno SERVFAIL.
La cosa è alquanto strana.
Se interrogo manualmente uno dei nameserver del nic, riesco a ottenere
l'elenco dei nameserver per 
libero.it
 ed i rispettivi glue-records:
# dig @
nameserver.cnr.it
 
ns2.libero.it
; <<>> DiG 9.6.0-P1 <<>> @
nameserver.cnr.it
 
ns2.libero.it
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16307
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;
ns2.libero.it
.			IN	A
;; AUTHORITY SECTION:
libero.it
.		86400	IN	NS	
ns1.libero.it
.
libero.it
.		86400	IN	NS	
ns2.libero.it
.
;; ADDITIONAL SECTION:
ns2.libero.it
.		86400	IN	A	193.70.192.100
ns1.libero.it
.		86400	IN	A	195.210.91.100
;; Query time: 17 msec
;; SERVER: 194.119.192.34#53(194.119.192.34)
;; WHEN: Mon Jan  3 09:43:57 2011
;; MSG SIZE  rcvd: 95
Che dovrebbe essere questi:
ns2.libero.it
.		86400	IN	A	193.70.192.100
ns1.libero.it
.		86400	IN	A	195.210.91.100
Se li interrogo manualmente, dallo stesso server che mi da problemi,
risolve:
# dig @
195.210.91.100
 -t a 
www.libero.it
 +short
vs-fe.iol.it
.
195.210.91.83
# dig @
193.70.192.100
 -t a 
www.libero.it
 +short
vs-fe.iol.it
.
195.210.91.83
Cosa simile, ma non uguale, con alice:
# dig +short 
www.alice.it
nessun risultato ma un bel SERFAIL
Facendo il trace però, vedo la risposta:
# dig +trace 
www.alice.it
 @localhost
; <<>> DiG 9.6.0-P1 <<>> +trace 
www.alice.it
 @localhost
;; global options: +cmd
.			26999	IN	NS	
d.root-servers.net
.
.			26999	IN	NS	
b.root-servers.net
.
.			26999	IN	NS	
e.root-servers.net
.
.			26999	IN	NS	
l.root-servers.net
.
.			26999	IN	NS	
j.root-servers.net
.
.			26999	IN	NS	
m.root-servers.net
.
.			26999	IN	NS	
h.root-servers.net
.
.			26999	IN	NS	
a.root-servers.net
.
.			26999	IN	NS	
i.root-servers.net
.
.			26999	IN	NS	
g.root-servers.net
.
.			26999	IN	NS	
f.root-servers.net
.
.			26999	IN	NS	
k.root-servers.net
.
.			26999	IN	NS	
c.root-servers.net
.
;; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 6 ms
it.			172800	IN	NS	
c.dns.it
.
it.			172800	IN	NS	
m.dns.it
.
it.			172800	IN	NS	
r.dns.it
.
it.			172800	IN	NS	
s.dns.it
.
it.			172800	IN	NS	
dns.nic.it
.
it.			172800	IN	NS	
nameserver.cnr.it
.
;; Received 331 bytes from 199.7.83.42#53(
l.root-servers.net
) in 68 ms
alice.it
.		86400	IN	NS	
dns3.interbusiness.it
.
alice.it
.		86400	IN	NS	
dns4.interbusiness.it
.
;; Received 82 bytes from 194.119.192.34#53(
nameserver.cnr.it
) in 17
ms
www.alice.it
.		300	IN	A	212.48.10.154
alice.it
.		3600	IN	NS	
dns3.interbusiness.it
.
alice.it
.		3600	IN	NS	
dns4.interbusiness.it
.
;; Received 98 bytes from 80.22.52.130#53(
dns4.interbusiness.it
) in 9
ms
Eccola li:
www.alice.it
.		300	IN	A	212.48.10.154
Ma io ricevo sempre un servfail se provo a fare una interrogazione
tradizionale eppure i server di libero funzionano e la risposta di
Alice è presente.

 network (e non solo) più comuni che portano a problemi di risoluzione.
L'avevo letto a suo tempo, ma mi ero dimenticato di questo tuo post.
Ora vado a leggere di nuovo.
P.S: 
alice.it
 dovrebbe avere una risposta inferiore a 512byte, quindi 
escludo sia quello il problema, visto che mi si presenta anche con alice.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 cristallo, e quella in edizione 2011 mi deve ancora arrivare.
Non dovrei essere soggetto al problema:
# dig +short 
rs.dns-oarc.net
 txt
rst.x3827.rs.dns-oarc.net
.
rst.x3837.x3827.rs.dns-oarc.net
.
rst.x3843.x3837.x3827.rs.dns-oarc.net
.
"Tested at 2011-01-03 10:21:52 UTC"
"xx.xx.xx.xx sent EDNS buffer size 4096"
"xx.xx.xx.xx DNS reply size limit is at least 3843"


 escludo sia quello il problema, visto che mi si presenta anche con alice.
Plausibile, ma senza altri dati quella caratteristica di 
libero.it
 è la
prima cosa che salta all'occhio.


 "xx.xx.xx.xx DNS reply size limit is at least 3843"
Ni.
Con questo test puoi dire che non sei soggetto al problema per i tuoi
namserver *e* per la tratta di routing che va da te al DNS di test di OARC.
Nulla ti dice per la tratta verso i nameserver di Libero... ;-)


 prima cosa che salta all'occhio.
Capisco perfettamente, ma non ho la più pallida idea di quali altri dati
possa fornire. Il problema si è presentato da solo il 31 dicembre, senza
che nessuno facesse alcuna variazione al routing della nostra rete e/o
toccasse le configurazioni dei server.
Il 31 eravamo chiusi, nessuno lavorava.


 Il 31 eravamo chiusi, nessuno lavorava.
*Tu* OK. Ma a meno che tu non sia direttamente collegato a libero/wind
(e/o non sia presente al MIX o altro IXP ove fai peering con Wind), in
mezzo ci sono anche dei router nè tuoi nè di Wind...


 mezzo ci sono anche dei router nè tuoi nè di Wind...
Ecco, proprio qui volevo arrivare.
Quindi anche qualche birbante in mezzo alla tratta tra me ed i ns
di libero potrebbe aver cambiato qualche impostazione e rompere le
mie risoluzioni...
(Problema risolto: *MAI* avere come resolver lo stesso server che è
anche autoritativo per i propri domini. *MAI*. Ed ho detto tutto)


 anche autoritativo per i propri domini. *MAI*. Ed ho detto tutto)
Amen


 un modo o nell'altro) oppure sei una mina vagante, per te e per gli altri.
No, io non voglio fare un open resolver.
Il mio è 'pubblico' nel senso che può essere usato fuori dalla mia rete,
ma solo dopo aver aperto i filtri. Lo usano molti miei clienti, quasi
tutti i nostri firewall dislocati nelle varie reti, io da casa, e così 
via, ma, a differenza di quello attuale che per i motivi già citati non
posso modificare se non abbattendolo, il nuovo avrà un filtro a livello IP.


 
http://bofhskull.wordpress.com/2009/12/11/preoccupazioni-da-radici-
firmate/
Ma che bei miciotti! :)
Mi spiace tanto per il primo. :(


 posso modificare se non abbattendolo, il nuovo avrà un filtro a livello IP.
Mi sfugge cosa ti impedisca di farlo anche sull'attuale, quanto a quello.
la direttiva allow-recursion è lì apposta...


 Mi spiace tanto per il primo. :(
Povero Randi... :'(


 interrogando quello di google senza fare di testa sua.
Occhio che molte RBL, spamhaus in primis, non funzionano (NXDOMAIN di 
default)
Max

 la direttiva allow-recursion è lì apposta...
Non ho idea di chi stia usando il server.
Come ho scritto prima, entro breve lo seghiamo.
Chi lo usa, ci chiama (anche per forza, visto che non
navigherebbe più), e lo dirottiamo nel nuovo.
L'attuale nameserver è in piedi, non scherzo, da almeno
10 anni buoni. Nel limite del possibile, quando l'ho preso
in gestione, ho fatto solo qualche upgrade prima di schiantarmi
contro DLZ


 default)
Perchè non dovrebbe funzionare?
Al momento non mi risultano anomalie...


 Perchè non dovrebbe funzionare?
Sopra un TOT di query/die per usare spamhaus la gente paga.
Se i DNS di google fossero autorizzati a effettuare query sui mirror di
Spamhaus, in quanti pagherebbero, secondo te?


 Spamhaus, in quanti pagherebbero, secondo te?
A ok, ora ci sono.
Stavo giusto provando unbound, ma non mi è chiaro come loggare la
query fatte, cosa per me fondamentale, hai qualche idea? Stando alla
documentazione, basta mettere il verbose a 3, ma non viene loggata
nessuna query.
Mentre invece, per quanto riguarda EDNS, il non supportarlo mi pare
possa impattare sulla risoluzione di domini
con risposte superiori a 512bytes, dico bene? Visto che PowerDNS in
lenny non supporta EDNS, meglio lasciar perdere?
Stando al tuo blog, sembra di si, visto che suggerisci di usare un
resolver differente.

 resolver differente.
Se non c'è supporto a EDNS0, si fa alla vecchia maniera: si riceve una
risposta tronca e si ri-effettua la query via TCP.
Per ottenere gli stessi dati la latenza della risoluzione triplica, il
carico massimo (in query/sec) gestibili dal resolver si abbassa
drasticamente, ecc.
Ci sono anche effetti collaterali secondari dovuti ai meccanismi di
distribuzione del carico usata dal protocollo DNS, ma è roba -appunto-
secondaria e con scarso impatto operativo (di norma, almeno).
Certo è che oggi come oggi che...
- la root è firmata DNSSEC e "pesa" già da sola 2K:
zarathustra:~ skull$ dig +bufsize=4096 any . @
k.root-servers.net
 | tail -5
;; Query time: 12 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Mon Jan  3 14:40:06 2011
;; MSG SIZE  rcvd: 2081
- i principali TLD sono già firmati, con il "peso aggiuntivo" che ne
consegue:
zarathustra:~ skull$ dig +dnssec +bufsize=4096 any org.
@
a0.org.afilias-nst.info
 | tail -5
;; Query time: 126 msec
;; SERVER: 199.19.56.1#53(199.19.56.1)
;; WHEN: Mon Jan  3 14:42:20 2011
;; MSG SIZE  rcvd: 2110
...partire con una nuova implementazione di resolver a livello ISP
scegliendo strumenti privi di supporto a DNSSEC e EDNS0 mi pare un po'
suicida...
(poi ognuno si fa male come gli pare, eh...)


 suicida...
Concordo con te, infatti sto testando unbound.
Ma la versione pacchettizzata debian mi pare abbastanza arretrata e non
supporta l'auto-trust-anchor-file necessario per attivare dnssec.
Se ho ben capito, basta salvarsi la chiave della root zone e darla in
pasto a unbound con quella direttiva. Non funziona, ma non avendo mai
usato unbound prima d'ora, sicuramente ho fatto qualche cappella.
Uhm, mi sa che devo tornare a bind, nonostante non mi piaccia, ho
più confidenza con lui che con unbound.


 più confidenza con lui che con unbound.
Bind è certamente molto più flessibile (dato che ha sia il ruolo di
unbound che di nsd).
Ma non dovrebbe stupire che unbound abbia prestazioni notevolmente
migliori e un footprint estremamente più esiguo.


 migliori e un footprint estremamente più esiguo.
Avrà anche prestazioni migliori, ma è più facile configurare bind
di unbound, il che è tutto dire.
Un vero peccato che PowerDNS non supporti ne dnssec ne edns0.
A quanto pare non è molto adatto come resolver nel 2011, mentre
invece come autoritario fa il suo sporco lavoro senza problemi.


 invece come autoritario fa il suo sporco lavoro senza problemi.
Anche questo solamente finchè ti sta bene di perdere il treno DNSSEC
quando parte (davvero) e star sulla banchina a guardare...


 quando parte (davvero) e star sulla banchina a guardare...
Dici per adottare dnssec anche nei nameserver autoritari?


 Dici per adottare dnssec anche nei nameserver autoritari?
Yep.


 unbound (aka: non ci sian problemi di permessi).
E' questo il problema.
unbound su debian non accetta 'auto-trust-anchor-file' ed usando
'trust-anchor-file' (o qualunque sia la direttiva) unbound parte
ma non attiva il dnssec
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 quando parte (davvero) e star sulla banchina a guardare...
Che poi PowerDNS supporta i record RRSIG già dalla versione
nei repo debian, ma non mi pare sia in grado di firmarli al volo.
Il che significa, da quel che ho capito, che bisogna firmarli
manualmente e poi inserire la risultante in un record di nome RRSIG
Improponibile.
