Secondary-DNS-Server: Was er ist und wie er funktioniert

Was ist ein Secondary-DNS-Server?

Ein Secondary-DNS-Server ist ein autoritativer Nameserver, der eine schreibgeschützte Kopie einer DNS-Zone hält und Anfragen dafür mit derselben Autorität beantwortet wie der primäre Server. Er besitzt keine eigene Version der Zone: Er erhält die Zone vom primären Nameserver über einen Zonentransfer und hält diese Kopie synchron.

Von außen sind primärer und sekundärer Server nicht zu unterscheiden. Beide stehen in den NS-Records der Domain, beide antworten mit dem AA-Flag (authoritative answer), und Resolver wählen denjenigen, der schneller antwortet. Der Unterschied liegt allein darin, wo die Daten bearbeitet werden: Sie ändern Records auf dem primären Server, und der sekundäre folgt.

Ältere Dokumentation und viele Konfigurationsdateien nennen die beiden Rollen noch Master und Slave. BIND, PowerDNS und die meisten Panels akzeptieren beide Bezeichnungen; die Bedeutung ist dieselbe.

Von jeder Produktivdomain wird erwartet, dass sie mindestens zwei autoritative Nameserver in unterschiedlichen Netzen hat — RFC 2182 erläutert warum, und die meisten Registries lehnen eine Delegation mit weniger ab. Ein Secondary-DNS-Server ist der Weg, wie eine Einzelserver-Installation diese Anforderung erfüllt, ohne von Hand eine zweite vollständige DNS-Installation zu betreiben.

Primärer vs. sekundärer DNS

Primär (Master). Hält die bearbeitbare Kopie der Zone — in Zonendateien bei BIND, in einer Datenbank bei PowerDNS, im Speicher des Panels bei cPanel, Plesk, DirectAdmin oder CyberPanel. Jede Änderung an einem Record geschieht hier, und jede Änderung soll die SOA-Seriennummer der Zone erhöhen.

Sekundär (Slave). Hält eine per Zonentransfer bezogene Kopie. Er nimmt niemals Bearbeitungen an; alles, was lokal geändert wird, überschreibt der nächste Transfer. Er beantwortet Anfragen autoritativ, sendet keine Änderungen zurück und verwirft die Zone, wenn er den primären Server länger als die SOA-Expire-Zeit nicht erreichen kann.

Was das in der Praxis bedeutet:

- Einen Record hinzuzufügen heißt, nur den primären Server zu bearbeiten. Der sekundäre übernimmt die Änderung von selbst. - Ist der primäre Server ausgefallen, antwortet der sekundäre weiter — neue Änderungen sind aber erst wieder möglich, wenn der primäre zurück ist. - Ist der sekundäre Server ausgefallen, antwortet der primäre weiter und nichts geht verloren; Resolver nutzen einfach den verbleibenden Nameserver. - Beide Server müssen in den NS-Records beim Registrar eingetragen sein, sonst fragen Resolver den sekundären Server niemals etwas.

Wie ein sekundärer Server die Zone erhält

Der Mechanismus ist ein Zonentransfer, definiert im DNS-Protokoll selbst, sodass jeder sekundäre Server unabhängig von der Software mit jedem primären zusammenarbeiten kann.

1. Autorisierung. Der primäre Server muss Transfers an die IP-Adresse des sekundären erlauben (allow-transfer in BIND, allow-axfr-ips in PowerDNS) oder einen gemeinsamen TSIG-Schlüssel akzeptieren. Ohne das wird der sekundäre Server abgewiesen. 2. Erster Transfer. Der sekundäre Server fordert mit einer AXFR-Anfrage über TCP-Port 53 die gesamte Zone an und speichert das Ergebnis. Von nun an ist er für die Zone autoritativ. 3. Synchron bleiben. Der sekundäre Server prüft den SOA-Record des primären Servers erneut im Takt des SOA-Refresh-Werts der Zone. Ist die Seriennummer des primären Servers höher als seine eigene, transferiert er erneut — die gesamte Zone (AXFR) oder nur die Änderungen (IXFR), wenn beide Seiten dies unterstützen. 4. NOTIFY. Statt auf den Refresh-Timer zu warten, kann ein primärer Server in dem Moment, in dem sich die Zone ändert, eine NOTIFY-Nachricht senden; der sekundäre Server prüft die Seriennummer dann sofort. Mit eingerichtetem NOTIFY erreichen Änderungen den sekundären Server in Sekunden. 5. Ablauf. Bleibt der primäre Server länger als der SOA-Expire-Wert unerreichbar, stellt der sekundäre Server die Antworten für die Zone ein, statt womöglich stark veraltete Daten auszuliefern.

