2. AXFR-Nachrichten

Eine AXFR-Sitzung besteht aus einer einzelnen TCP-Verbindung und wird durch eine DNS-Abfragenachricht initiiert. Diese Abfragenachricht bestimmt die zu übertragende Zone und bestimmte Eigenschaften der Sitzung. Nach der Abfrage folgt die Übertragung des Zoneninhalts, vorausgesetzt eine erfolgreiche Abfrage, und dann eine Verbindungsbeendigung.

Die folgenden Definitionen werden in diesem Dokument verwendet. Der "AXFR-Client" ist der Host, der die TCP-Verbindung initiiert und die DNS-AXFR-Abfrage sendet. Der "AXFR-Server" ist der Host, der die AXFR-Abfrage empfängt und die AXFR-Antwort(en) sendet. Eine "AXFR-Sitzung" besteht aus einer AXFR-Abfrage und der Sequenz von AXFR-Antworten, die dieser Abfrage entsprechen.

Ein AXFR ist einer von mehreren Abfragetypen (QTYPE), die für DNS definiert sind; im Gegensatz zu den meisten Abfragetypen kann AXFR jedoch mehrere DNS-Nachrichten erfordern, um vollständig auf eine Abfrage zu antworten. Das Format der anfänglichen Abfrage und der Antwortnachrichten sind Standard-DNS-Nachrichten, definiert in RFC 1035 und nachfolgenden Dokumenten. Einige Felder in der DNS-Nachricht sind weiter eingeschränkt, wenn der Abfragetyp ein AXFR ist.

In diesem gesamten Dokument werden AXFR-Abfragen und -Antworten in Abschnitte unterteilt, die der Struktur der DNS-Nachricht folgen. Die fünf Abschnitte sind: (1) Header, (2) Question, (3) Answer, (4) Authority und (5) Additional.

Dieser Abschnitt dokumentiert die Abfrage- und Antwortnachrichten, einschließlich Einschränkungen für die Abfragen und Anforderungen an die Server. Dies behandelt auch die Verwendung der TCP-Verbindung.

2.1. AXFR-Abfrage

Dieser Unterabschnitt beschreibt das Format und die Semantik der Abfragenachricht, die eine AXFR-Sitzung initiiert. Der Begriff "normales DNS" wird verwendet, um Verhalten zu beschreiben, das durch die Standard-DNS-Spezifikation (RFC 1034, RFC 1035 und Aktualisierungen) geregelt wird.

Eine AXFR-Abfrage ist wie eine normale DNS-Abfragenachricht mit QTYPE AXFR; es werden jedoch zusätzliche Einschränkungen für eine "wohlgeformte AXFR-Abfrage" auferlegt. Ein AXFR-Client, der eine AXFR-Abfrage sendet, SOLLTE den Regeln für eine wohlgeformte Abfrage entsprechen. Ein AXFR-Server MUSS auf eine AXFR-Abfrage, die diesen Regeln nicht entspricht, auf dieselbe Weise antworten, wie er auf jede falsch formatierte Abfrage antworten würde. (Dies ist typischerweise eine FORMERR-Antwort.)

Eine wohlgeformte AXFR-Abfrage hat folgende Eigenschaften:

1. Der OPCODE des DNS-Headers MUSS Null sein (eine Standardabfrage).

2. Der Question-Section-Count des DNS-Headers (QDCOUNT) MUSS 1 sein.

3. Der Answer-Section-Count des DNS-Headers (ANCOUNT), der Authority-Section-Count (NSCOUNT) und der Additional-Section-Count (ARCOUNT) MÜSSEN alle 0 sein.

4. Der Question-Abschnitt MUSS eine einzelne Frage mit folgenden Eigenschaften enthalten:

   • QTYPE gleich AXFR [RFC5395] (252 dezimal);
   • QCLASS gleich der Zonenklasse oder ANY;
   • QNAME gleich dem Namen der zu übertragenden Zone.

