~2026-25621-16: RFC 5936, Abstract

2026-04-27T15:25:15Z

RFC 5936, Abstract

Neue Seite

Der '''inkrementelle Zonentransfer''' (vom englischen ''{{lang|en|Incremental Zone Transfer}}'', kurz ''IXFR'' genannt) ist ein Verfahren, das im [[Domain Name System]] des [[Internet]]s zum Aktualisieren von [[Zonendatei]]en verwendet wird. Es regelt die Kommunikation zwischen einem Primary-Nameserver, der über die aktuellen Daten verfügt, und den Secondary-Nameservern, deren Daten aktualisiert werden sollen.

== Ziele ==

Ziel des inkrementellen Zonentransfers ist es, die Menge der zu übertragenden Daten zu minimieren. Im Gegensatz zum vollständigen [[Zonentransfer]] ''{{lang|en|Authoritative Transfer}}'' (AXFR) werden deshalb nur die geänderten Sätze vom Primary zu den Secondaries kopiert. Die Einsparungen können besonders beim [[Zonentransfer#Notify-Verfahren|Notify-Verfahren]] erheblich sein. Bei einer Zone mit 10.000 {{lang|en|Resource Records}}, die häufig geändert wird und von einem Primary an vier Secondaries verteilt werden muss, wäre der Aufwand, mit AXFR bei jeder Änderung die komplette Zone zu übertragen, unverhältnismäßig groß.

Um sicherzustellen, dass zwischen Primary und Secondaries keine Inkonsistenzen des Datenbestands entstehen, ist auf dem Primary eine aufwändige Buchführung aller Änderungen erforderlich. Informationen über neue oder gelöschte RRs werden zunächst gesammelt und in einer Datei gesichert. Je nach [[Domain Name System|DNS]]-Servertyp existieren dazu unterschiedliche Verfahren. Der freie DNS-Server ''[[BIND]]'' zum Beispiel speichert alle (dynamischen) Änderungen in sogenannten Journal-Files.

== Einschränkungen ==

Der inkrementelle Zonentransfer ist praktisch nur beim Notify-Verfahren sinnvoll. Beim Einsatz von BIND-Nameservern ist zu beachten, dass nur [[Dynamisches Update|dynamische Updates]] einbezogen werden. Bei manuellen Änderungen eines Zonefiles muss nämlich ein BIND-Server zurückgesetzt werden, was einen kompletten Zonentransfer nach sich zieht.

== Weitere Details ==

Der IXFR wird vom Secondary mit einer [[User Datagram Protocol|UDP]]-Message (DNS-Query-Typ 251) eingeleitet. Der Primary sendet daraufhin eine Liste mit allen Änderungen. Ein Listenelement enthält dabei den [[SOA Resource Record|SOA-RR]] und den geänderten RR (u. U. auch mehrere RRs). Bei einem gelöschten RR wird der SOA-RR ''vor'' dem Löschen und bei einem hinzugefügten RR der SOA ''nach'' dem Hinzufügen verwendet. Der Secondary arbeitet die empfangene Liste ab und synchronisiert sich so mit dem Primary.

Pro Änderung wird also ein Listenelement mit mindestens zwei RRs übertragen. Bei sehr vielen Änderungen kann ein inkrementeller Zonentransfer umfangreicher sein als ein vollständiger. Ein Primary darf in derartigen Fällen auf einen IXFR-Request eines Secondaries mit einem AXFR reagieren. In anderen Fällen heben sich Änderungen auf. So kann es etwa vorkommen, dass ein neuer Name hinzugefügt und wenig später wieder entfernt wird. Der Primary kann dann diese irrelevanten Zwischenschritte bei der Übertragung der Liste weglassen.

== Weblinks ==
* {{RFC-Internet |Autor=M. Ohta |RFC=1995 |Titel=Incremental Zone Transfer in DNS |Datum=1996-08}}

[[Kategorie:Domain Name System]]

Inkrementeller Zonentransfer - Versionsgeschichte

~2026-25621-16: RFC 5936, Abstract