Wie funktioniert die DNS-Namensauflösung grundsätzlich?

Question 1

Angenommen, Ihr konfigurierter Nameserver verfügt über keine zwischengespeicherten Ergebnisse. Wie viele Nameserver muss Ihr Nameserver abfragen, um maps.google.com aufzulösen? Welche(n) Befehl(e) würden Sie verwenden, um alle diese Nameserver zu finden? Listen Sie einen von jeder Ebene auf und erklären Sie, warum diese Ebene benötigt wird.

Nun gut, lassen Sie uns dieses hier auseinandernehmen.

„Vorausgesetzt, Ihr konfigurierter Nameserver verfügt über keine zwischengespeicherten Ergebnisse.“-- zunächst einmal, wenn esNEINWenn Sie überhaupt zwischengespeicherte Daten haben, kann dieser nichts auflösen. Um den Cache des Resolvers zu füllen, benötigen Sie die NS- und Adressdatensätze (A, AAAA) für die .(auch als Root-)Zone bezeichnete Zone. Das sind die Root-Nameserver, die sich in der root-servers.net.Zone befinden. Diese Zone oder diese DNS-Server haben nichts Magisches an sich. Diese Daten werden dem DNS-Resolver jedoch häufig „out of band“ bereitgestellt, um den Cache des Resolvers zu füllen. Nur autoritative Nameserver benötigen diese Daten nicht, auflösende Nameserver jedoch schon.

Und in was soll es „aufgelöst“ werden? In irgendeinen RR-Typ mit diesem Namen? In einen ARR? Oder in etwas anderes? In welche Klasse ( CH/Chaosnet, IN/Internet, ...)? Der genaue Vorgang ist unterschiedlich, aber die Grundidee bleibt dieselbe.

Wenn wir davon ausgehen können, dass wir nur wissen, wie die Stamm-Nameserver zu finden sind, und dass wir mit „Auflösen“ das Abrufen des Inhalts aller IN Amit dem Namen verknüpften RRs meinen, wird die Sache wesentlich praktischer.

Um einen DNS-Namen aufzulösen, teilen Sie den Namen im Grunde in Bezeichnungen auf und arbeiten sich dann von rechts nach links vor. Vergessen Sie nicht das .am Ende; Sie würden tatsächlich auflösen maps.google.com.und nicht maps.google.com. Damit bleibt uns nur noch die Aufgabe, aufzulösen (wir wissen das, aber eine DNS-Resolver-Implementierung wird es wahrscheinlich nicht wissen):

.
com.
google.com.
maps.google.com.

Beginnen wir damit, herauszufinden, wo wir den Inhalt von anfordern .. Das ist einfach; wir haben diese Informationen bereits: den Root-NameserverNamen und IP-Adressen. Wir haben also einen Root-Nameserver. Nehmen wir an, wir entscheiden uns, 198.41.0.4 ( a.root-servers.net, auch 2001:503:ba3e::2:30) zu verwenden, um die Namensauflösung fortzusetzen. In der Praxis wird der Resolver wahrscheinlich als Erstes die bereitgestellten Root-Server-Daten verwenden, um einen der Root-Zonenserver nach einer genauen Liste der Nameserver für die Root-Zone zu fragen. Auf diese Weise wird sichergestellt, dass, wenn einer der Namen und IP-Adressen gültig und erreichbar ist, bei Beginn der Auflösung ein vollständiger Datensatz für die Root-Zone vorliegt.

Senden Sie eine DNS-Abfrage an maps.google.com. IN A198.41.0.4. Sie erhalten als Antwort „nö, das mache ich nicht, aber hier ist jemand, der es vielleicht weiß“; das ist eine Empfehlung. Sie enthält NSDatensätze für die nächstgelegene Zone, die der betreffende Server kennt, zusammen mit allen Verbindungsdatensätzen, die der Server zufällig zur Verfügung hat. Wenn keine Verbindungsdaten verfügbar sind, müssen Sie zuerst den Host auflösen, der im ausgewählten NS-Datensatz genannt wird. Erstellen Sie also eine separate Namensauflösung, um die IP-Adresse zu erhalten. Wenn Verbindungsdaten verfügbar sind, haben Sie die IP-Adresse eines Nameservers, der der Antwort zumindest „näher“ kommt. In diesem Fall ist das die Gruppe von Servern für die com.Zone, und Verbindungsdaten werden ebenfalls bereitgestellt.