5. AXFR-Antworten KÖNNEN eine höhere DNS-Protokollversion als die Abfrage haben.

2.1.1. Header-Werte

QR: MUSS 0 sein (Abfrage)

OPCODE: MUSS 0 sein (Standardabfrage)

AA: Wird nicht untersucht (für eine Abfrage irrelevant)

TC: MUSS 0 sein (Nicht abgeschnitten) - Eine AXFR-Abfrage mit TC auf 1 gesetzt ist falsch formatiert.

RD: KANN 0 oder 1 sein - Das Recursion-Desired-Bit wird vom AXFR-Server ignoriert; es beeinflusst weder das Verhalten einer AXFR-Abfrage noch spielt es eine Rolle bei autoritativen Übertragungen. Die Einstellung des RD-Bits in einer AXFR-Abfragenachricht ist kein zuverlässiger Indikator dafür, dass die Abfrage eine rekursive Abfrage ist.

RA: Wird nicht untersucht (nur in Antworten verwendet)

Z: MUSS 0 sein (für zukünftige Verwendung reserviert) - Gemäß der Anforderung der DNS-Spezifikation MÜSSEN die reservierten Bits in einer Abfrage Null sein und MÜSSEN in einer Antwort ignoriert werden. Daher MUSS ein AXFR-Client die Z-Bits auf Null setzen, und ein AXFR-Server MUSS ihren Wert ignorieren. Eine AXFR-Abfrage mit einem der reservierten (Z) Bits auf einen Nicht-Null-Wert gesetzt ist falsch formatiert.

AD: MUSS 0 sein - Das Authentic-Data-Bit ist nur für Antworten definiert [RFC4035].

CD: KANN 0 oder 1 sein - Das Checking-Disabled-Bit ist nur für Antworten relevant, daher hat es keine definierte Bedeutung für eine Zonentransfer-Abfrage. Ein AXFR-Client KANN dieses Bit setzen; ein AXFR-Server MUSS seinen Wert ignorieren.

RCODE: MUSS 0 sein (Kein Fehler) - Das Response-Code-Feld ist nur für Antworten definiert.

QDCOUNT: MUSS 1 sein

ANCOUNT: MUSS 0 sein

NSCOUNT: MUSS 0 sein

ARCOUNT: MUSS 0 sein oder KANN größer als Null sein, wenn die Abfrage EDNS(0) [RFC2671], TSIG [RFC2845] oder SIG(0) [RFC2931] Optionen enthält.

Für EDNS(0), TSIG und SIG(0) Überlegungen siehe Abschnitt 2.2.5.

2.1.2. Question-Abschnitt

Der Question-Abschnitt MUSS dem in RFC 1035 spezifizierten entsprechen und eine einzelne Frage mit folgenden Eigenschaften enthalten:

QNAME: Der Name der zu übertragenden Zone, der ein gültiger DNS-Domainname sein MUSS.

QTYPE: Der Wert ist 252 (für AXFR) gemäß [RFC5395].

QCLASS: Die Klasse der zu übertragenden Zone. Da AXFR-Abfragen ein erhebliches Sicherheitsrisiko darstellen können, wird ein AXFR-Server den Zonentransfer-Zugriff wahrscheinlich durch eine Richtlinie einschränken (über Zugriffskontrolllisten, TSIG-Authentifizierung usw.), und ein Zonentransfer sollte nicht jedem Anfrager bereitgestellt werden. Der spezielle QCLASS-Wert * (ANY, 255 dezimal) KANN aus Gründen der Rückwärtskompatibilität verwendet werden. Wenn QCLASS ANY ist, soll ein AXFR-Server nicht Zonendaten für alle verfügbaren Klassen von Daten zurückgeben, sondern kann eine Klasse auswählen und diese Zone übertragen oder die Abfrage ablehnen. (Letzteres wird für eine Allzweck-DNS-Implementierung EMPFOHLEN.) Sorgfältig geschriebene AXFR-Clients fordern Zonentransfers über spezifische Klassen an.

