Secondary DNS einrichten: Zonentransfer mit TSIG

Viele Domains haben laut Registry zwei Nameserver und trotzdem nur einen. ns1 und ns2 liegen beim selben Anbieter, oft im selben Netz, manchmal sogar auf derselben Maschine. Fällt dieser Anbieter einem DDoS zum Opfer, nützt die zweite Adresse nichts.

Was Secondary DNS leistet

Ein Secondary DNS ist ein autoritativer Nameserver, der seine Daten nicht selbst verwaltet, sondern vom Primary kopiert. Er beantwortet Anfragen genauso verbindlich wie der Primary. Resolver unterscheiden nicht zwischen beiden, sie sehen nur die NS-Einträge und fragen einen davon.

Der Nutzen hängt komplett davon ab, wo der Secondary steht. RFC 2182 („Selection and Operation of Secondary DNS Servers“) empfiehlt, Secondaries so zu platzieren, dass sie nicht gemeinsam mit dem Primary ausfallen: anderes Netz, anderer Standort, idealerweise anderer Betreiber. Für DDoS-Schutz ist das der springende Punkt. Ein Angriff auf Anbieter A trifft Anbieter B nicht automatisch.

Welche Angriffe auf Nameserver typisch sind, zeigt der Artikel DNS-DDoS.

Wie der Zonentransfer funktioniert

Drei Mechanismen arbeiten zusammen:

Der Ablauf: Du änderst einen Eintrag auf dem Primary und erhöhst die Seriennummer im SOA. Der Primary schickt ein NOTIFY. Der Secondary fragt den SOA ab, sieht die höhere Seriennummer und holt per IXFR oder AXFR die neuen Daten. Kommt kein NOTIFY an, fragt der Secondary trotzdem regelmäßig nach, im Abstand des Refresh-Werts.

Die SOA-Timer richtig setzen

Der SOA-Eintrag steuert, wie sich der Secondary verhält, wenn etwas schiefgeht.

example.de.  3600  IN  SOA  ns1.example.de. hostmaster.example.de. (
                 2026101801 ; Serial (Datum + Zähler)
                 3600       ; Refresh: alle 60 Minuten nachfragen
                 900        ; Retry: nach Fehler alle 15 Minuten
                 1209600    ; Expire: nach 14 Tagen ohne Kontakt aufgeben
                 3600 )     ; Negative-Caching-TTL

Wichtig ist Expire. Solange der Secondary den Primary innerhalb dieser Frist erreicht hat, beantwortet er Anfragen. RFC 1912 empfiehlt zwei bis vier Wochen. Ein Expire von einem Tag wäre riskant: Liegt der Primary übers Wochenende lahm, verabschiedet sich am Montag auch der Secondary.

Secondary DNS mit BIND einrichten

Das Beispiel nutzt Dokumentations-Adressen: Primary 198.51.100.10, Secondary 203.0.113.53. Bei einem Managed-DNS-Anbieter als Secondary übernimmt dessen Oberfläche die Secondary-Seite, die Primary-Seite bleibt gleich.

1. TSIG-Schlüssel erzeugen (auf dem Primary):

tsig-keygen -a hmac-sha256 xfr-key > /etc/bind/xfr-key.conf

Die Datei enthält einen key "xfr-key" { … };-Block. Denselben Block brauchst du auf dem Secondary. Übertrage ihn auf einem sicheren Weg, nicht per unverschlüsselter Mail.

2. Primary konfigurieren:

include "/etc/bind/xfr-key.conf";

zone "example.de" {
    type primary;
    file "/etc/bind/zones/db.example.de";
    notify yes;
    also-notify { 203.0.113.53 key "xfr-key"; };
    allow-transfer { key "xfr-key"; };
};

3. Secondary konfigurieren:

include "/etc/bind/xfr-key.conf";

zone "example.de" {
    type secondary;
    file "/var/cache/bind/db.example.de";
    primaries { 198.51.100.10 key "xfr-key"; };
};

Ältere BIND-Versionen kennen statt primary/secondary nur master/slave und masters. Danach named-checkconf auf beiden Seiten, rndc reload und im Log nach transfer of 'example.de/IN' from 198.51.100.10#53: Transfer completed suchen.

Drei Prüfbefehle

Sind beide Server auf demselben Stand?

dig @ns1.example.de example.de SOA +short
dig @ns2.example.net example.de SOA +short

Die dritte Zahl in der Ausgabe ist die Seriennummer. Stimmt sie überein, ist der Secondary aktuell.

Ist der Transfer ohne Schlüssel gesperrt?

dig @198.51.100.10 example.de AXFR

Erwartet ist ; Transfer failed.. Kommt stattdessen die komplette Zone, kann jeder deine Einträge auslesen, inklusive interner Hostnamen.

Stimmen die NS-Einträge?

dig example.de NS +short

Hier müssen alle Nameserver erscheinen, auch der neue Secondary. Und zwar sowohl in der Zone selbst als auch in der Delegation beim Registrar.

Typische Fehler beim Secondary DNS

