Erläuterung, warum DNS-Zonendateien NS-Einträge erfordern

Diese Frage wurde ursprünglich hier gestellt: Warum benötigen DNS-Zonendateien NS-Einträge?

Um zusammenzufassen: "Wenn ich zu meinem Registrar gehe und example.com kaufe, werde ich meinem Registrar mitteilen, dass meine Nameserver ns1.example.org und ns2.example.org sind."

Aber bitte kann jemand folgendes klären:

Nach der Registrierung verfügt die .com-Registrierung nun über einen Datensatz, aus dem hervorgeht, dass ein Resolver ns1.example.org oder ns2.example.org besuchen muss, um die IP-Adresse von example.com herauszufinden. Die IP-Adresse befindet sich in einem A-Datensatz in einer Zonendatei auf ns1.example.org und hat eine identische Kopie auf ns2.example.org.

In dieser Datei müssen sich jedoch auch 2 NS-Einträge befinden, in denen ns1.example.org und ns2.example.org als Nameserver aufgeführt sind. Da wir uns jedoch bereits auf einem dieser Server befinden, handelt es sich anscheinend um doppelte Informationen.

Die ursprünglich auf die Frage gegebene Antwort besagte, dass die in der Zonendatei aufgelisteten Nameserver "maßgeblich" sind. Wenn die Nameserver nicht übereinstimmen, haben die maßgeblichen Nameserver Vorrang. Das ist alles in Ordnung und gut, aber der Resolver ist mit den in der .com-Registrierung aufgeführten Nameservern auf dem Nameserver angekommen. Wenn der Nameserver nicht übereinstimmt, sucht der Resolver die Zonendatei auf dem falschen Nameserver. nicht in der Lage sein, es zu finden.

Oder ist es ein Fall, in dem die .com-Registrierung Nameserver-Informationen aus dem Zonendateidatensatz "ns" extrahiert? (Aber dann nehme ich an, wenn Sie die Zonendatei ändern, ohne der Registrierung mitzuteilen, dass sie nicht weiß, wo sie suchen soll.)

Vielen Dank

Lassen Sie es uns ein wenig aufschlüsseln.

Die NS-Datensätze in der TLD-Zone (z. B. example.com NS ...in com) sind Delegierungsdatensätze .

Die A- und AAAA-Datensätze in der TLD-Zone (z. B. ns1.example.com A ...in com) sind Leimdatensätze .

Die NS-Datensätze in der Zone selbst (d. H. example.com NS ...In example.com) sind Berechtigungsdatensätze .

Die A- und AAAA-Datensätze in der Zone selbst ( ns1.example.com A ...in example.com) sind schlicht und einfach Adressdatensätze .

Wenn ein (rekursiver) Resolver mit keinem Cache für die Daten Ihrer Zone und nur mit dem Root-Zonen-Cache (der zum Booten des Namensauflösungsprozesses verwendet wird) startet, wird zuerst der Server .aufgerufen com.. Die comServer antworten mit einer Antwort der Autoritätssektion, die im Grunde "Ich weiß es nicht, aber suche hier jemanden, der es weiß", genau wie die Server, die dies .tun com. Diese Abfrageantwort ist nicht autorisierend und enthält keinen ausgefüllten Antwortabschnitt. Es kann auch ein sogenannter Zusatz enthaltenAbschnitt, der die Adresszuordnungen für alle Hostnamen angibt, die dem jeweiligen Server bekannt sind (entweder aus Leimdatensätzen oder im Fall von rekursiven Auflösern aus zuvor zwischengespeicherten Daten). Der Resolver nimmt diese Delegierungsantwort entgegen, löst bei Bedarf den Hostnamen eines NS-Eintrags auf und fragt den DNS-Server ab, an den die Berechtigung delegiert wurde. Dieser Vorgang wird möglicherweise mehrmals wiederholt, wenn Sie über eine tiefe Delegierungshierarchie verfügen, führt jedoch schließlich zu einer Abfrageantwort, bei der das Flag "Autorisierende Antwort" gesetzt ist .

Es ist wichtig zu beachten, dass der Resolver (im Allgemeinen, hoffentlich) nicht versucht, den aufgelösten Hostnamen aufzuschlüsseln, um Stück für Stück danach zu fragen, sondern ihn einfach in seiner Gesamtheit an den "besten" Server sendet, den er kennt. Da der durchschnittliche autorisierende Nameserver im Internet für die überwiegende Mehrheit der gültigen DNS-Namen nicht autorisierend ist, handelt es sich bei der Antwort um eine nicht autorisierende Delegierungsantwort, die auf einen anderen DNS-Server verweist.

Jetzt muss ein Server in den Delegierungs- oder Berechtigungsdatensätzen nirgends benannt werden, um für eine Zone autorisierend zu sein. Stellen Sie sich zum Beispiel den Fall eines privaten Masterservers vor. In diesem Fall ist ein autorisierender DNS-Server vorhanden, der nur den Administratoren der Slave-DNS-Server für die Zone bekannt ist. Ein DNS-Server ist für eine Zone maßgeblich, wenn er seiner Meinung nach über einen Mechanismus verfügt, der die betreffende Zone vollständig und genau kennt. Ein normalerweise autorisierender DNS-Server kann beispielsweise nicht autorisierend werden, wenn die konfigurierten Masterserver nicht innerhalb des im SOA-Datensatz als Ablaufzeit definierten Zeitlimits erreicht werden können.

