Newsgroup: it.comp.os.linux.sys
Titolo: Chiarimento su record NS

Ho notato che ï¿œ possibile impostare un record NS
avente host differente dalla canonica "@".
Che senso puï¿œ avere?
Posso delegare la gestione DNS di un terzo livello
ad un ns esterno?
Esempio:
pippo.pluto.it
 NS 1.2.3.4
che senso puï¿œ avere?
Ho sempre usato solo "
pluto.it
" NS 1.2.3.4
Aggiungo una seconda domanda:
anche impostando "
pluto.it
 NS 1.2.3.4" il record
NS non viene seguito, ovvero chi risolve continuerï¿œ
a farlo tramite il mio dns, incurante della "delega".
E' normale?

 della "delega". E' normale?
dovresti usare qualcosa del tipo
pluto.it
. IN NS 
ns1.pluto.it
.
ns1 IN A 1.2.3.4
(oppure
@ IN NS ns1
ns1 IN A 1.2.3.4
)
ciao,
stefano

 ns1 IN A 1.2.3.4
Ho provato proprio come dici, ma non ha
funzionato.
Mi spiego:
i dns authoritativi del dominio, ovvvero quelli indicati
in fase di registrazione, puntano a me.
Io però non voglio gestire gli host ed ho creato una zona
(ho tutto su mysql) contenente solo il SOA ed un NS che punta
a 1.2.3.4
@ SOA ...
@ IN NS 1.2.3.4
Sul server 1.2.3.4 ho creato la zona corretta, contenente
tutti i record corretti, ma se provo a fare un banale ping
i record non vengono risolti. Se invece li creo sul mio dns
tutto funziona. In pratica l'interrogazione non segue i
record NS indicati nella mia zona ma cerca di risolvere
direttamente tramite i miei server.

 E' normale?
Maieutica: chi sta risolvendo vuole risolvere "
pluto.it
", e per farlo 
deve interrogare i DNS (ovvero i record NS) che hanno le informazioni 
per quel dominio.
Di certo non li puï¿œ domandare ai DNS autoritativi (o autorevoli per chi 
preferisce) per il dominio, dato che non sa ancora chi siano.
A chi li domanda?
-- 
http://bofhskull.wordpress.com/

 in fase di registrazione, puntano a me.
E allora *tu* devi fornire le informazioni su 
pluto.it
.
Puoi delegarne una parte, ma non tutta la zona, altrimenti cambi i 
record di delega e fine.....
-- 
http://bofhskull.wordpress.com/

 A chi li domanda?
Ti rispondo di la.

 record di delega e fine.....
Dunque,
supponiamo di avere "
pippo.it
".
Gli autoritari per il dominio puntano a me, per cui le richieste
arrivano la mio server.
pippo.it
 SOA...
@ IN NS 
ns1.cliente.com
@ IN NS 
ns2.cliente.com
così non può funzionare, perchè avrei delegato tutta la zona, giusto?
Mentre invece
pippo.it
 SOA
tizio IN NS 
ns1.cliente.com
tizio IN NS 
ns2.cliente.com
Così invece ho delegato solo tizio al cliente.
Per cui chi cerca di risolvere tizio, prima interroga il .IT per cercare
pippo.it
, poi interroga me per cercare 
tizio.pippo.it
 e vedendo che c'è
un NS che punta a 
ns1.cliente.com
 interroga quel dns per vedere i
record associati a 
tizio.pippo.it
, compreso eventuali record A associati
a "
tizio.pippo.it
".
Giusto?

 
tizio.pippo.pluto.it
.
yes
in ogni caso, a long time ago avevo scritto questo:
http://stefano.dscnet.org/a/delega_di_un_sottodominio_con_bind
forse può darti una mano nella configurazione.
ciao,
stefano

 Giusto?
Giusto.
Ricordati solo i punti alla fine dei record assoluti ;-)
-- 
http://bofhskull.wordpress.com/

 Ricordati solo i punti alla fine dei record assoluti ;-)
Son stati volutamente omessi, il codice postato non ha pretesa di essere
funzionante, è solo per far capire di cosa sto parlando.

 Questo non mi è proprio chiaro.
