Supponendo che il nameserver configurato non abbia alcun risultato memorizzato nella cache a sua disposizione, quanti nameserver devono essere interrogati dal nameserver per risolvere maps.google.com? Quali comandi useresti per trovare tutti questi nameserver? Elenca uno per ogni livello e spiega perché questo livello è necessario.
Bene, scegliamo questo a parte.
"Supponendo che il nameserver configurato non abbia alcun risultato memorizzato nella cache" , innanzitutto, se non ha alcun dato memorizzato nella cache, non può risolvere nulla. Per eseguire il priming della cache del resolver, è necessario disporre dei record NS e address (A, AAAA) per la zona .(radice AKA). Questi sono i server dei nomi di root, che si trovano nella root-servers.net.zona. Non c'è nulla di magico in quella zona o in quei server DNS. Tuttavia, questi dati vengono spesso forniti "fuori banda" al risolutore DNS, proprio per adescare la cache del risolutore. I server dei nomi solo autorevoli non hanno bisogno di questi dati, ma lo fanno i server dei nomi in risoluzione.
Inoltre, "risolvi" in cosa? Qualche RRtype con quel nome? Un ARR? O qualcos'altro? Quale classe ( CH/ Chaosnet, IN/ Internet, ...)? Il processo esatto sarà diverso, ma l'idea generale rimane la stessa.
Se possiamo supporre che sappiamo come trovare i server dei nomi di root ma niente di più, e che per "risoluzione" intendiamo ottenere il contenuto di qualsiasi IN ARR associato al nome, diventa molto più pratico.
Per risolvere un nome DNS, sostanzialmente dividi il nome in etichette e poi procedi da destra a sinistra. Non dimenticare il .alla fine; avresti davvero risolto maps.google.com.piuttosto che maps.google.com. Questo ci lascia con la necessità di risolvere (lo sappiamo, ma un'implementazione del resolver DNS probabilmente non lo farà):
.com.google.com.maps.google.com.
Inizia con capire dove chiedere il contenuto di .. Questo è facile; disponiamo già di tali informazioni: i nomi dei server dei nomi root e gli indirizzi IP . Quindi abbiamo un server dei nomi di root. Diciamo che decidiamo di usare 198.41.0.4 ( a.root-servers.net, anche 2001: 503: ba3e :: 2: 30) per continuare la risoluzione dei nomi. In pratica, una delle prime cose fatte dal risolutore sarà probabilmente quella di utilizzare i dati del server radice forniti per chiedere a uno dei server della zona radice un elenco accurato dei server dei nomi per la zona radice, assicurando così che se qualcuno di i nomi e gli indirizzi IP sono validi e raggiungibili, quando avrà inizio la risoluzione avrà un set completo e completo di dati per la zona radice.
maps.google.com. IN ASposta una query DNS per 198.41.0.4. In risposta ti dirà "no, non lo farò, ma ecco qualcuno che potrebbe sapere"; questo è un rinvio. Contiene i NSrecord per la zona più vicina di cui il server in questione è a conoscenza, insieme a tutti i record di colla disponibili sul server. Se non sono disponibili dati sulla colla, devi prima risolvere l'host indicato nel record NS selezionato, quindi genera una risoluzione dei nomi separata per ottenere l'indirizzo IP; se sono disponibili dati di colla, avrai l'indirizzo IP di un server dei nomi che è almeno "più vicino" alla risposta. In questo caso, sarà il set di server per la com.zona e verranno forniti anche i dati di colla.
Ripetere il processo, ponendo a uno dei com.server dei nomi la stessa domanda. Neanche loro lo sanno, ma ti rimandano ai server dei nomi autorevoli di Google. A questo punto, nel caso generale, verrà colpito o meno se vengono forniti o meno i dati di colla; non c'è nulla che impedisca a un comdominio di avere server dei nomi solo nl, ad esempio, nel qual caso è improbabile che i dati di colla siano disponibili dai server gTLD. I dati di colla forniti potrebbero anche essere incompleti o, se sei davvero sfortunato, potrebbero anche essere errati! Devi sempre essere pronto a spawnare quella risoluzione di nome separata che ho menzionato sopra.
Fondamentalmente, vai avanti fino a quando non ottieni una risposta con il aaflag (risposta autorevole) impostato. Quella risposta ti dirà cosa stai chiedendo o che il RR che hai richiesto non esiste ( NXDOMAINo NOERRORcon record di dati a risposta zero). Continua a cercare risposte come SERVFAIL(e fai un passo indietro e prova un altro server se ne hai uno; se tutti i server nominati ritornano SERVFAIL, fallisci il processo di risoluzione dei nomi e torna SERVFAILal client).
L'alternativa alla richiesta del nome RR completo da ciascun server (che potrebbe essere considerato una cattiva pratica) è quella di utilizzare l'elenco suddiviso di etichette che abbiamo determinato in precedenza, chiedere ai server dei nomi dati dal server più verso la radice per IN NSe IN A/ IN AAAARR per quell'etichetta e utilizzali per promuovere il processo di risoluzione dei nomi. Questo è solo marginalmente diverso nella pratica e lo stesso processo si applica ancora.
È possibile simulare l'intero processo utilizzando l' +traceopzione per l' digutilità, inclusa in BIND o set debugin nslookup.
Vale anche la pena ricordare che alcuni tipi di RR (in particolare NS, MXe alcuni altri; inoltre, è A6stato ragionevolmente ben utilizzato per un po 'ma è stato deprecato) e può fare riferimento ad altri RR. In tal caso, potrebbe essere necessario generare un altro processo di risoluzione dei nomi per dare una risposta completa e utile al tuo cliente.
dig +trace, ma non sono sicuro di cosa si intenda per livelli. Questa potrebbe essere una domanda per Server Fault.