6. Zonen
Dieser Abschnitt definiert Begriffe, die bei der Diskussion von Zonen verwendet werden, die bedient oder abgerufen werden.
Zone: "Autoritative Informationen sind in Einheiten organisiert, die 'Zonen' genannt werden, und diese Zonen können automatisch an die Nameserver verteilt werden, die redundante Dienste für die Daten in einer Zone bereitstellen." (Zitiert aus [RFC1034], Abschnitt 2.4)
Kind (Child): "Die Entität in den Aufzeichnungen, die die Delegation der Domäne vom Elternteil hat." (Zitiert aus [RFC7344], Abschnitt 1.1)
Elternteil (Parent): "Die Domäne, in der das Kind registriert ist." (Zitiert aus [RFC7344], Abschnitt 1.1) Früher wurde "Parent Name Server" in [RFC882] als "der Nameserver, der Autorität über den Platz im Domänennamenraum hat, der die neue Domäne halten wird" definiert. (Beachten Sie, dass [RFC882] durch [RFC1034] und [RFC1035] obsolet wurde.) [RFC819] hat auch eine gewisse Beschreibung der Beziehung zwischen Eltern und Kindern.
Origin (Ursprung):
(a) "Der Domänenname, der am oberen Ende einer Zone erscheint (direkt unterhalb des Schnittes, der die Zone von ihrem Elternteil trennt). Der Name der Zone ist derselbe wie der Name der Domäne am Ursprung der Zone." (Zitiert aus [RFC2181], Abschnitt 6.) Heutzutage werden dieser Sinn von "Origin" und "Apex" (unten definiert) oft austauschbar verwendet.
(b) Der Domänenname, innerhalb dessen ein gegebener relativer Domänenname in Zonendateien erscheint. Allgemein im Kontext von "$ORIGIN" gesehen, was ein Kontrolleintrag ist, der in [RFC1035], Abschnitt 5.1, als Teil des Master-File-Formats definiert ist. Zum Beispiel, wenn das $ORIGIN auf "example.org." gesetzt ist, dann ist eine Master-File-Zeile für "www" tatsächlich ein Eintrag für "www.example.org.".
Apex (Spitze): Der Punkt im Baum an einem Owner eines SOA und entsprechenden autoritativen NS RRset. Dies wird auch "Zone Apex" genannt. [RFC4033] definiert es als "der Name auf der Kind-Seite eines Zonenschnitts". Der "Apex" kann nützlicherweise als datentheoretische Beschreibung einer Baumstruktur betrachtet werden, und "Origin" ist der Name desselben Konzepts, wenn es in Zonendateien implementiert wird. Die Unterscheidung wird jedoch in der Verwendung nicht immer beibehalten, und man kann Verwendungen finden, die subtil mit dieser Definition in Konflikt stehen. [RFC1034] verwendet den Begriff "oberer Knoten der Zone" (top node of the zone) als Synonym von "Apex", aber dieser Begriff wird nicht weit verbreitet verwendet. Heutzutage werden der erste Sinn von "Origin" (oben) und "Apex" oft austauschbar verwendet.
Zonenschnitt (Zone cut): Der Begrenzungspunkt zwischen zwei Zonen, wo der Ursprung einer der Zonen das Kind der anderen Zone ist.
"Zonen werden durch 'Zonenschnitte' begrenzt. Jeder Zonenschnitt trennt eine 'Kind'-Zone (unterhalb des Schnitts) von einer 'Eltern'-Zone (oberhalb des Schnitts). (Zitiert aus [RFC2181], Abschnitt 6; beachten Sie, dass dies kaum eine ostensive Definition ist.) Abschnitt 4.2 von [RFC1034] verwendet "cuts" (Schnitte) als 'Zonenschnitt'."
Delegation: Der Prozess, durch den eine separate Zone im Namensraum unterhalb des Apex einer gegebenen Domäne erstellt wird. Delegation geschieht, wenn ein NS RRset in der Elternzone für den Kind-Ursprung hinzugefügt wird. Delegation geschieht inhärent an einem Zonenschnitt. Der Begriff ist auch allgemein ein Substantiv: die neue Zone, die durch den Akt der Delegation erstellt wird.
Glue Records: "[Resource Records], die nicht Teil der autoritativen Daten [der Zone] sind und Adress-Resource-Records für die [Nameserver in Subzonen] sind. Diese RRs sind nur notwendig, wenn der Name des Nameservers 'unterhalb' des Schnitts ist, und werden nur als Teil einer Referral-Antwort verwendet." Ohne Glue "könnten wir mit der Situation konfrontiert sein, wo die NS RRs uns sagen, dass wir, um die Adresse eines Nameservers zu lernen, den Server unter Verwendung der Adresse kontaktieren sollten, die wir lernen möchten." (Definition aus [RFC1034], Abschnitt 4.2.1)
Eine spätere Definition ist, dass Glue "jeden Record in einer Zonendatei einschließt, der nicht ordnungsgemäß Teil dieser Zone ist, einschließlich Nameserver-Records delegierter Subzonen (NS-Records), Adress-Records, die diese NS-Records begleiten (A, AAAA, etc.), und alle anderen vereinzelten Daten, die erscheinen könnten" ([RFC2181], Abschnitt 5.4.1). Obwohl Glue heute manchmal mit dieser breiteren Definition im Hinterkopf verwendet wird, legt der Kontext, der die [RFC2181]-Definition umgibt, nahe, dass sie auf die Verwendung von Glue innerhalb des Dokuments selbst angewendet werden soll und nicht notwendigerweise darüber hinaus.
In-Bailiwick:
(a) Ein Adjektiv zur Beschreibung eines Nameservers, dessen Name entweder dem Zonenursprung untergeordnet ist oder (selten) derselbe ist. In-Bailiwick-Nameserver erfordern Glue-Records in ihrer Elternzone (unter Verwendung der ersten der Definitionen von "Glue Records" in der obigen Definition).
(b) Daten, für die der Server entweder autoritativ ist oder autoritativ für einen Vorfahren des Owner-Namens ist. Dieser Sinn des Begriffs wird normalerweise verwendet, wenn die Relevanz von Glue-Records in einer Antwort diskutiert wird. Zum Beispiel könnte der Server für die Elternzone "example.com" mit Glue-Records für "ns.child.example.com" antworten. Da die Zone "child.example.com" ein Nachkomme der Zone "example.com" ist, sind die Glue-Records In-Bailiwick.
Out-of-Bailiwick: Das Antonym von In-Bailiwick.
Autoritative Daten (Authoritative data): "Alle RRs, die an allen Knoten vom oberen Knoten der Zone bis zu Blattknoten oder Knoten oberhalb von Schnitten um den unteren Rand der Zone herum angehängt sind." (Zitiert aus [RFC1034], Abschnitt 4.2.1) Es wird bemerkt, dass diese Definition versehentlich auch alle NS-Records einschließen könnte, die in der Zone erscheinen, selbst diejenigen, die möglicherweise nicht wirklich autoritativ sind, weil es identische NS RRs unterhalb des Zonenschnitts gibt. Dies offenbart die Mehrdeutigkeit im Begriff autoritative Daten, weil die elternseitigen NS-Records die Delegation autoritativ anzeigen, auch wenn sie selbst keine autoritativen Daten sind.
Root-Zone (Root zone): Die Zone, deren Apex das Label mit Nulllänge ist. Auch manchmal "die DNS-Wurzel" (the DNS root) genannt.
Leere Non-Terminals (Empty non-terminals): "Domänennamen, die keine Resource Records besitzen, aber Subdomänen haben, die welche besitzen." (Zitiert aus [RFC4592], Abschnitt 2.2.2.) Ein typisches Beispiel findet sich in SRV-Records: im Namen "_sip._tcp.example.com" ist es wahrscheinlich, dass "_tcp.example.com" keine RRsets hat, aber dass "_sip._tcp.example.com" (mindestens) ein SRV RRset hat.
Delegationszentrierte Zone (Delegation-centric zone): Eine Zone, die hauptsächlich aus Delegationen an Kindzonen besteht. Dieser Begriff wird im Gegensatz zu einer Zone verwendet, die möglicherweise einige Delegationen an Kindzonen hat, aber auch viele Daten-Resource-Records für die Zone selbst und/oder für Kindzonen hat. Der Begriff wird in [RFC4956] und [RFC5155] verwendet, ist dort aber nicht definiert.
Wildcard (Platzhalter): [RFC1034] definierte "Wildcard", aber auf eine Weise, die sich als verwirrend für Implementierer herausstellte. Spezielle Behandlung wird RRs mit Owner-Namen gegeben, die mit dem Label "*" beginnen. "Solche RRs werden 'Wildcards' genannt. Wildcard-RRs können als Anweisungen zur Synthese von RRs betrachtet werden." (Zitiert aus [RFC1034], Abschnitt 4.3.3) Für eine erweiterte Diskussion von Wildcards, einschließlich klarerer Definitionen, siehe [RFC4592].
Verdeckter Name (Occluded name): "Das Hinzufügen eines Delegationspunkts über dynamisches Update wird alle untergeordneten Domänennamen in einen Schwebezustand versetzen, immer noch Teil der Zone, aber nicht verfügbar für den Suchprozess. Das Hinzufügen eines DNAME-Resource-Records hat denselben Einfluss. Die untergeordneten Namen werden als 'verdeckt' bezeichnet." (Zitiert aus [RFC5936], Abschnitt 3.5)
Fast Flux DNS: Dies "tritt auf, wenn eine Domäne in DNS mit A-Records zu mehreren IP-Adressen gefunden wird, von denen jede einen sehr kurzen Time-to-Live (TTL)-Wert zugeordnet hat. Dies bedeutet, dass die Domäne über einen kurzen Zeitraum zu variierenden IP-Adressen aufgelöst wird." (Zitiert aus [RFC6561], Abschnitt 1.1.5, mit korrigiertem Tippfehler) Es wird oft verwendet, um Malware zu verbreiten. Da sich die Adressen so schnell ändern, ist es schwierig, alle Hosts zu ermitteln. Es sollte bemerkt werden, dass die Technik auch mit AAAA-Records funktioniert, aber eine solche Verwendung wird zum Zeitpunkt dieses Schreibens im Internet nicht häufig beobachtet.