Perchè le deleghe funzionano così, nulla di più e nulla di meno ;-)
Se poi vogliamo scendere in dettagli, posso dirti che se levi i record 
NS dalla zona figlio la risoluzione dei record A ivi contenuti funziona 
-di solito- ugualmente.
Ma è una cosa che a quel punto dipende dall'implementazione lato resolver.
Se effettui la risoluzione di un record NS, ad esempio (e di questo, 
alla fine, si tratta), ottieni comportamenti diversi tra le 
implementazioni di bind8 e bind9: bind8 ritorna i record NS presi dalla 
zona padre, mentre bind9 li prende dalla zona figlio[1].
Dato che in una configurazione corretta i due dovrebbero coincidere, 
usare gli uni o gli altri non dovrebbe fare grande differenza.
[1] questa particolarità, poi, è usata da parecchi spammer per i loro 
domini: se non riportano record NS nella zona figlio ma solo nella zona 
padre, i record A dove appoggiano le loro attività risolvono ugualmente, 
ma i check da parte dei software antispam che si basano sui record NS 
del dominio falliscono in quanto il resolver non ne ritorna alcuno, dato 
che li prende dalla zona figlio.
-- 
http://bofhskull.wordpress.com/

 -di solito- ugualmente.
Quindi:
sul nic registro 
pippo.it
 ed imposto i NS come 
ns1.ciccio.it
nella zona di 
pippo.it
 imposto i NS come 
ns1.ciccio.it
Bind9, se ho ben capito, riporta i dati in base ai dns figli, in questo
caso quelli presi dalla mia zona pippo.
Bind8, invece, interrogherebbe solo i dns indicati al nic, ovvero quelli
autoritari.
Se i dati corrispondono, nessun problema, ma se per assurdo mettessi
ns1.pluto.it
 come NS nella mia zona 
pippo.it
, bind9 dovrebbe risolvere
tramite 
ns1.pluto.it
 mentre bind8 tramite 
ns1.ciccio.it
.
Giusto?
Eppure, io ho provato a "svuotare" una zona di un dominio e ad impostare
i NS in maniera differente da quelli presenti al nic e non ha funzionato
niente. I dns da me impostati non sono mai stati interrogati.

 autoritari.
Limitatamente alle interrogazioni di tipo *NS*. Bind8 prende buoni i 
dati (sia i record NS che i rispettivi A) presenti nella 
delega/glue_record, mentre bind9 fa un passo in più e va a prenderli nel 
nameserver autoritativo.
-- 
http://bofhskull.wordpress.com/

 nameserver autoritativo.
Eppure, con bind9, non son riuscito a cambiare i record NS di un
dominio, continuava a ricercare i record sul mio server, come se
leggesse esclusivamente i nameserver dalla delega.
Ecco il perchè della mia domanda.....


E io ho appositamente specificato "Limitatamente alle interrogazioni di 
tipo *NS*" mica per niente...
Prendiamo un dominio che usa il trucchetto che dicevo:
zarathustra:~ skull$ dig ns 
tnizexeb.cn
; <<>> DiG 9.3.6-APPLE-P2 <<>> ns 
tnizexeb.cn
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16651
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;
tnizexeb.cn
.                   IN      NS
Nessun record NS?!?
Eppure:
zarathustra:~ skull$ ping 
www.tnizexeb.cn
PING 
www.tnizexeb.cn
 (222.186.12.38): 56 data bytes
64 bytes from 
222.186.12.38
: icmp_seq=0 ttl=51 time=464.517 ms
64 bytes from 
222.186.12.38
: icmp_seq=1 ttl=51 time=433.156 ms
Chi è il record www?
zarathustra:~ skull$ dig a 
www.tnizexeb.cn
; <<>> DiG 9.3.6-APPLE-P2 <<>> a 
www.tnizexeb.cn
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32209
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;
www.tnizexeb.cn
.               IN      A
;; ANSWER SECTION:
www.tnizexeb.cn
.        3600    IN      A       222.186.12.38
;; AUTHORITY SECTION:
tnizexeb.cn
.            19705   IN      NS      
ns4.6sf.ru
.
tnizexeb.cn
.            19705   IN      NS      
ns1.heavpass.com
.
tnizexeb.cn
.            19705   IN      NS      
ns2.heavpass.com
.
tnizexeb.cn
.            19705   IN      NS      
ns3.6sf.ru
.
;; ADDITIONAL SECTION:
ns1.heavpass.com
.       170886  IN      A       222.186.12.38
ns2.heavpass.com
.       170886  IN      A       218.93.205.44
ns3.6sf.ru
.             1686    IN      A       222.186.12.38
ns4.6sf.ru
.             1686    IN      A       222.186.12.38
Notasi la sezione "AUTHORITY", che fornisce dei record NS. Da dove li 
piglia?
Tracciamo:
zarathustra:~ skull$ dig ns 
tnizexeb.cn
 +trace
