1. Einleitung

Die Standardmechanismen des Domain Name Systems zur Aufrechterhaltung kohärenter Server für eine Zone bestehen aus drei Elementen. Authoritative Transfer (AXFR) ist definiert in "Domain Names - Concepts and Facilities" [RFC1034] (in diesem Dokument als RFC 1034 bezeichnet) und "Domain Names - Implementation and Specification" [RFC1035] (fortan RFC 1035). Incremental Zone Transfer (IXFR) ist definiert in "Incremental Zone Transfer in DNS" [RFC1995]. Ein Mechanismus zur prompten Benachrichtigung über Zonenänderungen (NOTIFY) ist definiert in "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. Das Ziel dieser Mechanismen ist es, einer Gruppe von DNS-Nameservern zu ermöglichen, kohärent autoritativ für eine gegebene Zone zu bleiben.

Dieses Dokument spezifiziert den AXFR-Mechanismus neu, wie er im Internet weitläufig eingesetzt wird, hoffentlich mit der von modernen Internet-Standards erwarteten Präzision, und aktualisiert dadurch RFC 1034 und RFC 1035.

1.1. Begriffsdefinitionen

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in "Key words for use in RFCs to Indicate Requirement Levels" [BCP14] beschrieben zu interpretieren.

Die Verwendung von "newer"/"new" und "older"/"old" DNS bezieht sich auf Implementierungen, die nach bzw. vor der Veröffentlichung dieses Dokuments geschrieben wurden.

"Allzweck-DNS-Implementierung" bezieht sich auf DNS-Software, die für weitverbreitete Nutzung entwickelt wurde. Dies umfasst Resolver und Server, die frei als Bibliotheken und eigenständige Prozesse zugänglich sind. Dies umfasst auch proprietäre Implementierungen, die nur zur Unterstützung von DNS-Dienstangeboten verwendet werden.

"Turnkey-DNS-Implementierung" bezieht sich auf maßgeschneiderte Einmal-Implementierungen von DNS. Solche Implementierungen bestehen aus Software, die das DNS-Protokoll-Nachrichtenformat verwendet, jedoch nicht dem gesamten Funktionsumfang von DNS entspricht.

Die Begriffe "AXFR-Sitzung", "AXFR-Server" und "AXFR-Client" werden im ersten Absatz von Abschnitt 2 eingeführt, nachdem mehr Kontext geschaffen wurde.

1.2. Geltungsbereich

Allgemein gesprochen können autoritative Nameserver für eine gegebene Zone verschiedene Mittel verwenden, um die Kohärenz der von ihnen bereitgestellten Zoneninhalte zu erreichen. Beispielsweise gibt es DNS-Implementierungen, die Antworten aus in relationalen Datenbanken gespeicherten Daten zusammenstellen (im Gegensatz zu Masterdateien) und sich auf die Nicht-DNS-Mittel der Datenbank zur Synchronisierung der Datenbankinstanzen verlassen. Einige dieser Nicht-DNS-Lösungen interoperieren auf irgendeine Weise. AXFR, IXFR und NOTIFY sind jedoch die einzigen protokolldefinierten Inband-Mechanismen zur Bereitstellung von Kohärenz einer Gruppe von Nameservern, und sie sind die einzigen vom IETF spezifizierten Mechanismen.

Dieses Dokument deckt inkohärente DNS-Situationen nicht ab. Es gibt Anwendungen des DNS, bei denen Server für eine Zone nicht kohärent sein sollen.

1.3. Kontext

Ein AXFR-Client sendet eine Anfrage, um den Inhalt einer Zone von einem AXFR-Server zu empfangen. Solche Übertragungen sind ein DNS-Abfragetyp und entsprechen den DNS-Protokollspezifikationen, einschließlich Abfrage-Header und Antwortnachrichten.

Der Zoneninhalt besteht aus den autoritativen DNS-RRs, die zu Domainnamen innerhalb der Zone gehören. Typischerweise werden alle autoritativen RRs für eine Zone durch eine AXFR-Sitzung übertragen, mit einer Ausnahme. Beim Folgen eines Zonenschnitts werden Glue-Records nicht übertragen.

