Zonen\u00fcbergang beschreibt die Replikation von DNS-Zonendaten zwischen Nameservern innerhalb einer Domain-Infrastruktur. Der prim\u00e4re Nameserver \u00fcbertr\u00e4gt seine authoritative Zonendatei an einen oder mehrere sekund\u00e4re Server, damit diese bei Ausfall des Master-Systems oder zur Lastverteilung DNS-Anfragen beantworten k\u00f6nnen. Dieses Verfahren gew\u00e4hrleistet Hochverf\u00fcgbarkeit und geografische Redundanz im Domain Name System.<\/p>\n
Ein Zonen\u00fcbergang beginnt, wenn ein sekund\u00e4rer Nameserver eine Aktualisierung seiner lokalen Zonenkopie ben\u00f6tigt. Der Slave-Server pr\u00fcft regelm\u00e4\u00dfig die Seriennummer (Serial) im SOA-Record der Zone auf dem Master-Server, um \u00c4nderungen zu erkennen. Steigt diese Seriennummer, fordert der Slave einen Transfer an \u2013 entweder die gesamte Zone via AXFR oder nur \u00c4nderungen via IXFR.<\/p>\n
Der Master-Server antwortet auf eine berechtigte Anfrage mit der Zonendatei im DNS-Nachrichtenformat. Die \u00dcbertragung erfolgt typischerweise \u00fcber TCP Port 53<\/strong>, da Zonendateien die Gr\u00f6\u00dfenbeschr\u00e4nkung von UDP-Paketen \u00fcberschreiten. Jeder Ressource Record wird sequenziell gesendet, beginnend mit dem SOA-Record und endend mit einem abschlie\u00dfenden SOA-Record als \u00dcbertragungsmarker.<\/p>\n Nach erfolgreicher \u00dcbertragung speichert der Slave-Server die Zonendaten lokal und aktualisiert seine eigene Seriennummer. Der Slave kann nun authoritative Antworten f\u00fcr die Zone liefern<\/strong>, ohne bei jeder Anfrage den Master-Server zu kontaktieren. Schl\u00e4gt die \u00dcbertragung fehl oder \u00fcberschreitet die Zone ihr Ablaufdatum (Expire), stellt der Slave die Antworten f\u00fcr diese Zone ein, bis eine erfolgreiche Synchronisation erfolgt.<\/p>\n Der NOTIFY-Mechanismus erm\u00f6glicht dem Master-Server, Slave-Server unmittelbar \u00fcber Zonen\u00e4nderungen zu informieren. Statt auf das Refresh-Intervall zu warten, sendet der Master eine NOTIFY-Nachricht an konfigurierte Slaves, sobald ein Administrator die Zone aktualisiert. Die benachrichtigten Server pr\u00fcfen daraufhin die Seriennummer und initiieren bei Bedarf einen Zonen\u00fcbergang, wodurch sich die Propagationszeit von \u00c4nderungen erheblich verk\u00fcrzt.<\/p>\n Ungesicherte Zonen\u00fcberg\u00e4nge z\u00e4hlen zu den klassischen Informationslecks in DNS-Infrastrukturen. Ein \u00f6ffentlich zug\u00e4nglicher AXFR-Request offenbart die gesamte DNS-Topologie einer Organisation, einschlie\u00dflich interner Hostnamen, IP-Adressbereiche und Dienstekonfigurationen. Angreifer kartieren damit die Angriffsfl\u00e4che einer Zielorganisation<\/strong>, ohne aktiv Systeme zu scannen oder Aufmerksamkeit durch Intrusion-Detection-Systeme zu erregen.<\/p>\n Die ausgesp\u00e4hten Informationen dienen der Vorbereitung gezielter Attacken. Entwicklungsserver mit vorhersehbaren Namen wie \u201edev.example.com“ oder \u201estaging.example.com“ sind h\u00e4ufig schw\u00e4cher gesichert als Produktionssysteme. Interne Subdomains verraten Organisationsstrukturen<\/strong> (\u201ehr.internal.example.com“, \u201efinance.internal.example.com“), die f\u00fcr Social-Engineering-Angriffe oder Phishing-Kampagnen ausgenutzt werden.<\/p>\n Die Offenlegung von Mailserver-Konfigurationen (MX-Records) und SPF-Eintr\u00e4gen unterst\u00fctzt E-Mail-basierte Angriffe. Angreifer identifizieren autorisierte Mailserver und IP-Bereiche, um \u00fcberzeugende Spoofing-Versuche zu konstruieren. Wildcard-Eintr\u00e4ge in der Zonendatei zeigen dynamische DNS-Bereiche<\/strong>, die m\u00f6glicherweise automatisiert verwaltet werden und geringere Sicherheitskontrollen aufweisen.<\/p>\n Die Absicherung von Zonen\u00fcberg\u00e4ngen erfolgt prim\u00e4r durch Zugriffskontrolle auf Netzwerk- und Anwendungsebene. IP-basierte ACLs beschr\u00e4nken AXFR- und IXFR-Anfragen auf die IP-Adressen autorisierter sekund\u00e4rer Nameserver. Diese Whitelist wird im Nameserver-Konfigurationsfile<\/strong> (z. B. named.conf bei BIND) als \u201eallow-transfer“-Direktive definiert und gilt zonenspezifisch oder global.<\/p>\n TSIG (Transaction Signature) erweitert die IP-basierte Filterung um kryptografische Authentifizierung. Master- und Slave-Server teilen einen geheimen Schl\u00fcssel, mit dem jede Transferanfrage und -antwort signiert wird. TSIG verhindert IP-Spoofing-Angriffe<\/strong>, da ein Angreifer ohne Kenntnis des Shared Secret keine g\u00fcltige Signatur erzeugen kann, selbst wenn er die autorisierte IP-Adresse vort\u00e4uscht.<\/p>\n Die Implementierung erfolgt durch Generierung eines TSIG-Schl\u00fcssels (typischerweise HMAC-SHA256) und dessen Konfiguration auf allen beteiligten Servern. Der Slave-Server f\u00fcgt seiner Zonen\u00fcbergangsanfrage die TSIG-Signatur hinzu, die der Master-Server verifiziert, bevor er die Zonendaten freigibt. Der Schl\u00fcssel selbst wird niemals \u00fcber das Netzwerk \u00fcbertragen<\/strong>, nur die damit errechnete Signatur der DNS-Nachricht.<\/p>\n Zonen\u00fcberg\u00e4nge unterscheiden sich fundamental von Standard-DNS-Lookups, obwohl beide das DNS-Protokoll verwenden. Eine regul\u00e4re DNS-Anfrage fragt einen einzelnen Ressource Record ab \u2013 beispielsweise die A-Record-Adresse von \u201ewww.example.com“. Der Nameserver antwortet ausschlie\u00dflich mit dem angefragten Datensatz<\/strong> plus eventueller zus\u00e4tzlicher Eintr\u00e4ge im Authority- oder Additional-Abschnitt.<\/p>\n Ein Zonen\u00fcbergang fordert dagegen die vollst\u00e4ndige Zonendatei an, unabh\u00e4ngig davon, welche spezifischen Eintr\u00e4ge der anfragende Client ben\u00f6tigt. Die Antwort umfasst jeden A-Record, AAAA-Record, MX-Record, TXT-Record und weitere Ressource Records innerhalb der Zonengrenzen. Diese Unterscheidung macht Zonen\u00fcberg\u00e4nge zu einem privilegierten Vorgang<\/strong>, der legitimerweise nur zwischen kooperierenden Nameservern stattfindet.<\/p>\n Protokolltechnisch verwenden Standard-Abfragen typischerweise UDP Port 53 mit Fallback auf TCP bei gro\u00dfen Antworten. Zonen\u00fcberg\u00e4nge erfolgen grunds\u00e4tzlich \u00fcber TCP aufgrund der Datenmenge. Der Query-Type unterscheidet beide Operationen:<\/strong> Regul\u00e4re Abfragen verwenden Query-Types wie A, AAAA oder MX, w\u00e4hrend Zonen\u00fcberg\u00e4nge die speziellen Types AXFR (252) oder IXFR (251) verwenden, die im normalen Resolver-Verkehr nicht vorkommen.<\/p>\n Die Protokollierung von Zonen\u00fcberg\u00e4ngen erm\u00f6glicht die Erkennung unautorisierter Transferversuche und hilft bei der Fehlerdiagnose. Moderne Nameserver-Software bietet granulare Logging-Optionen f\u00fcr Transferereignisse, die Zeitpunkt, Quell-IP, \u00fcbertragene Zone und Erfolg oder Fehlschlag dokumentieren. Regelm\u00e4\u00dfige Loganalysen identifizieren Anomalien<\/strong> wie unerwartete Quell-IPs, geh\u00e4ufte Fehlversuche oder Transferaktivit\u00e4ten au\u00dferhalb der geplanten Synchronisationsfenster.<\/p>\n Automatisierte Monitoring-Systeme k\u00f6nnen Warnmeldungen bei verd\u00e4chtigen Mustern ausl\u00f6sen. Mehrere gescheiterte Transferversuche von derselben IP innerhalb kurzer Zeit deuten auf einen Scanning-Versuch hin. Erfolgreiche Transfers von unbekannten Adressen<\/strong> \u2013 sollten sie trotz Schutzma\u00dfnahmen auftreten \u2013 signalisieren eine Fehlkonfiguration oder Kompromittierung eines autorisierten Servers.<\/p>\n Die Korrelation von Transfer-Logs mit \u00c4nderungsaufzeichnungen der Zonendatei verifiziert, dass Synchronisationen nach legitimen Updates erfolgen. Transfers ohne vorherige \u00c4nderung am Master k\u00f6nnen auf einen erzwungenen Refresh durch einen Angreifer hinweisen, der die Zone auslesen m\u00f6chte. Performance-Metriken wie Transferdauer und Datenmenge<\/strong> helfen, Kapazit\u00e4tsengp\u00e4sse zu identifizieren, bevor sie die Zonenverf\u00fcgbarkeit beeintr\u00e4chtigen.<\/p>\n DNS-Catalog-Zones bieten eine moderne Alternative zur manuellen Konfiguration von Master-Slave-Beziehungen. Der Master-Server ver\u00f6ffentlicht eine spezielle Catalog-Zone, die alle zu replizierenden Zonen auflistet. Slave-Server konsumieren diese Catalog-Zone per Zonen\u00fcbergang<\/strong> und konfigurieren automatisch die aufgef\u00fchrten Zonen zur Replikation, ohne dass Administratoren jeden Slave individuell anpassen m\u00fcssen.<\/p>\n DNSSEC (DNS Security Extensions) sch\u00fctzt die Integrit\u00e4t \u00fcbertragener Zonendaten gegen nachtr\u00e4gliche Manipulation. Die kryptografischen Signaturen in DNSSEC-signierten Zonen garantieren, dass ein Angreifer, der einen Zonen\u00fcbergang abh\u00f6rt, die erhaltenen Daten nicht unentdeckt modifizieren kann. DNSSEC ersetzt jedoch nicht die Zugriffskontrolle f\u00fcr Zonen\u00fcberg\u00e4nge<\/strong>, da es die Vertraulichkeit nicht sch\u00fctzt \u2013 ein erfolgreicher AXFR liefert weiterhin alle Zonendaten inklusive DNSSEC-Signaturen.<\/p>\n Hidden-Master-Architekturen verbergen den prim\u00e4ren Nameserver vor \u00f6ffentlichem Zugriff. Nur die sekund\u00e4ren Server erscheinen in den NS-Records der Zone und beantworten \u00f6ffentliche Anfragen. Der Hidden Master transferiert Zonen ausschlie\u00dflich an bekannte Slaves<\/strong> \u00fcber private Netzwerkverbindungen, was die Angriffsfl\u00e4che reduziert, da potenzielle Angreifer die Adresse des Masters nicht aus DNS-Abfragen ermitteln k\u00f6nnen.<\/p>\n","protected":false},"featured_media":0,"template":"","glossary_intl_set":[],"glossary_intl_cluster":[392],"glossary_intl_theme":[],"class_list":["post-28963","glossary_intl","type-glossary_intl","status-publish","hentry","glossary_intl_cluster-cybersecurity"],"acf":{"card_description":"Zonen\u00fcbergang bezeichnet in der IT die \u00dcbertragung von DNS-Zonendaten zwischen Nameservern, um Redundanz und Verf\u00fcgbarkeit zu gew\u00e4hrleisten.","nav_theme":"","nav_subtheme":"","dataset_version":"","term_inline":"","term_plural":false,"heading_overrides":null,"synonyms":[{"value":"Zonentransfer"},{"value":"DNS-Zonenreplikation"},{"value":"Zone Transfer"}],"lead_definition":"Zonen\u00fcbergang ist ein Verfahren im Domain Name System, bei dem ein prim\u00e4rer Nameserver DNS-Zonendaten vollst\u00e4ndig oder inkrementell an sekund\u00e4re Nameserver \u00fcbertr\u00e4gt, um die Verf\u00fcgbarkeit und Fehlertoleranz der Namensaufl\u00f6sung zu gew\u00e4hrleisten.","at_a_glance":[{"bullet":"Ein Zonen\u00fcbergang repliziert DNS-Zonendateien vom Master-Server auf Slave-Server, sodass mehrere Nameserver identische Daten bereithalten und Anfragen beantworten k\u00f6nnen."},{"bullet":"Falsch konfigurierte Zonen\u00fcberg\u00e4nge erm\u00f6glichen Angreifern, die gesamte DNS-Struktur einer Domain auszulesen und potenzielle Angriffsziele zu identifizieren."},{"bullet":"Die Zugriffskontrolle per ACL (Access Control List) beschr\u00e4nkt Zonen\u00fcberg\u00e4nge auf autorisierte Nameserver und verhindert unbefugtes Auslesen der DNS-Datenbank."}],"intro_answer":"","steps_answer":"","steps":null,"examples":[{"example":"Ein Unternehmen betreibt drei Nameserver f\u00fcr seine Domain: Der prim\u00e4re Server in Frankfurt aktualisiert st\u00fcndlich die sekund\u00e4ren Server in London und New York per Zonen\u00fcbergang, sodass alle drei Server identische DNS-Eintr\u00e4ge liefern."},{"example":"Ein Penetrationstester f\u00fchrt einen AXFR-Request gegen einen \u00f6ffentlichen Nameserver aus und erh\u00e4lt durch einen ungesicherten Zonen\u00fcbergang die komplette Liste aller Subdomains, Mailserver und internen Hostnamen der Zielorganisation."},{"example":"Nach einer \u00c4nderung des MX-Records initiiert der Master-Nameserver automatisch einen inkrementellen Zonen\u00fcbergang (IXFR), der nur die ge\u00e4nderten Eintr\u00e4ge an die Slave-Server \u00fcbertr\u00e4gt statt der gesamten Zonendatei."}],"misconception":null,"faq":[{"q":"Wie unterscheiden sich AXFR und IXFR bei Zonen\u00fcberg\u00e4ngen?","a":"AXFR (Full Zone Transfer) \u00fcbertr\u00e4gt die gesamte Zonendatei bei jedem Transfer, w\u00e4hrend IXFR (Incremental Zone Transfer) nur ge\u00e4nderte Eintr\u00e4ge seit dem letzten Transfer sendet. IXFR reduziert Bandbreite und Transferzeit erheblich, setzt aber voraus, dass beide Server die Seriennummern der Zone nachverfolgen."},{"q":"Warum stellen offene Zonen\u00fcberg\u00e4nge ein Sicherheitsrisiko dar?","a":"Ein ungesicherter Zonen\u00fcbergang offenbart die komplette interne DNS-Struktur inklusive aller Subdomains, Serveradressen und Dienstekonfigurationen. Angreifer nutzen diese Informationen f\u00fcr gezielte Attacken, Phishing-Kampagnen oder die Identifikation schlecht gesicherter Systeme innerhalb der Infrastruktur."},{"q":"Wann wird ein Zonen\u00fcbergang automatisch ausgel\u00f6st?","a":"Slave-Server initiieren Zonen\u00fcberg\u00e4nge nach Ablauf des Refresh-Intervalls, beim Empfang einer NOTIFY-Nachricht vom Master-Server oder nach einem Neustart, wenn ihre lokale Zonenkopie veraltet ist. Der Master-Server selbst l\u00f6st keine Transfers aktiv aus, sondern antwortet auf Anfragen autorisierter Slaves."},{"q":"Welche Authentifizierungsmethoden sch\u00fctzen Zonen\u00fcberg\u00e4nge?","a":"IP-basierte ACLs beschr\u00e4nken Transfers auf vordefinierte Nameserver-Adressen, w\u00e4hrend TSIG (Transaction Signature) kryptografische Schl\u00fcssel f\u00fcr die Authentifizierung verwendet. TSIG bietet st\u00e4rkere Sicherheit als reine IP-Filterung, da es Spoofing verhindert und die Integrit\u00e4t der \u00fcbertragenen Daten verifiziert."}],"compare_answer":"","compare":null,"variants":[{"title":"Vollst\u00e4ndiger Zonen\u00fcbergang (AXFR)","inline_description":"\u00dcbertragung der gesamten Zonendatei unabh\u00e4ngig von vorherigen \u00c4nderungen.","description":"AXFR ist eine Form des Zonen\u00fcbergangs, bei der der Slave-Server die komplette DNS-Zone vom Master-Server anfordert und empf\u00e4ngt, unabh\u00e4ngig davon, welche Daten bereits lokal vorliegen oder ob nur Teil\u00e4nderungen erfolgten.","source":"","key":""},{"title":"Inkrementeller Zonen\u00fcbergang (IXFR)","inline_description":"\u00dcbertragung nur ge\u00e4nderter DNS-Eintr\u00e4ge seit dem letzten Transfer.","description":"IXFR ist eine Form des Zonen\u00fcbergangs, bei der nur die seit dem letzten erfolgreichen Transfer ge\u00e4nderten, hinzugef\u00fcgten oder gel\u00f6schten Ressource Records \u00fcbertragen werden, was Bandbreite spart und die Synchronisationszeit verk\u00fcrzt.","source":"","key":""}],"signals_answer":"","signals":null,"protect_answer":"","prevent":null,"incident":null,"related_terms":null,"pillar_link":null,"sources":[{"publisher":"","name":"RFC 5936 - DNS Zone Transfer Protocol (AXFR)","url":"https:\/\/www.rfc-editor.org\/rfc\/rfc5936","doc_type":"","group":"used"},{"publisher":"","name":"RFC 1995 - Incremental Zone Transfer in DNS","url":"https:\/\/www.rfc-editor.org\/rfc\/rfc1995","doc_type":"","group":"used"}],"reviewer":{"name":"M. Kubascikova","qualification":"SEO director","date":"2026-07-01"},"disclaimer":""},"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tNOTIFY-Mechanismus f\u00fcr proaktive Updates<\/h3>\n
Sicherheitsrisiken durch ungesch\u00fctzte Zonen\u00fcberg\u00e4nge<\/h2>\n
H\u00e4ufige Fehlkonfigurationen<\/h3>\n
\n
Konfiguration sicherer Zonen\u00fcberg\u00e4nge<\/h2>\n
Praktische Konfigurationsschritte<\/h3>\n
\n
Zonen\u00fcbergang versus regul\u00e4re DNS-Abfragen<\/h2>\n
\n\n
\n \nMerkmal<\/th>\n Regul\u00e4re DNS-Abfrage<\/th>\n Zonen\u00fcbergang<\/th>\n<\/tr>\n<\/thead>\n \n Transportprotokoll<\/td>\n Prim\u00e4r UDP, TCP bei Bedarf<\/td>\n Ausschlie\u00dflich TCP<\/td>\n<\/tr>\n \n Antwortumfang<\/td>\n Einzelner angefragter Record<\/td>\n Gesamte Zonendatei<\/td>\n<\/tr>\n \n Query-Type<\/td>\n A, AAAA, MX, TXT etc.<\/td>\n AXFR (252) oder IXFR (251)<\/td>\n<\/tr>\n \n Zugangskontrolle<\/td>\n \u00d6ffentlich verf\u00fcgbar<\/td>\n Beschr\u00e4nkt auf autorisierte Server<\/td>\n<\/tr>\n \n Initiator<\/td>\n Beliebiger Client\/Resolver<\/td>\n Sekund\u00e4rer Nameserver<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \u00dcberwachung und Protokollierung von Zonen\u00fcberg\u00e4ngen<\/h2>\n
Alternativen und erg\u00e4nzende Technologien<\/h2>\n