; <<>> DiG 9.3.6-APPLE-P2 <<>> ns 
tnizexeb.cn
 +trace
;; global options:  printcmd
.                       327028  IN      NS      
A.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
B.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
C.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
D.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
E.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
F.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
G.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
H.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
I.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
J.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
K.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
L.ROOT-SERVERS.NET
.
.                       327028  IN      NS      
M.ROOT-SERVERS.NET
.
;; Received 500 bytes from 147.123.1.2#53(147.123.1.2) in 14 ms
cn.                     172800  IN      NS      
A.DNS.cn
.
cn.                     172800  IN      NS      
B.DNS.cn
.
cn.                     172800  IN      NS      
C.DNS.cn
.
cn.                     172800  IN      NS      
D.DNS.cn
.
cn.                     172800  IN      NS      
NS.CERNET.NET
.
cn.                     172800  IN      NS      
E.DNS.cn
.
;; Received 292 bytes from 198.41.0.4#53(
A.ROOT-SERVERS.NET
) in 172 ms
tnizexeb.cn
.            21600   IN      NS      
ns3.6sf.ru
.
tnizexeb.cn
.            21600   IN      NS      
ns4.6sf.ru
.
tnizexeb.cn
.            21600   IN      NS      
ns1.heavpass.com
.
tnizexeb.cn
.            21600   IN      NS      
ns2.heavpass.com
.
;; Received 119 bytes from 203.119.25.1#53(
A.DNS.cn
) in 297 ms
.                       3600    IN      SOA     . root.local. 2009020411 
10800 3600 3600000 3600
;; Received 73 bytes from 222.186.12.38#53(
ns3.6sf.ru
) in 472 ms
Quindi: la delega viene seguita e tutte le interrogazioni vanno a finire 
sui DNS autoritativi indicati dal ccTLD, ma se domando chi è il record 
NS bind9 lo domanda alla zona figlia, che non ha alcun record NS.
Prova a fare la stessa interrogazione del punto 1 verso un bind8, e ti 
ritornerà i record NS elencati nella delega (ora però non ne ho uno 
sottomano...)
-- 
http://bofhskull.wordpress.com/

 NS bind9 lo domanda alla zona figlia, che non ha alcun record NS.
Ok, per cui io potrei avere anche una zona senza record NS pubblicati.
In tal caso, bind9, alle interrogazioni di tipo NS risponderebbe con il
nulla perchè cercherebbe i record NS dalla zona figlia, mentre invece
con altre interrogazioni (ad esempio il record A associato al www)
risolverebbe correttamente perchè utilizzerebbe i record autoritari
indicati nel ggTLD.
Allora ritorniamo punto a capo: se, interrogazioni NS a parte, i record
sarebbero risolti comunque usando i nameserver indicati nei ggTLD, a che
mi serve inserire i record NS nella zona? Tanto non vengono usati, dato
che i record vengono risolti in base ai dati indicati nel ggtld e non in
base ai ns indicati nel record stesso....

 base ai ns indicati nel record stesso....
La delega, per definizione, è l'atto con cui una entità rilascia 
autorità e un'altra entità la prende.
Teoria vuole che chi due concordino su cosa è delegato a chi, null'altro.
Che poi "funziona lo stesso, chissenefrega" è un discorso che preferirei 
non sentire, di norma... ;-)
Qualche tempo fa si parlava di introdurre i check sulla consistenza 
delle deleghe direttamente dentro il codice di bind; non so se ne 
abbiano poi fatto qualcosa...
-- 
http://bofhskull.wordpress.com/

 non sentire, di norma... ;-)
Fermo li!
Non ho detto "funziona lo stesso, chissenefrega".
Sto solo cercando di capire che ruolo abbiano i record NS quando bind
per primo non li caga.
Se per risolvere "www" della zona "
pippo.it
" bind9 ignora i record NS
indicati nella zona stessa per interrogare quelli indicati nel ggtld,
a che servono i record NS? (che io metto sempre, sia chiaro)
Tu hai detto che bind9 *per le query di tipo NS* legge i record NS nella
zona in questione, mentre per le altre query a quanto pare, e l'hai
dimostrato prima, interroga i dns indicati nel ggtld.
Per cui, i record ns indicati nella zona sono usati solo in query di
tipo ns, ma queste query, quando vengono fatte?
Io pensavo funzionasse così:
1) interrogo ggtld
2) leggo dns autoritari indicati nel ggtld
3) interrogo i dns autoritari
4) leggo i ns indicati nella zona
5) interrogo tali ns per risolvere l'host in questione.
A quanto pare il passaggio 4 non esiste, e l'interrogazione per i
record *NON* ns viene fatta direttamente dai dati presenti nel ggtld.

 per primo non li caga.