Nur autorisierende Antworten sollten als richtige Abfrageantworten betrachtet werden. Alles andere ist entweder eine Delegation oder ein Irrtum. Eine Delegierung an einen nicht autorisierenden Server wird als "lahme" Delegierung bezeichnet. Dies bedeutet, dass der Resolver einen Schritt zurückverfolgen und einen anderen benannten DNS-Server ausprobieren muss. Wenn in der Delegierung keine autorisierenden erreichbaren Nameserver vorhanden sind, schlägt die Namensauflösung fehl (andernfalls ist sie nur langsamer als normal).

Dies ist alles wichtig, da nicht autorisierende Daten nicht zwischengespeichert werden dürfen . Wie könnte es sein, da der nicht autorisierende Server nicht das vollständige Bild hat? Der autorisierende Server muss also in der Lage sein, die Frage zu beantworten, wer für was autorisierend sein soll. Dies sind die Informationen, die von den NS-Einträgen in der Zone bereitgestellt werden.

Es gibt eine Reihe von Randfällen, in denen dies tatsächlich einen gravierenden Unterschied ausmachen kann, vor allem in Bezug auf mehrere Hostnamen-Labels in einer einzelnen Zone (wahrscheinlich ziemlich häufig, z. B. bei Reverse-DNS-Zonen, insbesondere bei großen dynamischen IP-Bereichen) oder wenn sich die Liste der Nameserver unterscheidet die übergeordnete Zone und die betreffende Zone (was höchstwahrscheinlich ein Fehler ist, aber auch absichtlich geschehen kann).

Wie dies funktioniert, können Sie anhand digder Funktionen +norec(keine Rekursion anfordern) und der @Serverspezifizierer genauer beobachten. Im Folgenden wird veranschaulicht, wie ein tatsächlich auflösender DNS-Server funktioniert. Abfrage für den / die A-Datensatz (e) zum unix.stackexchange.comStarten bei zB a.root-servers.net:

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

Schauen Sie sich flagsdie Anzahl der Abschnitte und die Anzahl der Abschnitte genau an . qrist Query Response und aaist maßgebliche Antwort. Beachten Sie, dass Sie nur an die comServer delegiert werden. Befolgen Sie diese Delegierung manuell (in der Realität würde ein rekursiver Resolver die IP-Adresse aus dem zusätzlichen Abschnitt verwenden, falls vorhanden) oder eine separate Namensauflösung für einen der genannten Nameserver initiieren, wenn in der Antwort der Delegierung keine IPs angegeben sind Überspringen Sie diesen Teil und greifen Sie einfach auf den normalen Resolver des Betriebssystems zurück, um das Beispiel zu verkürzen.

$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec

Jetzt sehen Sie, dass dies stackexchange.com(unter anderem) an delegiert ns1.serverfault.comist und Sie immer noch keine verbindliche Antwort erhalten. Folgen Sie erneut der Delegation:

$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;unix.stackexchange.com. IN A

;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16

Bingo! Wir haben eine Antwort erhalten, weil das aaFlag gesetzt ist und zufällig eine IP-Adresse enthält, wie wir sie uns erhofft hatten. Im Übrigen ist es erwähnenswert, dass sich zumindest zum Zeitpunkt des Schreibens dieses Beitrags die Liste der Nameserver, an die delegiert wurde, und die Liste der Nameserver mit den aufgeführten Berechtigungen unterscheiden, was zeigt, dass die beiden nicht identisch sein müssen. Was ich oben als Beispiel angeführt habe, ist im Grunde die Arbeit, die jeder Resolver leistet, außer dass jeder praktische Resolver auch Antworten zwischenspeichert, damit er nicht jedes Mal auf die Root-Server zugreifen muss.

Wie Sie aus dem obigen Beispiel ersehen können, dienen die Delegierungs- und Leimdatensätze einem anderen Zweck als die Berechtigungs- und Adressdatensätze in der Zone selbst.

Ein Nameserver, der den Cache auflöst, führt im Allgemeinen auch einige Überprüfungen der Richtigkeit der zurückgegebenen Daten durch, um sich vor einer Cachevergiftung zu schützen. Beispielsweise kann es abgelehnt werden, eine Antwort zwischenzuspeichern, in der die autorisierenden Server für comeine andere Quelle als eine Antwort benannt sind, die bereits von einer übergeordneten Zone als an delegiert für benannt wurde com. Die Details sind serverabhängig, es wird jedoch angestrebt, so viel wie möglich zwischenzuspeichern, ohne die Scheunentür zu öffnen, damit zufällige Nameserver im Internet Delegierungsdatensätze für Objekte außer Kraft setzen können, die nicht offiziell ihrer "Gerichtsbarkeit" unterliegen.

Die .com Registry ist der "Glue Record", der den Ort Ihres Nameservers als IP-Adresse enthält. Der Resolver kann die "Identität" Ihres DNS-Servers nicht erkennen und verwendet den NS-Eintrag, um sicherzustellen, dass die Nummern übereinstimmen.

DNS-Anfrage -> .com-Registrierung (IP ist xxxx) -> DNS (NS xxxx) stimmt überein, auflösen.

Wenn sie nicht übereinstimmen oder existieren, ist dies eine nicht autorisierende Antwort für die Domain.