Chiarimento del perché i file di zona DNS richiedono record NS

Questa domanda è stata inizialmente posta qui: Perché i file di zona DNS richiedono record NS?

Per riassumere: "Quando vado al mio registrar e acquisto example.com, dirò al mio registrar che i miei nameserver sono ns1.example.org e ns2.example.org".

Ma per favore qualcuno può chiarire quanto segue:

Dopo la registrazione, il registro .com ora avrà un record che indica a un risolutore che deve visitare ns1.example.org o ns2.example.org per scoprire l'indirizzo IP di example.com. L'indirizzo IP risiede in un record A in un file di zona su ns1.example.org e ha una copia identica su ns2.example.org.

Tuttavia, all'interno di questo file, devono essere presenti anche 2 record NS che elencano ns1.example.org e ns2.example.org come nameserver. Ma poiché siamo già su uno di questi server, sembra che ci siano informazioni duplicate.

La risposta originariamente fornita alla domanda diceva che i nameserver elencati nel file di zona sono "autorevoli". Se i server dei nomi non corrispondessero, i server dei nomi autorevoli avrebbero la precedenza. Va benissimo, ma il resolver è arrivato al nameserver usando i nameserver elencati nel registro .com , e se il nameserver non corrispondeva, il resolver avrebbe cercato il file di zona sul nameserver sbagliato e non avrebbe essere in grado di trovarlo.

O è un caso del registro .com che estrae le informazioni del nameserver dal record ns del file di zona? (Ma allora suppongo che se cambiate il ns registrate il file di zona senza dirlo al registro, allora non avrebbe modo di sapere dove cercare.)

Grazie

Analizziamolo un po '.

I record NS nella zona TLD (ad esempio, example.com NS ...in com) sono record di delega .

I record A e AAAA nella zona TLD (ad esempio, ns1.example.com A ...in com) sono record di colla .

I record NS nella zona stessa (ovvero example.com NS ...in example.com) sono record di autorità .

I record A e AAAA nella zona stessa ( ns1.example.com A ...in example.com) sono record di indirizzi , chiari e semplici.

Quando si avvia un resolver (ricorsivo) senza cache dei dati della propria zona e solo la cache della zona radice (che viene utilizzata per avviare il processo di risoluzione dei nomi), andrà prima a ., quindi com.. I comserver risponderanno con una risposta della sezione di autorità che sostanzialmente dice "Non lo so, ma cerca qui qualcuno che lo sappia", lo stesso dei server per cui .fare com. Questa risposta alla query non è autorevole e non include una sezione di risposta popolata. Essa può anche includere una cosiddetta addizionalesezione che fornisce i mapping degli indirizzi per tutti i nomi host conosciuti dal particolare server (dai record di colla o, nel caso di risolutori ricorsivi, dai dati precedentemente memorizzati nella cache). Il resolver accetterà questa risposta della delega, risolverà il nome host di un record NS, se necessario, e procederà a interrogare il server DNS a cui è stata delegata l'autorità. Questo processo può ripetersi più volte se si dispone di una gerarchia di delega profonda, ma alla fine si traduce in una risposta alla query con il flag "risposta autorevole" impostato .

È importante notare che il risolutore (in genere, si spera) non tenterà di abbattere il nome host che è stato risolto per chiederlo pezzo per pezzo, ma lo invierà per intero al server "migliore" di cui è a conoscenza. Poiché il server dei nomi autorevole medio su Internet non è autorevole per la stragrande maggioranza dei nomi DNS validi, la risposta sarà una risposta di delega non autorevole che punta verso un altro server DNS.

Ora, un server non deve essere nominato nella delegazione o nei registri delle autorità in alcun luogo per essere autorevole per una zona. Consideriamo ad esempio il caso di un server master privato; in tal caso esiste un server DNS autorevole che solo gli amministratori dei server DNS slave per la zona sono a conoscenza. Un server DNS è autorevole per una zona se, secondo un meccanismo, a suo avviso ha una conoscenza completa e accurata della zona in questione. Un server DNS normalmente autorevole può, ad esempio, diventare non autorevole se i server master configurati non possono essere raggiunti entro il limite di tempo definito come tempo di scadenza nel record SOA.