Wiederholen Sie den Vorgang, indem Sie einem der com.Nameserver dieselbe Frage stellen. Auch sie wissen es nicht, verweisen Sie aber auf die autoritativen Nameserver von Google. An diesem Punkt ist es im Allgemeinen reine Glückssache, ob Verbindungsdaten bereitgestellt werden oder nicht. Es spricht nichts dagegen, dass eine comDomain nur Nameserver in hat nl, in welchem Fall Verbindungsdaten von den gTLD-Servern wahrscheinlich nicht verfügbar sind. Die bereitgestellten Verbindungsdaten könnten auch unvollständig sein, oder, wenn Sie wirklich Pech haben, könnten sie sogar falsch sein! Sie müssenstetsSeien Sie darauf vorbereitet, dass die oben erwähnte separate Namensauflösung ausgelöst wird.

Im Grunde machen Sie so lange weiter, bis Sie eine Antwort mit aagesetztem Flag (autoritative Antwort) erhalten. Diese Antwort sagt Ihnen, wonach Sie gefragt haben oder dass der angeforderte RR nicht existiert (entweder NXDOMAIN, oder NOERRORmit null Antwortdatensätzen). Achten Sie weiterhin auf Antworten wie SERVFAIL(und gehen Sie einen Schritt zurück und versuchen Sie es mit einem anderen Server, wenn Sie einen erhalten; wenn alle benannten Server zurückgeben SERVFAIL, schlagen Sie beim Namensauflösungsprozess fehl und kehren SERVFAILSie zum Client zurück).

Die Alternative zur Abfrage des vollständigen RR-Namens von jedem Server (was als schlechte Praxis angesehen werden könnte) besteht darin, die zuvor ermittelte aufgeteilte Liste von Bezeichnungen zu verwenden, die vom Server weiter unten in der Wurzel angegebenen Nameserver nach / RRs für diese Bezeichnung zu fragen IN NSund diese zu verwenden IN A, IN AAAAum den Namensauflösungsprozess voranzutreiben. In der Praxis ist das nur geringfügig anders, und derselbe Prozess gilt immer noch.

Sie können diesen gesamten Vorgang simulieren, indem Sie die +traceOption des digDienstprogramms verwenden, das Teil von BIND ist, oder set debugin nslookup.

Es ist auch wichtig zu bedenken, dass einige RR-Typen (insbesondere NS, MXund einige andere; außerdem A6wurde eine Zeit lang recht häufig verwendet, ist aber veraltet) auf andere RRs verweisen können und dies auch tun. In diesem Fall müssen Sie möglicherweisenoch ein andererNamensauflösungsprozess, um Ihrem Kunden eine vollständige und nützliche Antwort zu geben.

Answer

Angenommen, Ihr konfigurierter Nameserver verfügt über keine zwischengespeicherten Ergebnisse. Wie viele Nameserver muss Ihr Nameserver abfragen, um maps.google.com aufzulösen? Welche(n) Befehl(e) würden Sie verwenden, um alle diese Nameserver zu finden? Listen Sie einen von jeder Ebene auf und erklären Sie, warum diese Ebene benötigt wird.

Nun gut, lassen Sie uns dieses hier auseinandernehmen.

