Perché il DNS funziona nel modo in cui funziona?

Questa è una domanda canonica sul DNS (Domain Name Service).

Se la mia comprensione del sistema DNS è corretta, il registro .com contiene una tabella che mappa i domini (www.esempio.com) ai server DNS.

1. Qual è il vantaggio? Perché non mappare direttamente a un indirizzo IP?

2. Se l'unico record che deve essere modificato durante la configurazione di un server DNS per puntare a un indirizzo IP diverso, si trova sul server DNS, perché il processo non è istantaneo?

3. Se l'unico motivo del ritardo sono le cache DNS, è possibile ignorarle, quindi posso vedere cosa sta succedendo in tempo reale?

In realtà, è più complicato di così - piuttosto che un "registro centrale (che) contiene una tabella che mappa i domini (www.mysite.com) ai server DNS", ci sono diversi livelli di gerarchia

C'è un registro centrale (root server) che contengono solo un piccolo insieme di voci: le NS (server dei nomi) record per tutti i domini di primo livello - .com, .net, .org, .uk, .us, .au, e così via.

Quei server contengono solo record NS per il livello successivo in basso. Per scegliere un esempio, i server dei nomi per il .ukdominio ha solo voci per .co.uk, .ac.uke le altre zone di secondo livello in uso nel Regno Unito.

Quei server contengono solo record NS per il livello successivo in basso - per continuare l'esempio, ti dicono dove trovare i record NS google.co.uk. È su quei server che finalmente troverai una mappatura tra un nome host simile www.google.co.uke un indirizzo IP.

Come ulteriore grinza, ogni strato servirà anche per record di "colla". Ciascun record NS associa un dominio a un nome host, ad esempio i record NS per l' .ukelenco nsa.nic.ukcome uno dei server. Per passare al livello successivo, dobbiamo scoprire che i record NS nic.uksono e che si rivelano includere nsa.nic.ukanche. Quindi ora dobbiamo conoscere l'IP di nsa.nic.uk, ma per scoprirlo dobbiamo fare una query nsa.nic.uk, ma non possiamo fare quella query fino a quando non conosciamo l'IP per nsa.nic.uk...

Per risolvere questo dilemma, i server per .ukaggiungere il record A per nsa.nic.uknella ADDITIONAL SECTIONrisposta (la risposta riportata di seguito viene ridotta per brevità):

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

Senza questi record di colla extra, non saremmo mai in grado di trovare i nameserver nic.uk.e quindi non saremmo mai in grado di cercare alcun dominio ospitato lì.

Per tornare alle tue domande ...

a) Qual è il vantaggio? Perché non mappare direttamente a un indirizzo IP?

Per prima cosa, consente di distribuire le modifiche a ogni singola zona. Se vuoi aggiornare la voce per www.mydomain.co.uk, devi solo modificare le informazioni sul tuo mydomain.co.uknameserver. Non è necessario avvisare i .co.ukserver centrali , i .ukserver o i nameserver principali. Se esistesse solo un unico registro centrale che mappasse tutti i livelli lungo la gerarchia che dovevano essere notificati su ogni singola modifica di una voce DNS lungo la catena, sarebbe completamente sommerso dal traffico.

Prima del 1982, in realtà era così che avveniva la risoluzione dei nomi. Un registro centrale è stato informato di tutti gli aggiornamenti e hanno distribuito un file chiamato hosts.txtche conteneva il nome host e l'indirizzo IP di ogni macchina su Internet. Una nuova versione di questo file veniva pubblicata ogni poche settimane e ogni macchina su Internet avrebbe dovuto scaricare una nuova copia. Ben prima del 1982, questo stava iniziando a diventare problematico, e così il DNS fu inventato per fornire un sistema più distribuito.

D'altra parte, questo sarebbe un unico punto di errore: se il registro centrale singolo non funzionasse, l'intera rete sarebbe offline. Avere un sistema distribuito significa che i guasti riguardano solo piccole sezioni di Internet, non il tutto.

(Per fornire ulteriore ridondanza, in realtà ci sono 13 cluster separati di server che servono la zona radice. Qualsiasi modifica ai record di dominio di livello superiore deve essere trasferita a tutti e 13; immagina di dover coordinare l'aggiornamento di tutti e 13 per ogni singola modifica a qualsiasi nome host in qualsiasi parte del mondo ...)

b) Se l'unico record che deve cambiare quando sto configurando un server DNS per puntare a un indirizzo IP diverso si trova sul server DNS, perché il processo non è istantaneo?

Perché DNS utilizza molta cache per accelerare le cose e ridurre il carico sugli NS. Senza memorizzazione nella cache, ogni singola volta che hai visitato il google.co.uktuo computer dovrebbe uscire in rete per cercare i server .uk, quindi .co.uk, quindi .google.co.uk, quindi www.google.co.uk. Queste risposte in realtà non cambiano molto, quindi cercarle ogni volta è una perdita di tempo e traffico di rete. Invece, quando NS restituisce i record sul computer, includerà un valore TTL, che indica al computer di memorizzare nella cache i risultati per un numero di secondi.

Ad esempio, i record NS per .ukhanno un TTL di 172800 secondi - 2 giorni. Google è ancora più conservatore: i record NS per google.co.ukun TTL di 4 giorni. I servizi che si affidano alla possibilità di aggiornare rapidamente possono scegliere un TTL molto più basso - ad esempio, telegraph.co.ukhanno un TTL di soli 600 secondi nei loro record NS.

