4. Transport

Dieser Abschnitt beschreibt die Transportprotokoll-Anforderungen für AXFR. Die ursprüngliche DNS-Spezifikation definierte AXFR für den Betrieb über TCP, und dies bleibt der einzige standardisierte Transport für AXFR.

4.1. TCP

AXFR MUSS TCP als Transportprotokoll verwenden. TCP bietet zuverlässige, geordnete und fehlergeprüfte Datenübertragung, die für die Integrität von Zonentransfers wesentlich ist.

4.1.1. AXFR-Client-TCP

Ein AXFR-Client stellt eine TCP-Verbindung zum DNS-Port des AXFR-Servers her (typischerweise Port 53, obwohl andere Ports konfiguriert werden KÖNNEN).

Verbindungsaufbau:

1. Der AXFR-Client initiiert den TCP-Drei-Wege-Handshake, um eine Verbindung mit dem AXFR-Server herzustellen.

2. Sobald die TCP-Verbindung hergestellt ist, sendet der AXFR-Client die AXFR-Abfragenachricht wie in Abschnitt 2.1 spezifiziert.

3. Der AXFR-Client wartet dann darauf, dass der AXFR-Server mit einer oder mehreren DNS-Antwortnachrichten antwortet, die die Zonendaten enthalten.

Verbindungspersistenz:

1. Der AXFR-Client SOLLTE die TCP-Verbindung offen halten, bis der vollständige Zonentransfer empfangen wurde, wie durch den Empfang des finalen SOA-RR im Answer-Abschnitt einer Antwortnachricht angezeigt.

2. Nach Erhalt des vollständigen Zonentransfers KANN der AXFR-Client die TCP-Verbindung schließen oder KANN sie offen halten, um zusätzliche Abfragen zu senden (obwohl dies kein typisches Verhalten für AXFR ist).

3. Der AXFR-Client MUSS darauf vorbereitet sein, dass der AXFR-Server die TCP-Verbindung jederzeit schließt, auch unmittelbar nach Abschluss des Zonentransfers.

Timeouts:

1. Der AXFR-Client SOLLTE Lese- und Schreib-Timeouts implementieren, um nicht reagierende Server oder Netzwerkprobleme zu erkennen.

2. Empfohlene Timeout-Werte variieren je nach Zonengröße und Netzwerkbedingungen, aber ein typischer Lese-Timeout könnte im Bereich von Minuten liegen (z.B. 5-10 Minuten), um große Zonen zu berücksichtigen.

3. Wenn ein Timeout auftritt, SOLLTE der AXFR-Client die TCP-Verbindung schließen und den Zonentransfer als fehlgeschlagen behandeln.

Fehlerbehandlung:

1. Wenn der AXFR-Client eine DNS-Antwortnachricht mit einem anderen RCODE als NOERROR erhält, MUSS er den Zonentransfer als fehlgeschlagen behandeln und die TCP-Verbindung schließen.

2. Wenn der AXFR-Client eine fehlerhafte DNS-Nachricht oder eine Nachricht erhält, die nicht dem AXFR-Protokoll entspricht, SOLLTE er die TCP-Verbindung schließen und den Zonentransfer als fehlgeschlagen behandeln.

3. Wenn die TCP-Verbindung vorzeitig geschlossen wird (bevor der finale SOA-RR empfangen wird), MUSS der AXFR-Client den Zonentransfer als fehlgeschlagen behandeln und alle empfangenen partiellen Zonendaten verwerfen.

Mehrere Abfragen:

1. Ein AXFR-Client KANN mehrere AXFR-Abfragen über dieselbe TCP-Verbindung senden, eine Praxis, die als "Pipelining" oder "Verbindungswiederverwendung" bekannt ist. Dieses Verhalten ist jedoch nicht weit verbreitet implementiert oder erforderlich.

2. Wenn ein AXFR-Client mehrere Abfragen sendet, MUSS er auf die vollständige Antwort auf die erste Abfrage (einschließlich des finalen SOA-RR) warten, bevor er die nächste Abfrage sendet.

3. Ein AXFR-Server ist nicht verpflichtet, mehrere Abfragen pro Verbindung zu unterstützen und KANN die Verbindung nach der Antwort auf eine einzelne Abfrage schließen.