Solo le risposte autorevoli devono essere considerate risposte alle query appropriate; tutto il resto è una delegazione o un errore di qualche tipo. Una delega a un server non autorevole è chiamata delega "zoppa" e indica che il resolver deve tornare indietro di un passaggio e provare un altro server DNS denominato. Se nella delegazione non esistono server dei nomi raggiungibili autorevoli, la risoluzione dei nomi non riesce (altrimenti sarà più lenta del normale).

Tutto ciò è importante perché i dati non autorevoli non devono essere memorizzati nella cache . Come potrebbe essere, dal momento che il server non autorevole non ha il quadro completo? Quindi il server autorevole deve, da solo, essere in grado di rispondere alla domanda "chi dovrebbe essere autorevole e per cosa?". Queste sono le informazioni fornite dai record NS nella zona.

Esistono numerosi casi limite in cui questo può effettivamente fare una differenza seria, principalmente incentrato su più etichette di nomi host all'interno di una singola zona (probabilmente abbastanza comune, ad esempio con zone DNS inverse, in particolare per ampi intervalli IP dinamici) o quando l'elenco dei server dei nomi differisce tra la zona padre e la zona in questione (che molto probabilmente è un errore, ma può essere eseguita anche intenzionalmente).

Puoi vedere come funziona in modo un po 'più dettagliato usando dige le sue caratteristiche +norec(non richiedere ricorsione) e @le caratteristiche dell'identificatore del server. Quello che segue è un esempio di come funziona un server DNS di risoluzione reale. Richiesta per i record A per unix.stackexchange.cominiziare, ad esempio a.root-servers.net:

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

Osserva attentamente i flagsconteggi per sezione. qrè la risposta alla query ed aaè la risposta autorevole. Si noti che vieni delegato solo ai comserver. Segui manualmente quella delega (nella vita reale un risolutore ricorsivo userebbe l'indirizzo IP dalla sezione aggiuntiva se fornita, o avvierebbe una risoluzione dei nomi separata di uno dei server dei nomi nominati se non viene fornito alcun IP nella risposta della delegazione, ma noi salta quella parte e torna al normale risolutore del sistema operativo per brevità dell'esempio):

$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec

Ora vedi che stackexchange.comè delegato (tra gli altri) ns1.serverfault.come non stai ancora ottenendo una risposta autorevole. Segui di nuovo la delegazione:

$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;unix.stackexchange.com. IN A

;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16

Bingo! Abbiamo ricevuto una risposta, perché la aabandiera è impostata e capita che contenga un indirizzo IP proprio come speravamo di trovare. A parte questo, vale la pena notare che almeno al momento in cui scrivo questo post, gli elenchi dei server dei nomi delegati e dell'autorità elencata differiscono, dimostrando che i due non devono essere identici. Ciò che ho esemplificato sopra è fondamentalmente il lavoro svolto da qualsiasi risolutore, tranne per il fatto che qualsiasi risolutore pratico memorizzerà anche le risposte lungo la strada in modo da non dover colpire i server root ogni volta.

Come si può vedere dall'esempio precedente, i record di delega e colla servono a uno scopo distinto dall'autorità e dai record di indirizzo nella zona stessa.

Un server dei nomi con memorizzazione nella cache eseguirà inoltre alcuni controlli di integrità sui dati restituiti per proteggere dall'avvelenamento della cache. Ad esempio, può rifiutare di memorizzare nella cache una risposta che nomina i server autorevoli comda un'origine diversa da quella che è già stata nominata da una zona padre come delegata a com. I dettagli dipendono dal server, ma l'intento è quello di memorizzare nella cache il più possibile senza aprire la porta della stalla per consentire a qualsiasi server di nomi casuali su Internet di ignorare i record di delega per tutto ciò che non è ufficialmente sotto la sua "giurisdizione".

Il registro .com è il "record di colla" che ha la posizione dei tuoi nameserver come indirizzo IP. Il risolutore non ha modo di conoscere l '"identità" del server DNS, quindi utilizza il record NS per garantire la corrispondenza dei numeri.

Richiesta DNS -> .com register (ip is xxxx) -> DNS (NS xxxx) corrisponde, risolvi.

Se non corrispondono o esistono, allora è una risposta non autorevole per il dominio.