2.1.3. Answer-Abschnitt

Der Answer-Abschnitt MUSS in einer AXFR-Abfrage leer sein (ANCOUNT muss 0 sein).

2.1.4. Authority-Abschnitt

Der Authority-Abschnitt MUSS in einer AXFR-Abfrage leer sein (NSCOUNT muss 0 sein).

2.1.5. Additional-Abschnitt

Der Additional-Abschnitt einer AXFR-Abfragenachricht kann EDNS(0)-Ressourceneinträge (RRs) [RFC2671] enthalten, um EDNS-Unterstützung und Parameter anzuzeigen. Er kann auch TSIG [RFC2845] oder SIG(0) [RFC2931] RRs für Authentifizierungszwecke enthalten. Das Vorhandensein von TSIG- oder SIG(0)-Optionen ermöglicht die Authentifizierung der AXFR-Abfrage, was potenziell permissivere Autorisierungsrichtlinien auf dem AXFR-Server ermöglicht.

Wenn EDNS(0) verwendet wird, wird der OPT-Pseudo-RR im Additional-Abschnitt platziert, und ARCOUNT wird entsprechend erhöht. Die von EDNS(0) angekündigte Versionsnummer zeigt die Bereitschaft an, für diese Version formatierte Pakete zu akzeptieren. Ein AXFR-Client, der nicht EDNS-fähig ist, setzt ARCOUNT auf 0 und schließt keinen OPT-RR ein. Ein AXFR-Server, der nicht EDNS-fähig ist, ignoriert den OPT-RR und kann die Abfrage als falsch formatiert behandeln, wenn ARCOUNT größer als 0 ist und zusätzliche Verarbeitung (Untersuchung dieser zusätzlichen RRs) aktiviert ist.

Eine AXFR-Abfrage mit einem SIG(0) hat ARCOUNT gleich 1 plus die Anzahl der OPT-RRs im Additional-Abschnitt. Ein TSIG-RR wird nicht in ARCOUNT gezählt, da TSIG eine alternative Nachrichtenauthentifizierungstechnik in DNS ist. Siehe [RFC2845] für TSIG-Überlegungen.

TSIG und EDNS(0) KÖNNEN gleichzeitig verwendet werden.

2.2. AXFR-Antwort

Dieser Unterabschnitt beschreibt das Format und die Semantik von Antworten auf AXFR-Abfragen. Antworten werden gesendet, nachdem eine TCP-Verbindung hergestellt und eine AXFR-Abfrage geparst wurde.

Ein AXFR-Server MUSS in der Lage sein, eine Abfrage mit unerwarteten, undefinierten oder nicht unterstützten Flags oder Attributen zu behandeln, indem er mit einer Standard-DNS-Fehlerantwort antwortet. Die Bedingungen, die verschiedene Fehler verursachen, werden in den folgenden Unterabschnitten erläutert.

Es gibt vier Kategorien von AXFR-Server-Antworten auf eine AXFR-Abfrage:

1. Eine fehlerhafte Antwort: Dies resultiert, wenn die über TCP empfangene AXFR-Abfrage keine legale DNS-Abfragenachricht ist oder wenn die DNS-Nachricht nicht den Anforderungen einer wohlgeformten AXFR-Abfrage entspricht, wie in Abschnitt 2.1 spezifiziert. Die Antwort auf eine fehlerhafte Abfrage SOLLTE eine einzelne DNS-Antwortnachricht mit einem geeigneten RCODE (FORMERR, NOTIMP, REFUSED usw.) sein.

