3. Zoneninhalt

Dieser Abschnitt beschreibt, welche DNS-Ressourceneinträge (RRs) in einer AXFR-Antwort enthalten sind und welche ausgeschlossen sind. Der Inhalt eines Zonentransfers ist nicht willkürlich; spezifische Regeln bestimmen, was enthalten ist und was nicht.

3.1. Einzuschließende Einträge

Ein AXFR-Server MUSS die folgenden RRs in einer AXFR-Antwort einschließen:

1. SOA-RR: Der SOA-RR für den Zonenscheitel MUSS als erster RR im Answer-Abschnitt der ersten Antwortnachricht und als letzter RR im Answer-Abschnitt der letzten Antwortnachricht erscheinen.

2. Alle autoritativen RRs: Alle autoritativen RRs, die zu Domainnamen innerhalb der Zone gehören, MÜSSEN eingeschlossen werden. Dies umfasst unter anderem die folgenden RR-Typen:

   • NS-RRs am Zonenscheitel
   • A, AAAA, MX, CNAME, TXT und andere Standard-RR-Typen
   • DNSSEC-bezogene RRs (DNSKEY, RRSIG, NSEC, NSEC3, DS am Zonenscheitel falls vorhanden)
   • Alle unbekannten oder experimentellen RR-Typen, die gemäß [RFC3597] definiert sind

3. RRsets: Alle RRs mit demselben Eignernamen, derselben Klasse und demselben Typ bilden ein RRset. Alle Mitglieder eines RRsets MÜSSEN im Zonentransfer enthalten sein. Es wird EMPFOHLEN, dass alle RRs desselben RRsets aus Effizienzgründen konsekutiv in der AXFR-Antwort erscheinen.

4. Leere Nicht-Terminale: Leere Nicht-Terminal (ENT) Domainnamen besitzen keine RRs, dienen aber als Platzhalter im Domainnamenbaum. Da ENTs jedoch keine RRs besitzen, werden sie nicht explizit in AXFR-Antworten dargestellt. Sie werden implizit durch die Existenz untergeordneter Namen definiert.

Ein AXFR-Server DARF Folgendes NICHT in einer AXFR-Antwort einschließen:

1. Zonenexterne Daten: RRs, die nicht zu Domainnamen innerhalb der Zone gehören, DÜRFEN NICHT eingeschlossen werden (außer Glue-Records, wie in Abschnitt 3.3 beschrieben).

2. Nicht-autoritative Daten: Zwischengespeicherte Daten, Hinweise oder andere nicht-autoritative Informationen DÜRFEN NICHT eingeschlossen werden.

3. OPT-RRs im Answer-Abschnitt: EDNS(0) OPT-Pseudo-RRs sind keine Zonendaten und DÜRFEN NICHT im Answer-Abschnitt erscheinen. Sie DÜRFEN nur im Additional-Abschnitt erscheinen.

3.2. Delegierungseinträge

Ein Zonenschnitt (Delegierungspunkt) ist ein Domainname in einer Zone, bei dem die Autorität an eine andere Zone delegiert wird. An einem Zonenschnitt zeigen NS-RRs die Delegierung an. Die Behandlung von Delegierungseinträgen in AXFR ist nuanciert.

Delegierungs-NS-RRs: NS-RRs an einem Zonenschnitt (die Autorität an eine Kindzone delegieren) MÜSSEN in der AXFR-Antwort enthalten sein. Diese NS-RRs sind autoritativ für die Elternzone und zeigen an, wohin die Autorität delegiert wurde.

Beispiel: Wenn die Zone example.com eine Delegierung an child.example.com enthält, MÜSSEN die NS-RRs für child.example.com in der AXFR-Antwort für example.com enthalten sein.

DS-RRs an Zonenschnitten: Für DNSSEC-signierte Zonen KÖNNEN DS-RRs (Delegation Signer) an einem Zonenschnitt in der Elternzone erscheinen. DS-RRs an einem Delegierungspunkt MÜSSEN in der AXFR-Antwort für die Elternzone enthalten sein.

Andere RR-Typen an Zonenschnitten: An einem Zonenschnitt sind nur NS-RRs (und optional DS-RRs für DNSSEC) in der Elternzone autoritativ. Andere RR-Typen, die möglicherweise unter demselben Domainnamen existieren, sind entweder:

• Glue-Records (siehe Abschnitt 3.3), oder
• Vom Zonenschnitt verdeckt (siehe Abschnitt 3.5).

An einem Zonenschnitt in der Elternzone existieren keine anderen autoritativen RR-Typen (außer NS und DS).

3.3. Glue-Records