„Vorausgesetzt, Ihr konfigurierter Nameserver verfügt über keine zwischengespeicherten Ergebnisse.“-- zunächst einmal, wenn esNEINWenn Sie überhaupt zwischengespeicherte Daten haben, kann dieser nichts auflösen. Um den Cache des Resolvers zu füllen, benötigen Sie die NS- und Adressdatensätze (A, AAAA) für die .(auch als Root-)Zone bezeichnete Zone. Das sind die Root-Nameserver, die sich in der root-servers.net.Zone befinden. Diese Zone oder diese DNS-Server haben nichts Magisches an sich. Diese Daten werden dem DNS-Resolver jedoch häufig „out of band“ bereitgestellt, um den Cache des Resolvers zu füllen. Nur autoritative Nameserver benötigen diese Daten nicht, auflösende Nameserver jedoch schon.

Und in was soll es „aufgelöst“ werden? In irgendeinen RR-Typ mit diesem Namen? In einen ARR? Oder in etwas anderes? In welche Klasse ( CH/Chaosnet, IN/Internet, ...)? Der genaue Vorgang ist unterschiedlich, aber die Grundidee bleibt dieselbe.

Wenn wir davon ausgehen können, dass wir nur wissen, wie die Stamm-Nameserver zu finden sind, und dass wir mit „Auflösen“ das Abrufen des Inhalts aller IN Amit dem Namen verknüpften RRs meinen, wird die Sache wesentlich praktischer.

Um einen DNS-Namen aufzulösen, teilen Sie den Namen im Grunde in Bezeichnungen auf und arbeiten sich dann von rechts nach links vor. Vergessen Sie nicht das .am Ende; Sie würden tatsächlich auflösen maps.google.com.und nicht maps.google.com. Damit bleibt uns nur noch die Aufgabe, aufzulösen (wir wissen das, aber eine DNS-Resolver-Implementierung wird es wahrscheinlich nicht wissen):

.
com.
google.com.
maps.google.com.

Beginnen wir damit, herauszufinden, wo wir den Inhalt von anfordern .. Das ist einfach; wir haben diese Informationen bereits: den Root-NameserverNamen und IP-Adressen. Wir haben also einen Root-Nameserver. Nehmen wir an, wir entscheiden uns, 198.41.0.4 ( a.root-servers.net, auch 2001:503:ba3e::2:30) zu verwenden, um die Namensauflösung fortzusetzen. In der Praxis wird der Resolver wahrscheinlich als Erstes die bereitgestellten Root-Server-Daten verwenden, um einen der Root-Zonenserver nach einer genauen Liste der Nameserver für die Root-Zone zu fragen. Auf diese Weise wird sichergestellt, dass, wenn einer der Namen und IP-Adressen gültig und erreichbar ist, bei Beginn der Auflösung ein vollständiger Datensatz für die Root-Zone vorliegt.

Senden Sie eine DNS-Abfrage an maps.google.com. IN A198.41.0.4. Sie erhalten als Antwort „nö, das mache ich nicht, aber hier ist jemand, der es vielleicht weiß“; das ist eine Empfehlung. Sie enthält NSDatensätze für die nächstgelegene Zone, die der betreffende Server kennt, zusammen mit allen Verbindungsdatensätzen, die der Server zufällig zur Verfügung hat. Wenn keine Verbindungsdaten verfügbar sind, müssen Sie zuerst den Host auflösen, der im ausgewählten NS-Datensatz genannt wird. Erstellen Sie also eine separate Namensauflösung, um die IP-Adresse zu erhalten. Wenn Verbindungsdaten verfügbar sind, haben Sie die IP-Adresse eines Nameservers, der der Antwort zumindest „näher“ kommt. In diesem Fall ist das die Gruppe von Servern für die com.Zone, und Verbindungsdaten werden ebenfalls bereitgestellt.