2. Eine abgelehnte Antwort: Wenn eine empfangene DNS-Nachricht eine legale AXFR-Abfrage ist, aber Richtlinienüberlegungen vorschreiben, dass dieser bestimmte AXFR-Client nicht berechtigt ist, Zonentransfers durchzuführen (für die betreffende Zone oder generell), SOLLTE die Antwort eine einzelne DNS-Antwortnachricht mit RCODE REFUSED sein.

3. Eine leere Antwort: Wenn die zu übertragende Zone leer ist (alle autoritativen Daten am Zonenscheitel liegen außerhalb der Zone), SOLLTE der AXFR-Server eine einzelne Antwortnachricht mit nur einem SOA-RR im Answer-Abschnitt zurückgeben. Dieser SOA-RR ist der einzige RR in der Zone. Die Bedingungen für eine leere Zone sind sehr ungewöhnlich und resultieren aus Out-of-Band-Operationen (Zonenbearbeitungen, dynamische Updates oder andere Mittel), die alles außer dem obligatorischen SOA aus der Zone entfernt haben.

4. Eine erfolgreiche Antwort: Unter der Annahme, dass keine Richtlinien- oder Formatierungsprobleme vorliegen, antwortet der AXFR-Server mit einer oder mehreren DNS-Antwortnachrichten, die gemeinsam alle autoritativen Daten aus der übertragenen Zone enthalten, vorbehaltlich einiger spezifischer Ein- und Ausschlüsse, die in Abschnitt 3 beschrieben werden.

Die ersten drei Antworttypen werden über eine einzelne DNS-Nachricht übermittelt. Der letzte Typ, die erfolgreiche Antwort, kann aus einer oder mehreren DNS-Antwortnachrichten bestehen, die sequenziell über die TCP-Verbindung gesendet werden.

Ein AXFR-Server, der EDNS(0), TSIG oder SIG(0) implementiert, MUSS darauf vorbereitet sein, AXFR-Abfragenachrichten zu empfangen, die die entsprechenden Optionen nicht enthalten. Umgekehrt KANN ein AXFR-Server das Vorhandensein von EDNS(0)-, TSIG- oder SIG(0)-Optionen in der Abfragenachricht ignorieren (z.B. wenn er sie nicht unterstützt oder nicht benötigt). Wenn jedoch ein AXFR-Server EDNS(0), TSIG oder SIG(0) implementiert und Informationen aus diesen Optionen in der Anfrage nutzen möchte, MUSS er die entsprechenden Optionsinformationen in seinen AXFR-Antwortnachrichten einschließen.

Ein AXFR-Client MUSS darauf vorbereitet sein, AXFR-Antworten zu empfangen, in denen das TC-Bit (Truncation) nicht verwendet wird oder bedeutungslos ist. Da AXFR über TCP operiert und mehrere DNS-Nachrichten in einer Antwortsequenz verwenden darf, ist Truncation nicht notwendig. (Die Verwendung des TC-Bits wird explizit in Abschnitt 2.2.1 behandelt.)

2.2.1. Header-Werte

QR: MUSS 1 sein (Antwort)

OPCODE: MUSS 0 sein (Standardabfrage)

AA: Das AA-Bit (Authoritative Answer) SOLLTE in allen Antwortnachrichten auf 1 gesetzt werden. Obwohl der AXFR-Server wahrscheinlich autoritativ für die zu übertragende Zone ist, gibt es keine strenge Anforderung, dass dies der Fall sein muss.

TC: MUSS 0 sein (Nicht abgeschnitten) - Da AXFR über TCP operiert und mehrere Antwortnachrichten verwenden kann, ist es nicht notwendig, das TC-Bit zu setzen.

RD: Das RD-Bit in der Antwort kopiert das RD-Bit aus der Abfrage (gemäß DNS-Spezifikation). Das RD-Bit hat keine Bedeutung für AXFR; sein Wert beeinflusst das AXFR-Verhalten nicht.