Glue-Records sind Adresseinträge (A oder AAAA), die außerhalb des autoritativen Bereichs der Zone existieren, aber notwendig sind, um zirkuläre Abhängigkeiten bei der Auflösung der Nameserver der Zone zu verhindern.

Definition: Glue-Records sind A- oder AAAA-RRs, die IP-Adressen für in den NS-RRs der Zone aufgelistete Nameserver bereitstellen, wobei diese Nameserver in einer delegierten Kindzone residieren.

Beispiel: Wenn example.com an child.example.com delegiert und einer der NS-RRs für child.example.com ns1.child.example.com ist, wäre ein A- oder AAAA-RR für ns1.child.example.com Glue im Kontext der Zone example.com.

AXFR-Verhalten:

1. Glue-Records DÜRFEN NICHT in einer AXFR-Antwort enthalten sein. Glue-Records sind zonenexterne Daten und nicht autoritativ für die zu übertragende Zone. Der AXFR-Server DARF KEINE Glue-Records im Answer-Abschnitt einer AXFR-Antwort senden.

2. Der AXFR-Client ist dafür verantwortlich, Glue-Records auf andere Weise zu erhalten (z.B. durch Abfrage der Kindzone oder durch Rückgriff auf zwischengespeicherte Daten).

Begründung: Die Einbeziehung von Glue-Records in AXFR-Antworten würde autoritative und nicht-autoritative Daten vermischen, was möglicherweise zu Verwirrung und Inkonsistenz führt. Durch den Ausschluss von Glue-Records enthält die AXFR-Antwort nur autoritative Daten für die Zone.

Historische Anmerkung: Einige ältere DNS-Implementierungen schlossen Glue-Records in AXFR-Antworten ein. Moderne Implementierungen DÜRFEN KEINE Glue-Records einschließen, da dieses Verhalten nicht standardkonform ist und zu Interoperabilitätsproblemen führen kann.

3.4. Namenskompression

Das DNS-Nachrichtenformat unterstützt Namenskompression, eine Technik zur Reduzierung der Größe von DNS-Nachrichten durch Ersetzen wiederholter Domainnamen durch Zeiger auf frühere Vorkommen desselben Namens innerhalb der Nachricht.

AXFR und Namenskompression:

1. Namenskompression KANN innerhalb einzelner AXFR-Antwortnachrichten verwendet werden. Jede DNS-Nachricht in einer AXFR-Sequenz ist in Bezug auf Namenskompression unabhängig; Zeiger DÜRFEN NICHT auf Namen in vorherigen oder nachfolgenden Nachrichten verweisen.

2. Namenskompression ist in AXFR-Antworten besonders vorteilhaft, da viele RRs gemeinsame Domainnamen-Suffixe teilen (z.B. den Zonennamen selbst).

3. Ein AXFR-Server SOLLTE Namenskompression verwenden, um Bandbreite zu reduzieren und die Effizienz zu verbessern, ist aber nicht verpflichtet, dies zu tun.

4. Ein AXFR-Client MUSS Namenskompression unterstützen und Namen in AXFR-Antworten korrekt dekomprimieren.

3.5. Verdeckte Namen

Ein verdeckter Name ist ein Domainname, der normalerweise innerhalb einer Zone wäre, aber aufgrund eines Zonenschnitts aus der Sicht der Zone verborgen ist. Verdeckte Namen existieren untergeordnet zu einem Delegierungspunkt.

Beispiel: Wenn example.com an child.example.com delegiert, sind alle Domainnamen, die child.example.com untergeordnet sind (wie www.child.example.com oder ftp.child.example.com), aus der Perspektive der Zone example.com verdeckt.

AXFR-Verhalten:

1. Verdeckte Namen und ihre zugehörigen RRs DÜRFEN NICHT in einer AXFR-Antwort für die Elternzone enthalten sein. Nur der Zonenschnitt (die NS-RRs am Delegierungspunkt) ist enthalten.

2. Der Inhalt der delegierten Zone (child.example.com im Beispiel) wird nur über eine AXFR-Sitzung übertragen, die speziell für diese Zone bestimmt ist.

Begründung: Die Einbeziehung verdeckter Namen in die AXFR-Antwort einer Elternzone würde die hierarchische Struktur des DNS verletzen und Daten aus mehreren Zonen vermischen.

Sonderfall - DNAME: Wenn eine Zone einen DNAME-RR [RFC2672] enthält, erzeugt der DNAME eine Umleitung, und alle Namen, die dem DNAME-Eigentümer untergeordnet sind, werden effektiv auf dieselbe Weise verdeckt wie Namen, die einer Delegierung untergeordnet sind. DNAME-verdeckte Namen DÜRFEN NICHT in einer AXFR-Antwort enthalten sein.