Stop: chi ti dice che non li caga? Io ti ho detto solo che non li caga 
*in quella situazione* e in quella implementazione. E' diverso.
Se tu (inteso "tu DNS") sei il legittimo detentore delle informazioni 
relative ad un dominio, è lecito aspettarsi che tra queste informazioni 
ci sia anche la risposta a "chi sono i DNS autoritativi per il dominio?".
Mi par sensato.
Ad esempio, rimanendo su BIND9: quando la zona viene aggiornata, viene 
inviata notifica per il zone-transfer a tutti i record NS relativi al 
dominio stesso (salvo ulteriori "also-notify"). Secondo te si aspetta di 
saperli, visto che la zona è la sua, oppure li va a domandare al TLD?!?
La seconda, se ci pensi, è un po' priva di senso, dato che 
significherebbe che ogni nodo dell'albero DNS dipende dal corretto 
funzionamento del resto dell'albero.
E ancora: se una zona non ha delega in quanto disconnessa dall'albero 
DNS "ufficiale", come nel caso di una zona ad uso interno, in assenza di 
record NS nella zona l'informazione da dove la si prende?!?
Che l'informazione relativa ai record NS (e, nel caso, ai rispettivi 
record A) sia duplicata e ridondante, nel funzionamento del protocollo, 
è indubbio, ma è anche lo scotto da pagare per un sistema 
decentralizzato ben funzionante...
-- 
http://bofhskull.wordpress.com/

 record NS nella zona l'informazione da dove la si prende?!?
Ecco, per cui (non ho provato) se in locale configurassi una zona
"ciccio.local" impostando, ad esempio, 212.216.112.112 come ns
delegherei la gestione di tutti i record al dns telecom.
Giusto?
Ma in tal caso, il nameserver autoritario sarebbe il mio, per cui
un padre ci sarà sempre.
Se configuro ciccio.local sul mio dns, per poter accedere ad esso
devo per forza di cose interrogare il mio dns, non essendo presente
tutta la gerarchia come di consueto.
Per cui ci sarà sempre una sorta di "ramo principale" e ci sarà sempre
un dns autoritario, solo che invece di interrogare tutto il ramo a
partire dal .it interrogo direttamente il mio dns.

 un padre ci sarà sempre.
Non esiste un DNS padre e un DNS figlio.
Esiste una *zona* padre e una zona figlio.
-- 
http://bofhskull.wordpress.com/

 Esiste una *zona* padre e una zona figlio.
E' stato un mio refuso, stavo parlando della zona.
Per cui, gira e rigira, anche se avessi zone locali
non collegate all'albero, ci sarebbe sempre una zona
padre e quindi i record NS non saranno mai usati.
Che venga interrogato il nameserver autoritario presente
in "
pippo.it
" registrato al nic, o che venga interrogato
il nameserver autoritario per la zona "prova.local" presente
nel mio server dns, i dns che fan fede son sempre e solo
quelli autoritari e mai i record ns.
Ragionando, ovviamente, dal punto di vista del figlio.
Perchè se io delegassi la gestione di "
ciccio.pasticcio.it
"
ad un cliente impostando
ciccio IN NS 1.2.3.4 (sorvola sugli ip)
nella zona di "
pasticcio.it
" che è sotto il mio controllo,
dal mio punto di vista, ovvero il padre, saranno presi sempre
in considerazione i miei record NS e mai quelli del cliente.
in pratica:
pasticcio.it
:
ciccio IN NS 1.2.3.4
ciccio.pasticcio.it
 su 1.2.3.4 (zona gestita dal cliente)
@ SOA...
@ IN NS 6.7.8.9
www IN A 4.5.6.7
dal mio punto di vista, il padre, sarà sempre usato il ns
indicato nella MIA zona, ovvero il record "ciccio IN NS 1.2.3.4"
mentre dal punto di vista del cliente, il figlio, non sarà mai
usato il ns indicato nella zona.