RA: Das RA-Bit (Recursion Available) KANN in der Antwort gemäß den allgemeinen Richtlinien des AXFR-Servers gesetzt oder gelöscht werden. Im Fall eines Zonentransfers ist Rekursion nicht anwendbar, daher ist der Wert von RA in diesem Kontext nicht bedeutungsvoll.

Z: MUSS 0 sein (Reserviert) - Die reservierten Bits MÜSSEN von einem AXFR-Server auf Null gesetzt werden und MÜSSEN von einem AXFR-Client ignoriert werden.

AD: KANN 0 oder 1 sein - Für DNSSEC-fähige AXFR-Server, die DNSSEC-signierte Zonen bereitstellen, KANN das AD-Bit (Authentic Data) in AXFR-Antworten gemäß DNSSEC-Anforderungen [RFC4035] gesetzt werden. Für Zonen, die nicht DNSSEC-signiert sind, SOLLTE das AD-Bit 0 sein. Ein AXFR-Client, der nicht DNSSEC-fähig ist, ignoriert das AD-Bit.

CD: SOLLTE 0 sein - Das CD-Bit (Checking Disabled) ist nur für Resolver relevant, nicht für autoritative Server. Für AXFR-Antworten SOLLTE das CD-Bit 0 sein und hat keine definierte Bedeutung.

RCODE: Der Response-Code zeigt das Ergebnis der AXFR-Abfrage an. Häufige Werte sind:

• NOERROR (0): Erfolgreicher Transfer (alle Antwortnachrichten in einer erfolgreichen AXFR-Antwortsequenz haben RCODE auf NOERROR gesetzt).
• FORMERR (1): Formatfehler in der Abfrage.
• SERVFAIL (2): Serverfehler bei der Verarbeitung der Anfrage.
• NOTIMP (4): Abfragetyp nicht implementiert.
• REFUSED (5): Zonentransfer durch Richtlinie abgelehnt.
• NOTAUTH (9): Server ist nicht autoritativ für die angeforderte Zone (definiert in [RFC2136]).

Für eine erfolgreiche AXFR-Antwort MÜSSEN alle DNS-Antwortnachrichten in der AXFR-Sitzung RCODE auf NOERROR gesetzt haben. Wenn eine DNS-Antwortnachricht in einer AXFR-Sitzung RCODE auf etwas anderes als NOERROR gesetzt hat, MUSS der AXFR-Client den Zonentransfer als fehlgeschlagen betrachten.

QDCOUNT: MUSS 1 sein - Der Question-Abschnitt wird in jeder Antwortnachricht wiederholt und kopiert die Frage aus der Abfrage.

ANCOUNT: Gibt die Anzahl der RRs im Answer-Abschnitt an. Der Wert variiert je nachdem, wie viele RRs in jede Antwortnachricht passen.

NSCOUNT: MUSS 0 sein - Kein Authority-Abschnitt ist in AXFR-Antwortnachrichten enthalten.

ARCOUNT: MUSS 0 oder größer sein, wenn EDNS(0), TSIG oder SIG(0) verwendet wird. Typischerweise ist ARCOUNT 0 für AXFR-Antworten.

2.2.2. Question-Abschnitt

Der Question-Abschnitt in der Antwort MUSS identisch mit dem Question-Abschnitt in der entsprechenden AXFR-Abfrage sein. Dies bedeutet, dass QDCOUNT 1 sein MUSS und die einzelne Frage mit der Frage aus der Abfrage übereinstimmen MUSS.

2.2.3. Answer-Abschnitt

Der Answer-Abschnitt enthält die zu übertragenden Zonendaten. Die Anforderungen für den Inhalt des Answer-Abschnitts sind:

1. SOA-RRs: Der erste RR in der ersten Antwortnachricht einer AXFR-Antwort MUSS der SOA-RR für die Zone sein. Der letzte RR in der letzten Antwortnachricht einer AXFR-Antwort MUSS ebenfalls der SOA-RR für die Zone sein (d.h. derselbe SOA-RR erscheint am Anfang und am Ende der Übertragung).