Ein Zonentransfer wird durch den DNS-SOA-Refresh-Timer, eine NOTIFY-Nachricht oder Eingriff eines Operators initiiert (wobei andere Mittel nicht ausgeschlossen sind). Ein AXFR ist oft auf Server beschränkt, die speziell als sekundär zu den primären Servern für die Zone konfiguriert sind, und Anfragen von anderen Clients werden abgelehnt.

Die ursprüngliche 1035-Definition von AXFR spezifizierte die Ausführung über TCP. Diese Spezifikation unterstützt nur AXFR über TCP. Der Vollständigkeit halber erwähnt diese Spezifikation jedoch AXFR-über-UDP in einem informativen Anhang.

Eine AXFR-Sitzung besteht aus einer AXFR-Anfragenachricht, einer oder mehreren AXFR-Antwortnachrichten und schließlich der Beendigung der TCP-Verbindung. Eine AXFR-Sitzung wird als "erfolgreich" bezeichnet, wenn die folgenden zwei Bedingungen erfüllt sind: (1) der AXFR-Client hat eine erfolgreiche AXFR-Antwortsequenz erhalten, und (2) der AXFR-Client hat die TCP-Verbindung geschlossen oder der Client hat eine Bestätigung erhalten, dass der AXFR-Server die TCP-Verbindung geschlossen hat.

Dieses Dokument behandelt nicht die Sicherheit von Zonentransfers. Die relevanten Sicherheitsüberlegungen werden in Abschnitt 8 diskutiert.

1.4. Abdeckung und Beziehung zur ursprünglichen AXFR-Spezifikation

Dieses Dokument behandelt eine autoritative, nicht DNS-UPDATE-bewusste, primär-zu-sekundär AXFR-Sitzung ohne eingesetzte Sicherheit, und die übertragene Zone ist eine "normale" DNS-Zone für IPv4-Transport. Das heißt, der Server ist ein Master oder Primärserver für die Zone und der Client ist ein sekundärer oder Slave-Server. Die Definition wurde in einer Weise geschrieben, die einen Erweiterungsmechanismus zur Angabe der Abdeckung zusätzlicher Parameterwerte ermöglichen soll.

Zur Referenz notiert dieses Dokument Folgendes (definiert jedoch keine dieser Varianten):

• Zonentransfers können zwischen einem Slave und einem anderen Slave durchgeführt werden (alle sind autoritative Server).

• Ein Zonentransfer-Client kann ein Resolver oder ein Zonenvalidator sein, der Daten sammelt (nicht-autoritative Anwendungen).

• Es gibt eine optionale Protokollerweiterung, die "inkrementelle Übertragungen" ermöglicht -- Incremental Zone Transfer (IXFR) [RFC1995].

• DNSSEC (über RFC 4033 [RFC4033], RFC 4034 [RFC4034] und RFC 4035 [RFC4035]) definiert ein Sicherheitsprotokoll für DNS.

• DNS UPDATE (RFC 2136 [RFC2136]) bietet ein Mittel, durch das eine Zone dynamisch aktualisiert werden kann.

• IPv6-Transport kann verwendet werden.

Das Ziel, diese zu erwähnen, besteht darin, klarzustellen, dass, während die in diesem Dokument beschriebenen Mechanismen nur auf ein spezifisches Szenario anwendbar sind, es verwandte Szenarien gibt, die auf dieses Dokument verweisen, um Kontext bereitzustellen. Die aufgelisteten Varianten sind nicht alle äquivalent, sicherlich nicht unabhängig voneinander, und können innerhalb oder außerhalb des Geltungsbereichs dieses Dokuments liegen.

Dieses Dokument hat absichtlich einen engen Geltungsbereich, ist aber so geschrieben, dass es anzeigt, dass es einen erweiterbaren Mechanismus beschreibt.