4.1.2. AXFR-Server-TCP

Ein AXFR-Server wartet auf eingehende TCP-Verbindungen an seinem DNS-Port (typischerweise Port 53).

Verbindungsbehandlung:

1. Nach dem Akzeptieren einer TCP-Verbindung wartet der AXFR-Server darauf, eine DNS-Abfragenachricht vom AXFR-Client zu empfangen.

2. Der AXFR-Server analysiert die Abfragenachricht, um zu bestimmen, ob es sich um eine gültige AXFR-Abfrage handelt (wie in Abschnitt 2.1 definiert).

3. Basierend auf der Abfrage und den anwendbaren Richtlinien (z.B. ACLs, TSIG-Authentifizierung) antwortet der AXFR-Server entweder mit den Zonendaten oder mit einer Fehlermeldung.

Antwortübertragung:

1. Wenn der Zonentransfer autorisiert ist, sendet der AXFR-Server eine oder mehrere DNS-Antwortnachrichten, die die Zonendaten enthalten, wie in Abschnitt 2.2 spezifiziert.

2. Jede Antwortnachricht wird als vollständige DNS-Nachricht über die TCP-Verbindung gesendet. Der AXFR-Server MUSS sicherstellen, dass Nachrichtengrenzen erhalten bleiben (d.h. jeder DNS-Nachricht geht ein 2-Byte-Längenfeld voraus, wie in RFC 1035 Abschnitt 4.2.2 spezifiziert).

3. Der AXFR-Server sendet weiterhin Antwortnachrichten, bis alle Zonendaten (einschließlich des finalen SOA-RR) übertragen wurden.

Verbindungsbeendigung:

1. Nach der Übertragung der finalen Antwortnachricht (die den abschließenden SOA-RR enthält) KANN der AXFR-Server die TCP-Verbindung sofort schließen oder KANN sie offen halten, um zusätzliche Abfragen zu akzeptieren.

2. Der AXFR-Server SOLLTE inaktive Verbindungen nach einer angemessenen Timeout-Periode schließen, um Ressourcen freizugeben.

3. Der AXFR-Server KANN die Verbindung jederzeit schließen, wenn ein Fehler auftritt (z.B. ein Schreibfehler, ein Timeout oder ein interner Fehler).

Parallelität:

1. Ein AXFR-Server SOLLTE in der Lage sein, mehrere gleichzeitige AXFR-Sitzungen zu handhaben (d.h. mehrere TCP-Verbindungen von verschiedenen Clients).

2. Der AXFR-Server KANN Limits für die Anzahl gleichzeitiger Zonentransfers auferlegen, um Ressourcenerschöpfung zu verhindern.

4.2. UDP

AXFR über UDP ist nicht standardisiert und DARF NICHT in Allzweck-DNS-Implementierungen verwendet werden. Während frühe DNS-Spezifikationen die Möglichkeit von AXFR über UDP für kleine Zonen erwähnten, hat dieser Ansatz erhebliche Einschränkungen:

1. Zuverlässigkeit: UDP ist ein unzuverlässiges Protokoll und garantiert weder die Zustellung noch die Reihenfolge von Paketen.

2. Nachrichtengröße: DNS-Nachrichten über UDP sind in der Größe begrenzt (typischerweise 512 Bytes ohne EDNS(0) oder bis zu 4096 Bytes mit EDNS(0)), was es für die meisten Zonentransfers unpraktisch macht.

3. Keine Standardisierung: Es gibt kein standardisiertes Format oder Verhalten für AXFR über UDP in modernen DNS-Spezifikationen.

Aus diesen Gründen wird AXFR über UDP als veraltet betrachtet und DARF NICHT in neuer DNS-Software implementiert werden. Alle Verweise auf AXFR über UDP in älteren DNS-Dokumenten sind historisch und sollten ignoriert werden.

Empfehlung: AXFR-Clients und -Server MÜSSEN TCP verwenden. Wenn aus irgendeinem Grund UDP-basierte Zonensynchronisation benötigt wird, sollten Implementierer die Verwendung von IXFR [RFC1995] über UDP in Betracht ziehen, obwohl selbst IXFR typischerweise über TCP durchgeführt wird.