Welche Rolle spielen NS-Einträge an der Spitze einer DNS-Domäne?

$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

Die Rolle eines NS-Eintrags unter dem Scheitelpunkt einer Domäne ist bekannt. Sie sind vorhanden, um die Berechtigung für eine Unterdomäne an einen anderen Nameserver zu delegieren. Beispiele hierfür sind die NS-Datensätze für sub1und sub2. Diese ermöglichen es dem Nameserver, Verweise für Teile der Domain zu vergeben, für die er sich nicht als autorisierend erachtet.

Der Zweck der NS-Einträge am Scheitelpunkt einer Domain ns1und ns2in diesem Fall scheint vom Internet insgesamt weniger verstanden zu werden. Mein Verständnis (das möglicherweise nicht ganzheitlich ist) lautet wie folgt:

1. Sie werden nicht vom Caching von DNS-Servern verwendet, um die autorisierenden Server für die Domäne zu ermitteln. Dies wird durch Nameserver-Leim erledigt , der auf Registrar-Ebene definiert wird. Der Registrar verwendet diese Informationen niemals , um die Leimaufzeichnungen zu erstellen.
2. Sie werden nicht verwendet, um Berechtigungen für die gesamte Domain an andere Nameserver zu delegieren. Der Versuch, dies mit Software wie ISC BIND zu tun, führt überhaupt nicht zum "erwarteten" Empfehlungsverhalten, da sich der Nameserver weiterhin als autorisierend für die Zone betrachtet.
3. Sie werden vom Nameserver nicht verwendet, um zu bestimmen, ob autorisierende Antworten zurückgegeben werden sollen ( AAFlag gesetzt) ​​oder nicht. Dieses Verhalten wird dadurch definiert, ob die Software als Master oder Slave für die Zone fungiert. Die meisten Nameserver-Programme können Apex-NS-Einträge bereitstellen, die nicht mit den in den vorgelagerten Glue-Einträgen enthaltenen Informationen übereinstimmen. Dies wiederum führt dazu, dass bekannte DNS-Validierungs-Websites Warnungen für die Domain generieren.

Was bleibt uns in diesem Fall übrig? Warum definieren wir diese Informationen, wenn sie anscheinend nicht durch das Zwischenspeichern von DNS-Servern im Internet insgesamt verbraucht werden?

Untergeordnete Identifikation

NS-Einträge auf Apex-Ebene werden von einem Masterserver verwendet, um seine Untergebenen zu identifizieren. Wenn sich Daten auf einem autorisierenden Nameserver ändern, wird dies über DNS NOTIFYNachrichten ( RFC 1996 ) an alle Peers in dieser Liste angekündigt . Diese Server rufen ihrerseits mit einer Anfrage nach dem SOADatensatz (der die Seriennummer enthält) zurück und treffen eine Entscheidung darüber, ob eine neuere Kopie dieser Zone abgerufen werden soll.

• Es ist möglich, diese Nachrichten an Server zu senden, die nicht in diesem NSAbschnitt aufgeführt sind. Hierfür sind jedoch serverspezifische Konfigurationsanweisungen erforderlich (z. B. die also-notifyAnweisung von ISC BIND ). Die Apex-NS-Einträge umfassen die Grundliste der Server, die bei einer Standardkonfiguration benachrichtigt werden sollen.
• Es ist zu beachten, dass die sekundären Server auf der Grundlage dieser NSDatensätze auch NOTIFY-Nachrichten aneinander senden , was normalerweise zu protokollierten Ablehnungen führt. Dies kann deaktiviert werden, indem Server angewiesen werden, Benachrichtigungen nur für Zonen zu senden, für die sie Master sind (BIND:) notify master;, oder NSbasierte Benachrichtigungen vollständig zugunsten explizit in der Konfiguration definierter Benachrichtigungen zu überspringen . (BIND: notify explicit;)

Maßgebliche Definition

Die obige Frage enthielt einen Irrtum:

Sie werden nicht vom Caching von DNS-Servern verwendet, um die autorisierenden Server für die Domäne zu ermitteln. Dies wird durch Nameserver-Leim erledigt, der auf Registrar-Ebene definiert wird. Der Registrar verwendet diese Informationen niemals, um die Leimaufzeichnungen zu erstellen.

Dies ist eine einfache Schlussfolgerung, die jedoch nicht zutreffend ist. Die NSin Ihrem Registrar-Konto definierten Datensätze und Leimdatensätze sind nicht maßgebend. Es liegt auf der Hand, dass sie nicht als "autorisierender" angesehen werden können als die Daten, die sich auf den Servern befinden, an die die Autorität delegiert wird. Dies wird durch die Tatsache unterstrichen, dass für Verweise das aaFlag (Authoritative Answer) nicht gesetzt ist.

Um zu veranschaulichen:

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

Beachten Sie das Fehlen aain den Flags für die obige Antwort. Die Überweisung selbst ist nicht maßgebend. Andererseits sind die Daten auf dem Server, auf den verwiesen wird, maßgebend.

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

Das heißt, diese Beziehung kann sehr verwirrend werden, da es nicht möglich ist, Informationen zu den autorisierenden Versionen dieser NSDatensätze zu erhalten, ohne die nicht autorisierenden NSDatensätze, die auf der übergeordneten Seite der Überweisung definiert sind. Was passiert, wenn sie nicht einverstanden sind?