Zwei Details verursachen die meisten fehlgeschlagenen Einrichtungen. Die Seriennummer muss bei jeder Änderung tatsächlich steigen — ein sekundärer Server vergleicht Zahlen, nicht Inhalte. Und AXFR nutzt TCP, nicht UDP: Eine Firewall, die nur UDP 53 erlaubt, lässt normale Anfragen durch, blockiert aber stillschweigend jeden Zonentransfer. Das Transferprotokoll wird ausführlich in AXFR-Zonentransfers verstehen behandelt, die Timer in Was ist ein DNS-SOA-Record und warum er für Ihre Domain wichtig ist.

Warum Sie einen Secondary-DNS-Server brauchen

Verfügbarkeit. Ein einzelner autoritativer Nameserver ist ein Single Point of Failure für jede Domain, die auf ihm liegt. Ein Neustart für ein Kernel-Update, ein Hardwaredefekt, ein DDoS auf den Server — und die Domains lösen überhaupt nicht mehr auf: Websites, E-Mail und APIs fallen gemeinsam aus. Mit einem sekundären Server in einem anderen Netz erhalten Resolver ihre Antworten von ihm, und die Nutzer bemerken nichts.

Regeln von Registrar und Registry. Die meisten Registries verlangen mindestens zwei Nameserver, um eine Domain zu delegieren, und manche prüfen, ob sie in unterschiedlichen Netzen liegen. Denselben Server unter zwei Namen einzutragen erfüllt die Form, aber nicht den Zweck: Beide Namen fallen gemeinsam aus.

Caching rettet Sie nicht. Resolver speichern Records nur für ihre TTL zwischen — Minuten bis Stunden. Ein primärer Server, der länger als die TTL ausgefallen ist, bedeutet eine Domain, die aus dem Internet verschwunden ist, und Mailserver, die Ihren MX nicht auflösen können, weisen Nachrichten ab oder stellen sie zurück.

Entfernung. Ein sekundärer Server an einem zweiten Standort beantwortet Anfragen der Nutzer in seiner Nähe, und beide Server teilen sich die Abfragelast. Das ist ein Nebeneffekt, nicht der Hauptgrund: Der Hauptgrund ist, dass ein Server irgendwann ausfällt, und ein sekundärer Server ist das, was die Domain dann online hält.

DNS-Redundanz: Warum sie wichtig ist und wie Sie sie erreichen geht tiefer darauf ein, was tatsächlich ausfällt und wie Sie dagegen planen.

Eigener Secondary vs. gehosteter Secondary

Ihr eigener zweiter Server. Eine zweite BIND- oder PowerDNS-Installation auf einer anderen Maschine, idealerweise in einem anderen Rechenzentrum, für jede Zone als sekundärer Server konfiguriert. Sie gibt Ihnen volle Kontrolle und kostet nur den Server. Der Preis ist betrieblich: ein zweiter Host, der gepatcht und überwacht werden muss, Firewall-Regeln auf beiden Seiten und jede neue Zone von Hand auf dem sekundären Server einzutragen — oder mit Skripten automatisiert, die Sie pflegen. Viele Einzelserver-Installationen kommen genau deshalb nie dazu.

