Hetzner, DENIC und ein Nameserver-Albtraum: Wie ich purkon.de stundenlang debuggt habe

TL;DR: Wer bei Hetzner eine sekundäre DNS-Zone mit Plesk als Hidden Primary betreibt und die Nameserver im Robot wechseln will, stolpert über eine Reihe von Fallstricken – von veralteten Zonen über BIND-Cache bis zur Firewall. Dieser Artikel dokumentiert jeden Schritt

Der Ausgangspunkt: Eine harmlose Fehlermeldung

Es fing mit einer Warnung in der Hetzner DNS Console an. Die Zone für purkon.de zeigte: „Fehlerhafte Zonen-Delegierung – Ihre Domain verweist auf andere Nameserver.“ Das klingt einfach. Es war alles andere als das.

Das Setup: Plesk läuft als Hidden Primary auf meinem Hetzner Dedicated Server. Die Hetzner DNS Console fungiert als sekundäre Zone – sie holt sich die Zonendaten via AXFR von Plesk und publiziert sie über die Hetzner Nameserver. Das Ziel: die Nameserver im Hetzner Robot auf die richtigen Secondary-NS umstellen:

ns1.first-ns.de

robotns2.second-ns.de

robotns3.second-ns.com

Was dann folgte, war ein mehrstündiges Debugging durch mehrere Layers.

Fallstrick 1: Zwei Hetzner-Produkte, zwei Nameserver-Sets

Das erste Problem ist konzeptuell. Hetzner hat zwei verschiedene DNS-Systeme mit unterschiedlichen Nameservern:

Produkt	Nameserver
Hetzner DNS Console (neue primäre Zonen)	hydrogen.ns.hetzner.com, helium.ns.hetzner.de, oxygen.ns.hetzner.com
Hetzner Robot / sekundäre Zonen	ns1.first-ns.de, robotns2.second-ns.de, robotns3.second-ns.com

Wer eine sekundäre Zone mit eigenem Hidden Primary betreibt, braucht zwingend die Robot-Nameserver. Die Console-Warnung klingt nach einem Fehler – ist aber bei diesem Setup normal, solange die Nameserver korrekt gesetzt sind.

Laut Hetzner-Dokumentation gilt: Sekundäre Zonen funktionieren nur mit den Robot-Nameservern (ns1.first-ns.de etc.), nicht mit den Console-Nameservern.

Fallstrick 2: Der DENIC Predelegation Check schlägt fehl

Beim Versuch, die Nameserver im Robot umzustellen, kam sofort ein Fehler:

code: '2305' – Object association prohibits operation
ERROR: 118 Inconsistent set of NS RRs
(robotns3.second-ns.com, 193.47.99.3, ['helium.ns.hetzner.de', 'hydrogen.ns.hetzner.com', 'oxygen.ns.hetzner.com'])

DENIC führt bei jeder Nameserver-Änderung einen Predelegation Check durch. Das heißt: Die neuen Nameserver müssen die Zone bereits kennen und konsistente Daten liefern, bevor die Delegation geändert wird. Ein klassisches Henne-Ei-Problem.

Die Ursache: Die Hetzner Console hatte noch eine Zone für purkon.de mit den alten NS-Records (helium/hydrogen/oxygen). Diese Zone wurde von den sekundären Nameservern via AXFR repliziert – und genau diese alten Records hat DENIC beim Predelegation Check gesehen.

Die Lösung: Zuerst die NS-Records in der Zone selbst ändern (in Plesk auf die neuen Nameserver setzen), warten bis der AXFR alle Slaves aktualisiert hat – und erst dann im Robot umstellen.

Fallstrick 3: BIND-Cache auf dem eigenen Server

Ein dig purkon.de ns direkt auf dem Server lieferte die alten Records – obwohl Plesk die Zone bereits korrekt konfiguriert hatte. Der lokale BIND-Cache hatte die alten Daten noch gespeichert.

Fix:

rndc flushname purkon.de

Danach mit dig purkon.de ns @127.0.0.1 prüfen ob die eigene Zone authoritative die richtigen Records liefert (erkennbar am aa-Flag in der Ausgabe).

---

Fallstrick 4: helium und oxygen mit Serial aus Oktober 2025

Beim direkten Befragen der Hetzner-Nameserver zeigte sich ein erschreckendes Bild:

helium.ns.hetzner.de  → Serial: 2025100301  ❌
oxygen.ns.hetzner.com → Serial: 2025100301  ❌
hydrogen.ns.hetzner.com → Serial: 2026051903 ✅

helium und oxygen hatten eine Zone die seit Oktober 2025 nicht mehr aktualisiert worden war – mit dem alten SOA MNAME oxygen.ns.hetzner.com. Das war ein Überbleibsel aus der Zeit bevor das Setup auf Hidden Primary umgestellt wurde.

