Il tuo browser no. Il tuo browser utilizzerà le chiamate di sistema standard per la risoluzione dei nomi host (di solito, credo, getaddrinfo() ), e questi a loro volta esamineranno solitamente il contenuto di /etc/resolv.conf per trovare i server dei nomi di risoluzione configurati e interrogarli. A loro volta inoltreranno la query del sistema operativo del tuo desktop ai server upstream (memorizzando nella cache qualsiasi risposta) o eseguiranno essi stessi la risoluzione ricorsiva. Si noti che la maggior parte dei passaggi nella catena di cui sopra sono configurabili, quindi ciò che il browser fa in realtà sarà determinato localmente; ma lo scenario di cui sopra è tipico.
Sono i server dei nomi a risoluzione ricorsiva in quella catena (che siano i server dei nomi autorevoli configurati localmente o i server di alcuni ISP lungo la linea) che devono sapere come trovare i server root e lo fanno tramite un file di zona preconfigurato per . (che di solito viene periodicamente aggiornato interrogando un root nameserver disponibile).
Modifica :Non è così. Dipenderà dall'implementazione, ma nel mio caso (BIND), ne sceglie solo uno e lo interroga. Finché ottiene una risposta in tempo, riparte da lì. Cosa ti fa pensare che sia in corso qualsiasi tipo di operazione di misurazione?
Nella risoluzione dei nomi DNS, come fanno i browser a determinare i server DNS più vicini disponibili tra molti server DNS?
Come indicano le altre risposte, il tuo browser o altro programma client non esegue questa selezione. Un programma client richiede la risoluzione del servizio dei nomi effettuando chiamate a una libreria chiamata resolver.
Il resolver determina quali server deve contattare per porre una query. Dipende dall'implementazione del resolver ma di solito consulta, nell'ordine, un elenco di risolutori ricorsivi con cui è stato configurato (tramite configurazione statica o ricevendoli tramite un meccanismo come DHCP.)
In sintesi, quindi:il tuo programma (a livello utente) chiede al risolutore la risoluzione dei nomi e il risolutore chiede i server dei nomi che gli sono stati forniti tramite qualche meccanismo di configurazione.
Sono a conoscenza del fatto che ci sono 13 server root, ma come fa il server DNS del mio ISP a sapere quale server DNS root contattare?
Anche questo dipende dall'implementazione. Descriverò come funziona con BIND, da
- BIND è un server dei nomi molto popolare e ci sono buone probabilità che il tuo ISP lo stia utilizzando, e
- Anche se il tuo ISP non utilizza BIND, alcune alternative utilizzano un meccanismo simile per la selezione del server dei nomi da un set di record di risorse NS.
Per cominciare, parliamo prima di come un nameserver ricorrente sa anche quali nameserver scegliere per parlare con un dominio specifico. Per ogni dominio raggiungibile dal livello root (".") del nameserver, gli amministratori che gestiscono quel dominio pubblicano, nel dominio padre che lo contiene, un set di record di risorse di tipo record NS (i.e. nameserver) da delegare pubblicamente ai nameserver denominato nel record della risorsa ha la responsabilità di risolvere le query che hanno a che fare con quel dominio.
Una delle bellezze di questo sistema è che consente la delega gerarchica distribuita per il sistema dei nomi di dominio e l'unico dominio per il quale un server ricorsivo richiede a priori knowledge è il livello root, che il server è configurato per conoscere. Una volta era più comune specificare l'RRset NS per il root tramite un file di "suggerimenti" che BIND caricava all'avvio, ma da un po' di tempo gli indirizzi IP usati dai root server sono stati predefiniti in BIND. [Digressione:puoi ancora sovrascrivere i built-in specificando una root hint zone, e infatti l'indirizzo di d.root-servers.net è cambiato di recente e la nuova posizione non si rifletterà nell'elenco dei built-in fino a nuovo vengono create e distribuite versioni di BIND che includono le nuove informazioni. Al momento le versioni che contengono il nuovo indirizzo IP dei D root server sono in versione beta.]
Ad ogni modo, il punto chiave qui è che ogni dominio ha associato ad esso un record NS RRset contenente i nameserver annunciati pubblicamente per quel dominio. Dovresti provare a guardarne qualcuna tu stesso. Diamo un'occhiata alla radice:
$ dig . ns +edns=0 @f.root-servers.net.
Toglierò semplicemente la sezione delle risposte, che conterrà l'RRset NS restituito in un ordine non prevedibile (sto sorvolando un po' qui -- l'ordine è generalmente determinato dalla configurazione del server dei nomi con cui sto parlando Radici diverse potrebbero rispondere con ordinamenti diversi, ma gli elementi ordinati dovrebbero essere gli stessi.)
;; ANSWER SECTION:
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
Questi sono tutti i server dei nomi per il dominio radice (".") e possiamo porre a ciascuno di essi domande sul dominio radice. Se poniamo loro una domanda su qualcosa che non si trova nel dominio principale, riceveremo un errore o, più probabilmente, un rinvio a un altro set di server dei nomi (ad es. "example.com? Non rispondo a domande su example.com. . Prova a chiedere ai server dei nomi di dominio .com -- sono laggiù..")
Come fa allora BIND a sapere quale nameserver del NS RRset gli darà la risposta più veloce?
La risposta è:inizialmente no. Ma con il suo comportamento predefinito, impara nel tempo e si adatta normalmente chiedendo al server con il tempo di andata e ritorno più breve.
Tempi di andata e ritorno e selezione dei server dei nomi candidati BIND si affida ai Round Trip Times (RTT) ai nameserver in un RRset per scegliere quale nameserver deve ricevere le sue query. La prima volta che un NS RRset per un dominio viene aggiunto alla cache, a tutti i record nel set viene assegnato un piccolo tempo di andata e ritorno casuale, dell'ordine di pochi millisecondi. Dopo il priming iniziale, quando una query deve essere indirizzato ai nameserver delegati per un dato dominio, BIND controlla la sua cache e (si spera) trova l'RRset. Sceglie il server con il tempo RTT più basso dal set e fa la sua richiesta. E quando la query è terminata, BIND aggiorna gli RTT per NS RRset come segue:
- l'RTT del server che è stato appena interrogato è impostato sul tempo di andata e ritorno effettivo.
- Tutti gli altri server nell'RRset hanno i loro RTT ridotti di una piccola frazione (~3-4%, credo...)
Vediamo come funziona facendo un esempio. La prima volta che il mio resolver ricorsivo incontra il dominio example.com, carica l'RRset NS per example.com nella sua cache. Supponiamo che gli amministratori di example.com abbiano annunciato tre nameserver per example.com in modo che l'RRset NS assomigli a:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Supponiamo inoltre, per il bene di questo esempio, che il tuo resolver impieghi i seguenti periodi di tempo per ricevere una risposta da ciascuno dei server in questo set:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Ora, la prima volta che viene caricato example.com NS RRset, i pesi RTT vengono caricati con piccoli valori casuali. Quindi, prima di chiedere qualsiasi cosa a un nameserver example.com, la tabella RTT potrebbe apparire così:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
La prima volta che interroghiamo example.com, quindi, andremo su serverc e faremo la nostra domanda. Serverc impiega 50 ms per rispondere, quindi dopo che la nostra query è terminata aggiorniamo la nostra tabella RTT in modo che ora legga:
servera -- 7 ms // reduced by a small fraction
serverb -- 8 ms // reduced by a small fraction
serverc -- 50 ms // updated to reflect the actual round trip time.
La prossima volta sceglieremo ovviamente servera, poiché ora ha il tempo di andata e ritorno più basso. Dopo solo poche query al dominio example.com dovremmo avere un'idea abbastanza chiara di quale server dei nomi ci dà la risposta più veloce e da allora in poi preferiremo quel server di più del tempo.
Perché la maggior parte del tempo e non tutto del tempo? E che succede con la parte che ho menzionato prima su "Tutti gli altri server nell'RRset hanno i loro RTT ridotti di una piccola frazione"? Bene, si scopre che mentre vogliamo preferire il server più veloce, non vogliamo cancellare definitivamente gli altri server. Forse il server c è il server più veloce quasi sempre, ma al momento in cui abbiamo impostato per la prima volta il suo RTT era occupato in modo anomalo. Forse un server è stato temporaneamente fuori servizio, con un RTT incredibilmente alto (dopo che il nostro tentativo di interrogarlo è scaduto), ma vogliamo ricominciare a chiederlo dopo che sarà tornato in servizio. Regolando ogni volta al ribasso i valori degli altri server, prima o poi scenderanno al di sotto dell'RTT medio del server che preferiamo. Quando ciò accade, lanceremo una query nella loro direzione e se il tempo è migliore, allora fantastico. La maggior parte delle nostre query andrà al server o ai server più veloci del set, ma i valori anomali vengono provati periodicamente per assicurarsi che, se le condizioni sono cambiate, la tabella venga aggiornata per riflettere ciò e in media viene ancora selezionato il server migliore.
I 13 root nameserver non sono in realtà 13 server. Ognuno è un cluster distribuito di server in vari siti in tutto il mondo e vi si accede tramite routing IP standard, proprio come qualsiasi altro server.
Per quanto riguarda quale root nameserver che il server DNS dell'ISP sceglie di contattare, che probabilmente dipende dai dettagli del loro resolver DNS. Forse è completamente casuale, forse è ponderato, ma non saprei dirtelo.
Modifica:se intendevi, come trova l'ISP uno qualsiasi dei 13 server dei nomi, esiste un elenco pubblico di essi e dei corrispondenti indirizzi IP che praticamente ogni computer ha. Da lì, si tratta solo di sceglierne uno e lasciare che i router di Internet facciano il resto.