Angenommen, Ihr konfigurierter Nameserver verfügt über keine zwischengespeicherten Ergebnisse. Wie viele Nameserver muss Ihr Nameserver abfragen, um maps.google.com aufzulösen? Mit welchen Befehlen würden Sie alle diese Nameserver finden? Listen Sie eine von jeder Ebene auf und erklären Sie, warum diese Ebene benötigt wird.
Nun, lassen Sie uns dieses auseinander nehmen.
"Vorausgesetzt, Ihr konfigurierter Nameserver verfügt über keine zwischengespeicherten Ergebnisse" - Wenn er überhaupt keine zwischengespeicherten Daten hat, kann er zunächst nichts auflösen. Um den Cache des Resolvers zu füllen, benötigen Sie die NS- und Adressdatensätze (A, AAAA) für die .Zone (AKA root). Das sind die Root-Nameserver, die sich in der root-servers.net.Zone befinden. Diese Zone oder diese DNS-Server haben nichts Magisches. Diese Daten werden dem DNS-Resolver jedoch häufig "außerhalb des Bandes" zur Verfügung gestellt, um den Cache des Resolvers zu aktivieren. Nur autorisierende Nameserver benötigen diese Daten nicht, das Auflösen von Nameservern jedoch.
Auch "auflösen", was? Irgendein RR-Typ mit diesem Namen? Eine ARR? Oder etwas anderes? Welche Klasse ( CH/ Chaosnet, IN/ Internet, ...)? Der genaue Prozess wird anders sein, aber die allgemeine Idee bleibt dieselbe.
Wenn wir davon ausgehen können, dass wir wissen, wie man die Root-Nameserver findet, aber nicht mehr, und dass wir mit "Auflösen" den Inhalt aller IN Amit dem Namen verknüpften RRs abrufen, wird dies viel praktischer.
Um einen DNS-Namen aufzulösen, teilen Sie den Namen grundsätzlich in Labels auf und arbeiten sich dann von rechts nach links vor. Vergiss das .am Ende nicht; Sie würden wirklich eher lösen maps.google.com.als maps.google.com. Das lässt uns eine Lösung brauchen (wir wissen das, aber eine DNS-Resolver-Implementierung wird es wahrscheinlich nicht):
.com.google.com.maps.google.com.
Beginnen Sie damit, herauszufinden, wo Sie nach dem Inhalt von fragen können .. Das ist leicht; Wir haben bereits diese Informationen: die Namen der Root-Nameserver und die IP-Adressen . Wir haben also einen Root-Nameserver. Angenommen a.root-servers.net, wir verwenden 198.41.0.4 ( ebenfalls 2001: 503: ba3e :: 2: 30), um die Namensauflösung fortzusetzen. In der Praxis wird einer der ersten Schritte des Resolvers wahrscheinlich darin bestehen, die bereitgestellten Root-Server-Daten zu verwenden, um einen der Root-Zone-Server nach einer genauen Liste der Nameserver für die Root-Zone zu fragen, um sicherzustellen, dass einer der Server vorhanden ist Die Namen und IP-Adressen sind gültig und erreichbar. Zu Beginn der Auflösung enthält es einen vollständigen Datensatz für die Stammzone.
Schießen Sie eine DNS-Abfrage für maps.google.com. IN Abis 198.41.0.4 ab. Es wird Ihnen als Antwort sagen: "Nein, ich werde es nicht tun, aber hier ist jemand, der es vielleicht weiß." Das ist eine Überweisung. Es enthält NSDatensätze für die nächstgelegene Zone, die dem betreffenden Server bekannt ist, sowie alle Klebesätze, die dem Server zufällig zur Verfügung stehen. Wenn keine Klebedaten verfügbar sind, müssen Sie zuerst den Host auflösen, der in dem von Ihnen ausgewählten NS-Datensatz angegeben ist. Erstellen Sie daher eine separate Namensauflösung, um die IP-Adresse zu erhalten. Wenn Klebedaten verfügbar sind, haben Sie die IP-Adresse eines Nameservers, die mindestens "näher" an der Antwort liegt. In diesem Fall sind dies die Server für die com.Zone, und es werden auch Klebedaten bereitgestellt.
Wiederholen Sie den Vorgang und stellen Sie einem der com.Nameserver dieselbe Frage. Sie wissen es auch nicht, verweisen Sie jedoch auf die maßgeblichen Nameserver von Google. An diesem Punkt wird im allgemeinen Fall getroffen oder verfehlt, ob Klebedaten bereitgestellt werden oder nicht; Nichts hindert eine comDomain daran, nur Nameserver zu haben. nlIn diesem Fall ist es unwahrscheinlich, dass Klebedaten von den gTLD-Servern verfügbar sind. Die bereitgestellten Kleberdaten sind möglicherweise auch unvollständig, oder wenn Sie wirklich Pech haben, sind sie möglicherweise sogar falsch! Sie müssen immer bereit sein, diese separate Namensauflösung zu erzeugen, die ich oben erwähnt habe.
Grundsätzlich machen Sie so lange weiter, bis Sie eine Antwort mit dem aaFlag (maßgebliche Antwort) erhalten. Diese Antwort sagt Ihnen, wonach Sie fragen oder dass die von Ihnen angeforderte RR nicht vorhanden ist (entweder NXDOMAINoder NOERRORmit Datensätzen ohne Antwort). Halten Sie Ausschau nach Antworten wie SERVFAIL(und ziehen Sie sich einen Schritt zurück und versuchen Sie es mit einem anderen Server, wenn Sie einen erhalten. Wenn alle benannten Server zurückkehren SERVFAIL, schlagen Sie den Namensauflösungsprozess fehl und kehren SERVFAILSie zum Client zurück).
Die Alternative zum Abfragen des vollständigen RR-Namens von jedem Server (was als schlechte Vorgehensweise angesehen werden kann) besteht darin, die zuvor ermittelte Aufteilungsliste der Labels zu verwenden und die vom Server angegebenen Nameserver weiter in Richtung Stamm für IN NSund IN A/ IN AAAARRs zu fragen für dieses Etikett und verwenden Sie diese, um den Prozess der Namensauflösung voranzutreiben. Das ist in der Praxis nur unwesentlich anders, und der gleiche Prozess gilt immer noch.
Sie können diesen gesamten Prozess simulieren, indem Sie die +traceOption für das digDienstprogramm verwenden, das Teil von BIND ist, oder set debugin nslookup.
Es ist auch zu bedenken , dass einige RRtypes (vor allem NS, MXund ein paar anderen, auch, A6waren vernünftig für eine Weile gut genutzt , aber sind veraltet) tun können und Referenz andere RRs. In diesem Fall müssen Sie möglicherweise einen weiteren Prozess zur Namensauflösung starten , um Ihrem Kunden eine vollständige und nützliche Antwort zu geben.
dig +trace, bin mir aber nicht sicher, was unter Levels zu verstehen ist. Dies könnte eine Frage für Serverfehler sein.