DNS-Cleanup bei Hetzner

Nov 6, 2025 4 min read toheine Ansible DNS Hetzner Server

Ich bin seit vielen Jahren Kunde bei Hetzner (beruflich wie privat). Und wie oft gehe ich in die WebUI von Hetzner Robot, die DNS-Konsole oder in die Hetzner Console (ehemals Hetzner Cloud)? Antwort: Nicht so oft. Es läuft ja alles und selbst neue VMs kann ich über die API erzeugen. Warum soll ich mir das dann zusammen klicken. Das ist aber genau so lange voll OK, bis es eine wesentliche Änderung gibt, die mir dann über die Bubble zugespielt wird: Ey … haste mitbekommen … die schalten die DNS Console ab. 😳

Inhalt:

DNS Console zieht um

Dann muss ich mich halt mal wieder einloggen. In der DNS-Console fällt mir dann sofort das Banner auf:

Info-Banner: DNS Console zieht in die Hetzner Console

Umgezogen war das wirklich einfach. Wie gewohnt ist in den Docs alles vorbildlich beschrieben. Kann nichts schief gehen.

In einem meiner Projekte, mit denen ich zu tun habe, gab es dann aber doch einen Impact: Dort werden via API die _acme-challenge-Einträge für die DNS-01-Challenge gesetzt. Das bisher verwendete Ansbile-Modul Community.Dns ist aber nach der durchgeführten Migration nicht mehr kompatibel. Ein wenig weitere Recherche führte mich zu dem zone_rrset-Modul von Hetzner.Hcloud .

Das Modul wird gerade aktiv entwickelt und erst vor wenigen Tagen wurde die Version 6.0.0 veröffentlicht. Daher musste ich das Modul auf meinem Ansible-Host erstmal aktualisieren:

ansible-galaxy collection install hetzner.hcloud --force

Damit konnte ich nun relativ schnell erfolgreich testen und die notwendigen Resource Records setzen. Aber … und das ist meine komplett individuelle und subjektive Erkenntnis: Das Vorgehen via API die DNS-Einträge zu setzen ist gut und schön. Das funktioniert auch. Aber wenn der DNS-Server-Betreiber seinen Zugriff über die API ändert, muss man halt selbst nacharbeiten. Mir ist das jetzt zum zweiten Mal auf die Füße gefallen (das erste Mal war ich aber bei einem anderen DNS-Registrar).

Dieses Szenario ist genau der Grund, warum ich bevorzugt auf einen eigenen DNS-Server setze und dann darüber die Let’s-Encrypt-Zertifikate via DNS-01-Challenge erzeuge. Ich hab das Vorgehen hier im Blog bereits beschrieben.

Domain-Erwerb und Zonen-Datei

Bei meinen Tests ist mir noch ein weiterer Sachverhalt aufgefallen. Und das schreibe ich hier nur, damit ich in ferner Zukunft wieder in meinem eigenen Notizen nachlesen kann, was der Stolperstein ist. Es geht um die Schritte die bei Domain-Kauf durchzuführen sind.

Bei den meisten mir bekannten DNS-Registraren wird bei Kauf einer Domain sofort und automatisch eine entsprechende Zonen-Datei angelegt auf die ich über eine WebUI zugreifen kann. Bei Hetzner ist das nicht so. Wenn ich via Hetzner Robot eine Domain kaufe und ich nicht im Vorfeld eine entsprechende Zonen-Datei mit den notwendigen authoritativen DNS-Servern und einem SOA-Eintrag eingestellt habe, erfolgt eine Warnung bei Kauf, die ich bestätigen muss …

Warnung bei Kauf der Domain dass noch kein DNS-Eintrag hinterlegt wurde

… und eine Fehlermeldung (per Mail und in der GUI) wenn ich dann die Domain “zahlungspflichtig registriert” habe. Im Robot wird das auch schön dargestellt (Weißes Kreuz auf rotem Grund rechts im Bild):

Hinweis auf unvollständig registrierte Domain

Die Fehlermeldung kann in den Domainmeldungen nachgelesen werden (Auszug):

response:
  result:
    code: '2305'
    msg: 'Object association prohibits operation'
    extValue:
      -
        value: ERROR
        reason: 'Nameserver error [ERROR: 133 Answer must be authoritative \
                 (nameserver, ip, proto, record) \
                 (oxygen.ns.hetzner.com, 2a01:4f8:0:1::add:2992, udp, NS)]'
      -
        value: ERROR
        reason: 'Nameserver error [ERROR: 901 Unexpected RCODE \
                 (nameserver, ip, proto, record) \
                 (oxygen.ns.hetzner.com, 2a01:4f8:0:1::add:2992, udp, NS)]'

Die Korrektur ist dann kein Hexenwerk, wenn man weiß wie.

Schritt 1 - Zonen-Datei anlegen: In der Hetzner-Console muss in dem entsprechenden Projekt unter DNS (1) eine DNS-Zone mit der neu erworbenen Domain hinzu gefügt werden (2). Im Formular trägt man den gewünschten Domainnamen (3) ein. Für den Test reicht eine leere Zone (4):

Im Anschluss kann ich in die eben angelegte Zonen-Datei klicken und mir die dort hinterlegten NS- und SOA-Einträge anschauen, sowie weitere eigene Records anlegen. Oben erscheint eine kleine Warnmeldung mit einem Button daneben, der auf eine fehlerhafte Zonen-Delegierung hinweist:

Hinweis auf fehlerhafte Zonen-Delegierung

Schritt 2 - Fehler beseitigen: Ein reiner Klick auf “Nameserver überprüfen” bringt hier nichts. Es muss noch im Hetzner Robot, bei den Domains 1x auf “Domain ändern” geklickt werden. Aktualisiere ich dann die Seite, ist die oben erwähnte rote Fehlermeldung weg. Zudem wird die Korrektur via Mail bestätigt. Erst im Anschluss führt der Klick in der Hetzner Console “Nameserver überprüfen” das gewünschte Ergebnis und die Meldung verschwindet.

Fazit

Die Migration und das Troubleshooting meiner unvollständigen Domain-Registrierung hat mich gestern überhaupt nicht gestört. Es war alles irgendwie plausibel, nachvollziehbar und super dokumentiert. Zeit gekostet hat es dennoch. Wenn ich aber erneut über so ne Migration stolpere oder mich beim nächsten Domainkauf über Fehlermeldungen wundere, dann lese ich halt meinen eigenen Blog-Artikel. 😎

DNS Console zieht um

Domain-Erwerb und Zonen-Datei

Fazit

Quellen