Se vuoi che gli aggiornamenti della tua zona siano quasi istantanei, puoi scegliere di ridurre il tuo TTL fino a piacimento. Più è basso il set, più traffico vedranno i tuoi server, poiché i client aggiornano i loro record più spesso. Ogni volta che un client deve contattare i server per eseguire una query, ciò causerà un certo ritardo poiché è più lento rispetto alla ricerca della risposta nella loro cache locale, quindi ti consigliamo di considerare il compromesso tra aggiornamenti veloci e un servizio veloce.

c) Se l'unico motivo del ritardo sono le cache DNS, è possibile ignorarle, così posso vedere cosa sta succedendo in tempo reale?

Sì, questo è facile se stai testando manualmente con digo strumenti simili - basta dirgli quale server contattare.

Ecco un esempio di una risposta memorizzata nella cache:

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

La sezione flag qui non contiene il aaflag, quindi possiamo vedere che questo risultato proviene da una cache piuttosto che direttamente da una fonte autorevole. In effetti, possiamo vedere da dove proviene 97.107.133.4, che sembra essere uno dei risolutori DNS locali di Linode. Il fatto che la risposta sia stata pubblicata da una cache molto vicina a me significa che ho impiegato 0 msec per ottenere una risposta; ma come vedremo tra un momento, il prezzo che pago per quella velocità è che la risposta è quasi 5 minuti obsoleti.

Per bypassare il risolutore di Linode e andare direttamente alla fonte, basta scegliere uno di quegli NS e dire a scavare di contattarlo direttamente:

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

Puoi vedere che questa volta i risultati sono stati forniti direttamente dalla fonte: nota la aabandiera, che indica che i risultati provengono da una fonte autorevole. Nel mio esempio precedente, i risultati provenivano dalla mia cache locale, quindi mancano del aaflag. Vedo che la fonte autorevole per questo dominio imposta un TTL di 600 secondi. I risultati ottenuti in precedenza da una cache locale avevano un TTL di soli 319 secondi, il che mi dice che erano rimasti nella cache per (600-319) secondi - quasi 5 minuti - prima di vederli.

Sebbene il TTL qui sia solo di 600 secondi, alcuni ISP tenteranno di ridurre ulteriormente il loro traffico forzando i loro resolver DNS a memorizzare i risultati nella cache più a lungo - in alcuni casi, per 24 ore o più. È tradizionale (in un modo non-sappiamo-se-questo-è-davvero-necessario-ma-mettiamoci al sicuro) supporre che qualsiasi modifica DNS che fai non sarà visibile ovunque sul internet per 24-48 ore.

a) Il numero di IP -> mappature dei nomi host nel mondo è DAVVERO grande. Questo sistema distribuisce la responsabilità di ospitare tutti i record del sottodominio e MX e tutti gli altri record DNS inviati al proprietario del nome di dominio. Questo era praticamente il punto del nome di dominio. .comè detenuto da un registro dove .ukpuò essere detenuto da un altro. Allo stesso modo example.come otherexample.compuò essere ospitato separatamente in modo che le risorse possano essere distribuite.

b) È memorizzato nella cache, il che riduce il numero di hit sull'host DNS fino a una piccola frazione di ciò che sarebbe altrimenti. Per impostazione predefinita, i record risiedono 2 giorni nella cache prima di essere eliminati. Questo può essere modificato modificando il TTL (tempo di vita) del record.

c) È possibile interrompere efficacemente la memorizzazione nella cache dei record impostando un TTL davvero breve. Questo NON è raccomandato a meno che non lo si usi per DNS dinamico. La memorizzazione nella cache elimina di molto gli hit sul server DNS. Per scegliere un numero indovinato, stiamo parlando di eliminare il 95% delle richieste.

Se utilizzi un sistema * nix, scarica una copia dei djbdns di Dan Bernstein da http://cr.yp.to/djbdns.html ed esegui il suo programma dnstrace per vedere come funziona il sistema di query ricorsivo. È molto istruttivo.

a) Il numero di possibili nomi di dominio è troppo grande per essere gestito da un server. E non c'è solo .com; c'è .net, .org, .se, .info e un numero qualsiasi di altri. Aggiungete a ciò, è possibile delegare la responsabilità di un sottodominio (che è effettivamente ciò che comfa). Il fatto che il DNS sia meno centralizzato semplifica la gestione.

b) Le macchine lungo il percorso dall'utente all'utente dispongono di cache DNS per ridurre al minimo il numero di richieste necessarie. Previene, ad esempio, lo spamming della rete con richieste per l'indirizzo di "serverfault.com" ogni volta che si riceve una pagina da SF. Questi server possono persino memorizzare nella cache i risultati "dominio non esiste", motivo per cui può essere necessario un po 'di tempo prima che venga visualizzato anche un nuovo dominio.

c) Sebbene sia possibile disabilitare la cache, ci sono spesso altri server DNS tra la macchina e il server DNS di yourdomain.com. Il server DNS del tuo ISP, ad esempio, proverà a memorizzare nella cache il più possibile. Gli unici record che vengono aggiornati relativamente rapidamente in rete sono quelli con un breve TTL (che in pratica dice "Sono valido solo per pochi secondi; dopodiché, chiedimi di nuovo le informazioni correnti"). Il motivo per cui i TTL sono così elevati, tuttavia, è che il server responsabile del dominio può scaricare parte del lavoro su altri server. Se avessi tutta la rete in contatto con il tuo uno o due server DNS per ogni hit sul tuo sito web, sarebbero praticamente inutilizzabili nel momento in cui qualcuno vedesse il tuo sito su /., Digg, ecc.