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.
PPPCCCPPPCCC...), Child Centric Sticky (PPPCCCCCC...) und Parent Sticky (PPPPPP...). Bei weitem am häufigsten ist kinderbezogenes Nicht-Kleben, und kinderbezogenes Kleben ist tatsächlich häufiger als elterliches Kleben. Clients springen in der Tat zwischen den beiden Versionen der Realität hin und her, wenn die NS-Daten des Kindes und des Elternteils nicht übereinstimmen, es sei denn, die Resolver-Software ist übergeordnet, was das unwahrscheinlichste Ergebnis ist.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.
quelle