Ein gehosteter Secondary-DNS-Dienst. Ein Anbieter betreibt die sekundären Nameserver; Sie erlauben Zonentransfers von seiner IP und richten Ihre NS-Records auf seinen Hostnamen (oder auf Ihren eigenen Hostnamen mit einem Glue-Record — siehe Was sind DNS-Glue-Records und wann brauchen Sie sie). Ihr Server bleibt der primäre, an der Art, wie Sie DNS bearbeiten, ändert sich nichts, und die Aufgabe des Anbieters ist es, verfügbar zu bleiben, wenn Ihr Server es nicht ist. Der Kompromiss: Sie hängen für die Hälfte Ihres DNS von einem Dritten ab, daher zählen seine Verfügbarkeit und die Trennung seines Netzes von Ihrem.

Hosting-Panels. Bei cPanel, Plesk, DirectAdmin und CyberPanel ist der manuelle Weg schwieriger, als er aussieht: Das Panel erzeugt die Konfiguration des DNS-Servers neu, sodass Änderungen von Hand überschrieben werden, und jede neue Domain muss auf dem sekundären Server eingetragen werden. Genau dafür gibt es Integrationen, die sich in die Domain-Ereignisse des Panels einklinken; die Panel-Leitfäden unten zeigen sowohl den manuellen als auch den automatisierten Weg.

Wofür Sie sich auch entscheiden, die Checkliste ist dieselbe: Transfers von der Adresse des sekundären Servers erlaubt, NOTIFY aktiviert, TCP 53 offen, beide Nameserver in der Delegation und die Seriennummer bei jeder Änderung erhöht.

Prüfen, ob ein sekundärer Server funktioniert

Fragen Sie jeden autoritativen Server direkt nach dem SOA-Record der Zone. Ersetzen Sie example.com durch Ihre Domain und die beiden Hostnamen durch Ihre Nameserver:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Beide müssen antworten, und die Seriennummer (das dritte Feld) muss identisch sein. Ein sekundärer Server, der mit einer niedrigeren Seriennummer antwortet, hat die letzte Änderung nicht übernommen; einer, der mit SERVFAIL oder REFUSED antwortet, hat die Zone nie geladen oder hat sie verworfen.

Prüfen Sie die Delegation so, wie die Welt sie sieht:

dig NS example.com +short

Beide Nameserver müssen aufgeführt sein. Ein sekundärer Server, der perfekt synchron ist, aber in den NS-Records fehlt, erhält keine Anfragen und schützt nichts.

Bestätigen Sie schließlich, dass der Zonentransfer selbst aus dem Netz des sekundären Servers möglich ist — vom sekundären Host aus oder von jedem Host, dessen IP der primäre Server erlaubt:

dig AXFR example.com @ns1.example.com

Eine vollständige Zonenauflistung bedeutet, dass Transfers funktionieren; ein transfer failed oder REFUSED bedeutet, dass die allow-transfer-Regeln des primären Servers oder eine Firewall auf TCP 53 den sekundären Server blockieren.

Häufige Fehler

- Das Erhöhen der SOA-Seriennummer vergessen. Der primäre Server antwortet mit neuen Daten, der sekundäre sieht dieselbe Seriennummer und transferiert nie. Die häufigste Ursache für „funktioniert auf ns1, nicht auf ns2“. - UDP 53 öffnen, aber nicht TCP 53. Anfragen funktionieren, Transfers nicht. Jede Zone auf dem sekundären Server läuft stillschweigend ab. - Den sekundären Server nicht in den NS-Records eintragen. Der sekundäre Server synchronisiert perfekt und wird nie etwas gefragt. - Beide Nameserver auf demselben Host oder im selben Netz. Erfüllt die Form des Registrars, nicht den Ausfall, den sie überstehen soll. - Ein kurzes SOA-Expire. Ein Tag ist in Panel-Standardwerten üblich; ein Wochenendausfall des primären Servers reißt den sekundären dann mit. Zwei Wochen sind der übliche Wert. - Records auf dem sekundären Server bearbeiten. Sie verschwinden beim nächsten Transfer. - Den sekundären Server beim Anlegen einer neuen Domain vergessen. Jede neue Zone muss auf dem sekundären Server eingetragen werden, von Hand oder automatisiert; eine Zone, die nur auf dem primären Server existiert, hat überhaupt keine Redundanz.