2. Zwischen-RRs: Zwischen den beiden SOA-RRs (dem ersten und dem letzten) enthält der Answer-Abschnitt der Antwortnachricht(en) alle anderen autoritativen RRs für die Zone (vorbehaltlich der Einschränkungen in Abschnitt 3).

3. Reihenfolge: Die Reihenfolge der RRs im Answer-Abschnitt (außer den ersten und letzten SOA-RRs) ist undefiniert. Alle RRs desselben RRsets (gleicher Eignername, Klasse und Typ) SOLLTEN jedoch aus Effizienzgründen zusammengefasst werden.

4. Mehrere Nachrichten: Wenn die Zonendaten nicht in eine einzelne DNS-Antwortnachricht passen, sendet der AXFR-Server mehrere Antwortnachrichten. Jede Antwortnachricht nach der ersten setzt sich mit zusätzlichen Zonendaten fort, und die letzte Nachricht endet mit dem abschließenden SOA-RR.

2.2.4. Authority-Abschnitt

Der Authority-Abschnitt MUSS in AXFR-Antwortnachrichten leer sein (NSCOUNT = 0). Das Einbeziehen von NS-Records oder anderen Authority-Daten im Authority-Abschnitt einer AXFR-Antwort ist ausdrücklich verboten.

2.2.5. Additional-Abschnitt

Der Additional-Abschnitt von AXFR-Antwortnachrichten ist im Allgemeinen leer, KANN jedoch EDNS(0)-, TSIG- oder SIG(0)-RRs enthalten, wenn diese Optionen ausgehandelt wurden oder verwendet werden.

EDNS(0): Wenn die AXFR-Abfrage einen EDNS(0) OPT-RR enthielt, KANN der AXFR-Server OPT-RRs in den Additional-Abschnitten seiner Antwortnachrichten einschließen. EDNS(0) in AXFR-Antworten wird hauptsächlich zur Signalisierung erweiterter Fähigkeiten und Puffergrößen verwendet.

TSIG: Wenn TSIG zur Authentifizierung verwendet wird, werden TSIG-RRs im Additional-Abschnitt von AXFR-Antwortnachrichten eingeschlossen. TSIG-Signierung wird in Multi-Message-AXFR-Antworten unterschiedlich angewendet:

• Die erste Antwortnachricht in einer erfolgreichen AXFR-Sequenz MUSS einen TSIG-RR enthalten.
• Zwischennachrichten KÖNNEN den TSIG-RR weglassen (unsignierte Zwischennachrichten sind erlaubt).
• Die letzte Antwortnachricht MUSS einen TSIG-RR enthalten.

Siehe [RFC2845] für detaillierte TSIG-Überlegungen.

SIG(0): Wenn SIG(0) verwendet wird, wird ARCOUNT für jede Antwortnachricht, die ein SIG(0) enthält, entsprechend erhöht.

2.3. TCP-Verbindungsabbrüche

Ein AXFR-Client oder AXFR-Server KANN eine laufende AXFR-Sitzung abbrechen, indem er die TCP-Verbindung schließt. Gründe für den Abbruch einer Verbindung sind:

• Fehlerhafte oder unerwartete DNS-Nachrichten.
• Timeouts (entweder Lese- oder Schreib-Timeouts).
• Autorisierungsfehler (z.B. fehlgeschlagene TSIG-Validierung).
• Interne Serverfehler.
• Ressourcenerschöpfung.

Eine abgebrochene Verbindung MUSS vom AXFR-Client als fehlgeschlagener Zonentransfer interpretiert werden. Der AXFR-Client SOLLTE KEINE vor dem Verbindungsschluss empfangenen partiellen Zonendaten committen.

Ein AXFR-Server KANN den TCP-Verbindungsschluss als Hinweis an den AXFR-Client verwenden, dass der Zonentransfer fehlgeschlagen ist.