Wiederholen Sie den Vorgang, indem Sie einem der com.Nameserver dieselbe Frage stellen. Auch sie wissen es nicht, verweisen Sie aber auf die autoritativen Nameserver von Google. An diesem Punkt ist es im Allgemeinen reine Glückssache, ob Verbindungsdaten bereitgestellt werden oder nicht. Es spricht nichts dagegen, dass eine comDomain nur Nameserver in hat nl, in welchem Fall Verbindungsdaten von den gTLD-Servern wahrscheinlich nicht verfügbar sind. Die bereitgestellten Verbindungsdaten könnten auch unvollständig sein, oder, wenn Sie wirklich Pech haben, könnten sie sogar falsch sein! Sie müssenstetsSeien Sie darauf vorbereitet, dass die oben erwähnte separate Namensauflösung ausgelöst wird.

Im Grunde machen Sie so lange weiter, bis Sie eine Antwort mit aagesetztem Flag (autoritative Antwort) erhalten. Diese Antwort sagt Ihnen, wonach Sie gefragt haben oder dass der angeforderte RR nicht existiert (entweder NXDOMAIN, oder NOERRORmit null Antwortdatensätzen). Achten Sie weiterhin auf Antworten wie SERVFAIL(und gehen Sie einen Schritt zurück und versuchen Sie es mit einem anderen Server, wenn Sie einen erhalten; wenn alle benannten Server zurückgeben SERVFAIL, schlagen Sie beim Namensauflösungsprozess fehl und kehren SERVFAILSie zum Client zurück).

Die Alternative zur Abfrage des vollständigen RR-Namens von jedem Server (was als schlechte Praxis angesehen werden könnte) besteht darin, die zuvor ermittelte aufgeteilte Liste von Bezeichnungen zu verwenden, die vom Server weiter unten in der Wurzel angegebenen Nameserver nach / RRs für diese Bezeichnung zu fragen IN NSund diese zu verwenden IN A, IN AAAAum den Namensauflösungsprozess voranzutreiben. In der Praxis ist das nur geringfügig anders, und derselbe Prozess gilt immer noch.

Sie können diesen gesamten Vorgang simulieren, indem Sie die +traceOption des digDienstprogramms verwenden, das Teil von BIND ist, oder set debugin nslookup.

Es ist auch wichtig zu bedenken, dass einige RR-Typen (insbesondere NS, MXund einige andere; außerdem A6wurde eine Zeit lang recht häufig verwendet, ist aber veraltet) auf andere RRs verweisen können und dies auch tun. In diesem Fall müssen Sie möglicherweisenoch ein andererNamensauflösungsprozess, um Ihrem Kunden eine vollständige und nützliche Antwort zu geben.

Question 2

Es gibt einen dnstracerBefehl (Sie müssen ihn möglicherweise installieren, zumindest unter Debian, das ist auch der Paketname), der die Namensauflösung verfolgt. Sie können auch (wie Koveras in einem Kommentar anmerkt) verwenden dig.

Hier ist es mit dnstracer. -s .bedeutet, mit der Wurzel zu beginnen; -4bedeutet, IPv4 zu verwenden (v6 ist hier defekt ...); -obedeutet, die aufgelösten IP-Adressen am Ende tatsächlich anzuzeigen (ich habe diesen Teil der Ausgabe weggelassen, es gibt viele davon).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

Diese Ausgabe wird fortgesetzt, während dnstracer alle Pfade verfolgt (damit Sie beispielsweise sehen können, ob einige der Nameserver eine veraltete Zone haben).

Sie sehen also, dass eine Abfrage an den Stamm-Nameserver erforderlich ist, dann eine an die GTLD-Server (den Server für die .com-Zone) und schließlich eine an einen Google-Nameserver.

Mit digist die Ausgabe viel ausführlicher (ich werde also viel kürzen):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

digzeigt zusätzlich, dass eine Abfrage ausgeführt wurde, um die aktuelle Liste der Stamm-Nameserver abzurufen. Dies ist etwas, was ein DNS-Server normalerweise sehr selten tut. Daher bin ich mir nicht sicher, ob Sie es in Ihrem Cold-Cache-Fall zählen.

Sie können natürlich auch die eigentlichen Abfragen im Kabel verfolgen, beispielsweise mit wireshark.

Answer