Diese veraltete Zone in der Hetzner Console war der Grund warum DENIC im Predelegation Check immer wieder inkonsistente Daten sah. Da helium und oxygen interne Hetzner-Server sind, konnte das nur der Hetzner Support lösen.

Wichtig: Den Hetzner Support mit konkreten Daten kontaktieren:

„helium.ns.hetzner.de liefert für purkon.de Serial 2025100301 mit veraltetem MNAME oxygen.ns.hetzner.com. Mein Plesk-Primary (144.76.129.18) liefert Serial 2026051903 mit korrekten NS-Records. Bitte Zone manuell refreshen.“

Fallstrick 5: Die Firewall blockiert AXFR von robotns3

Nachdem die sekundäre Zone neu angelegt wurde, kam robotns3.second-ns.com noch immer nicht an aktuelle Daten. Ein Blick in die iptables-Regeln zeigte das Problem:

iptables -L INPUT -n | grep 53

Die erlaubten Ranges für Port 53 waren ausschließlich Hetzner-interne Netze:

213.133.0.0/16
213.239.192.0/18
78.46.0.0/15
85.10.192.0/18
88.198.0.0/16

robotns3.second-ns.com hat die IP 193.47.99.3 – die in keiner dieser Ranges liegt. AXFR-Anfragen von robotns3 wurden also still gedroppt.

Fix in Plesk: Tools & Settings → Firewall → Regel „Domain name server“ bearbeiten und folgende IPs ergänzen:

• 193.47.99.3 (robotns3 IPv4)
• 193.47.99.5 (robotns3 zweite IPv4)

Für IPv6 eine eigene Custom Rule anlegen:

• 2001:67c:192c::add:a3
• 2001:67c:192c::add:5

Fallstrick 6: NOTIFY kommt von der falschen IPv6-Adresse

Hetzner Support wies darauf hin, dass NOTIFY-Requests von einer IPv6-Adresse kamen, die nicht als Primary Server in der Console hinterlegt war. Plesk schickt NOTIFYs von allen verfügbaren Interfaces – also auch von 2a01:4f8:190:62ef::2.

Fix: In der Hetzner Console → sekundäre Zone → Primäre Server → IPv6-Adresse des Servers hinzufügen.

Die richtige Reihenfolge für dieses Setup

Wer Plesk als Hidden Primary mit Hetzner als sekundäre Zone betreibt, sollte bei einer Nameserver-Änderung diese Reihenfolge einhalten:

1. NS-Records in Plesk aktualisieren (auf neue Nameserver setzen)
2. NOTIFY auslösen: rndc notify domain.de
3. Prüfen ob alle Slaves aktuell sind:

   dig @ns1.first-ns.de domain.de NS
   dig @robotns2.second-ns.de domain.de NS
   dig @robotns3.second-ns.com domain.de NS

4. DENIC Predelegation Check unter https://nast.denic.de durchführen
5. Erst dann im Hetzner Robot die Nameserver umstellen

Checkliste: AXFR-IPs für Plesk Transfer Restrictions

Diese IPs müssen in Plesk unter Tools & Settings → DNS Settings → Transfer Restrictions Template eingetragen sein:

IPv4:

• 213.239.242.238 (ns1.first-ns.de)
• 213.133.100.103 (robotns2.second-ns.de)
• 193.47.99.3 (robotns3.second-ns.com)
• 193.47.99.5
• 213.239.246.3
• 88.198.229.192
• 213.133.100.98

IPv6:

• 2a01:4f8:0:a101::a:1
• 2a01:4f8:0:1::5ddc:2
• 2001:67c:192c::add:a3
• 2001:67c:192c::add:5
• 2a01:4f8:0:1::add:2992
• 2a01:4f8:0:1::add:1098

Fazit

Was wie eine einfache Nameserver-Änderung aussah, entpuppte sich als Schichtenkuchen aus veralteten Zonen, BIND-Cache, Firewall-Regeln und einem DENIC-Check der keinen Fehlerraum lässt. Die wichtigste Erkenntnis: Bei diesem Setup muss alles konsistent sein bevor DENIC befragt wird – und das bedeutet jeden einzelnen Nameserver direkt zu prüfen, nicht nur via öffentlichem Resolver.

Der DENIC NAST Check unter https://nast.denic.de ist dabei ein unverzichtbares Werkzeug. Er zeigt exakt was DENIC sieht – und ist damit der einzige verlässliche Indikator ob der Robot-Wechsel durchgehen wird.

Dieser Artikel entstand aus einer realen Debugging-Session und dokumentiert alle aufgetretenen Probleme ohne Vereinfachung.