• Die kurze Antwort lautet "inkonsistentes Verhalten".
• Die lange Antwort ist , dass Name - Server werden zunächst Stummel alles aus der Vorlage (und Klebstoff) auf einem leeren Cache, aber diejenigen NS, Aund AAAAAufzeichnungen irgendwann ersetzt werden können , wenn sie aufgefrischt werden. Die Aktualisierungen erfolgen, wenn die TTLs für diese temporären Datensätze ablaufen oder wenn jemand die Antwort für diese Datensätze explizit anfordert.
  • Aund AAAAAufzeichnungen für von Zonendaten (dh der comName - Server definiert , Klebstoff für Daten außerhalb der comZone, wie example.net) wird auf jeden Fall am Ende werden aufgefrischt, da es ein gut verständliches Konzept ist , dass ein Name - Server soll nicht eine maßgebliche Quelle dieser Informationen in Betracht gezogen werden . (RFC 2181)
  • Wenn sich die Werte der NSDatensätze zwischen der übergeordneten und der untergeordneten Seite der Überweisung unterscheiden (z. B. die in das Registrar Control Panel eingegebenen Nameserver, die sich von den NSauf denselben Servern gespeicherten Datensätzen unterscheiden ), ist das erlebte Verhalten bis einschließlich untergeordneter Server inkonsistent NSDatensätze werden komplett ignoriert. Dies liegt daran, dass das Verhalten durch die Standards nicht genau definiert ist und die Implementierung zwischen verschiedenen rekursiven Serverimplementierungen variiert. Mit anderen Worten, ein konsistentes Verhalten im Internet kann nur erwartet werden, wenn die Nameserver-Definitionen für eine Domain zwischen der übergeordneten und der untergeordneten Seite einer Empfehlung konsistent sind .

Das Entscheidende dabei ist, dass rekursive DNS-Server im gesamten Internet zwischen Zielen zurückspringen, wenn die auf der übergeordneten Seite des Verweises definierten Datensätze nicht mit den maßgeblichen Versionen dieser Datensätze übereinstimmen. Anfänglich werden die in der Überweisung enthaltenen Daten bevorzugt, nur um durch die maßgeblichen Definitionen ersetzt zu werden. Da Caches im gesamten Internet ständig von Grund auf neu aufgebaut werden, kann sich das Internet mit dieser Konfiguration nicht auf eine einzige Version der Realität festlegen. Wenn die autorisierenden Datensätze gemäß den Standards etwas Illegales tun, z. B. NSDatensätze auf Aliase verweisen, die durch a definiert sindCNAMEDies ist noch schwieriger zu beheben. Die Domain wechselt zwischen "funktioniert" und "funktioniert nicht" für Software, die den Verstoß ablehnt. (dh ISC BIND / named)

RFC 2181 §5.4.1 enthält eine Rangliste für die Vertrauenswürdigkeit dieser Daten und macht deutlich, dass Cache-Daten, die mit Verweisen und Klebstoff verknüpft sind, nicht als Antwort auf eine explizite Anforderung der Datensätze zurückgegeben werden können, auf die sie verweisen.

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Die NS-Aufzeichnungen der delegierten Zone liefern die Vollständigkeit der Domänendefinition. Die NS-Server selbst verlassen sich auf die Zonendatei. Es wird nicht erwartet, dass sie versuchen, sich selbst zu finden, indem sie eine rekursive Abfrage von den Stammservern durchführen. Die NS-Einträge in der Zonendatei bieten eine Reihe weiterer Funktionen.

Cacheserver aktualisieren möglicherweise die Nameserverliste, indem sie einen Nameserver aus dem Cache abfragen. Solange ein Caching-Server die Adresse eines Nameservers kennt, wird dieser verwendet, anstatt rekursiv nach einem geeigneten NS-Datensatz zu suchen.

Beim Verschieben von Nameservern ist es wichtig, sowohl die alten als auch die neuen Nameserver zu aktualisieren. Dies verhindert Ausfälle oder Inkonsistenzen, die auftreten, wenn die beiden Zonendefinitionen nicht mehr synchron sind. Die aktualisierten Datensätze werden schließlich von allen Servern aktualisiert, die die NS-Datensätze zwischengespeichert haben. Dadurch wird die zwischengespeicherte Liste der Nameserver ersetzt.

Die NS-Einträge helfen auch dabei, die Richtigkeit der DNS-Konfiguration zu bestätigen. Die Validierungssoftware überprüft häufig, ob die Nameserver-Definitionen der delegierenden Zone mit den von der Zone bereitgestellten übereinstimmen. Diese Prüfung kann auf allen Nameservern durchgeführt werden. Nichtübereinstimmungen können auf eine Fehlkonfiguration hinweisen.

Wenn NS-Einträge vorhanden sind, können getrennte (lokale) Zonen eingerichtet werden. Dies können Subdomains einer registrierten Domain oder eine völlig neue Domain sein (aufgrund von TLD-Änderungen nicht empfohlen). Hosts, die die Nameserver als Nameserver verwenden, können die Zonen finden, die nicht über die Stammserver erreichbar sind. Andere Nameserver können so konfiguriert werden, dass nach den Nameservern für die lokalen Zonen gesucht wird.

Im Fall von geteiltem DNS (intern / extern) kann es wünschenswert sein, einen anderen Satz von DNS-Servern zu haben. In diesem Fall unterscheiden sich die NS-Liste (und wahrscheinlich auch andere Daten) und in den NS-Einträgen in den Zonendateien wird die entsprechende Nameserverliste aufgeführt.