Die meisten Probleme mit Secondaries fallen erst auf, wenn man sie braucht. Diese tauchen in der Praxis immer wieder auf:

• Seriennummer vergessen. Wer die Zonendatei ändert, ohne die Serial zu erhöhen, sieht die Änderung nur auf dem Primary. Der Secondary hält seine Kopie für aktuell.
• Firewall blockiert TCP 53. Zonentransfers laufen über TCP. Ist nur UDP 53 offen, kommt NOTIFY an, der Transfer aber nicht.
• Secondary fehlt in der Delegation. Er ist eingerichtet und synchron, steht aber nicht in den NS-Einträgen beim Registrar. Resolver fragen ihn dann nie.
• Alte IP im Primary-Eintrag. Nach einem Serverumzug zeigt primaries noch auf die alte Adresse. Der Secondary läuft weiter, bis Expire erreicht ist, und fällt dann still aus.
• Uhrzeit falsch. TSIG prüft Zeitstempel. Weicht die Systemzeit eines Servers um mehr als ein paar Minuten ab, scheitern die Transfers mit einem BADTIME-Fehler. NTP auf beiden Seiten löst das.

Hidden Primary: der Primary bleibt unsichtbar

Eine beliebte Variante: Der Primary steht in keinem NS-Eintrag und ist aus dem Internet nur für Zonentransfers erreichbar. Öffentlich antworten ausschließlich die Secondaries, etwa bei zwei verschiedenen Anycast-Anbietern.

Der Vorteil für den DDoS-Fall: Angreifer kennen die Adresse des Primary nicht, weil sie nirgends veröffentlicht ist. Die öffentlichen Server stehen in großen Netzen, die mehr verkraften. Der Nachteil: Ein weiterer Server, den du betreiben und überwachen musst. Wie Anycast die öffentlichen Server stärkt, beschreibt Anycast-DNS.

Wenn der Anbieter keinen Zonentransfer kann

Manche DNS-Dienste unterstützen weder AXFR nach außen noch eingehende Transfers. Dann bleiben zwei Wege:

• API-Synchronisation. Ein Skript liest die Einträge bei Anbieter A über dessen API und schreibt sie zu Anbieter B. Das funktioniert, braucht aber Pflege und Monitoring.
• Beide Anbieter aus einer Quelle befüllen. Die Zone liegt als Datei in einem Repository, und ein Deployment-Schritt schreibt sie zu beiden Anbietern.

Beim Kauf eines DNS-Dienstes lohnt deshalb die Frage nach AXFR/IXFR mit TSIG. Sie entscheidet, ob du später ohne Aufwand einen zweiten Anbieter dazuschalten kannst.

DNSSEC mit zwei Anbietern

Mit DNSSEC wird es etwas anspruchsvoller. Der einfachste Weg: Der Primary signiert, der Secondary bekommt die signierte Zone per Transfer und liefert sie unverändert aus. Signiert jeder Anbieter selbst, braucht es ein Multi-Signer-Modell nach RFC 8901, bei dem die Schlüssel beider Seiten in der Zone stehen. Für die meisten Setups reicht die erste Variante.

Den DS-Eintrag hinterlegst du beim Registrar. Ein Registrar mit DNSSEC nimmt ihn entgegen und reicht ihn an die Registry weiter.

Die NS-Einträge für den Secondary trägst du in der Nameserver-Verwaltung deines Registrars ein. Danach den Abschnitt „Drei Prüfbefehle“ noch einmal durchgehen. Läuft alles, ist deine Domain gegen den Ausfall eines Anbieters abgesichert. Brauchst du für ein neues Projekt erst noch einen Namen, kannst du bei betadomain Wunschnamen prüfen und die Domain gleich mit zwei Nameserver-Anbietern starten. Wie du im Ernstfall weiter vorgehst, steht unter DDoS-Attacke: was tun.

Schritt für Schritt

1. Zweiten Anbieter wählenSuche einen DNS-Anbieter, der Secondary-Zonen per AXFR/IXFR mit TSIG unterstützt und in einem anderen Netz als dein Primary arbeitet.
2. TSIG-Schlüssel erzeugenErzeuge mit tsig-keygen -a hmac-sha256 xfr-key einen gemeinsamen Schlüssel und hinterlege ihn auf Primary und Secondary.
3. Primary für Transfers freigebenErlaube in der Zonenkonfiguration allow-transfer nur mit dem TSIG-Schlüssel und trage den Secondary per also-notify ein.
4. Secondary-Zone anlegenLege beim Secondary-Anbieter die Zone mit der IP des Primary und dem Schlüssel an, beziehungsweise in BIND als type secondary mit primaries.
5. Synchronisation prüfenVergleiche die SOA-Seriennummer beider Server mit dig SOA +short und teste, dass ein AXFR ohne Schlüssel abgewiesen wird.
6. NS-Einträge ergänzenTrage den Secondary als NS-Eintrag in der Zone und beim Registrar ein. Beide Listen müssen übereinstimmen.