Nameserver-Änderung nicht aktiv?

So prüfst du, ob die Nameserver-Änderung angekommen ist

Drei Schritte, alle auf dieser Seite. Die Prüfung liest öffentliches DNS über HTTPS aus deinem Browser — sie fasst dein Kundencenter nicht an, und es gibt nichts zu installieren und nichts anzumelden.

1. Domain eingeben. Domain, Hostname oder URL eintippen und auf Prüfen klicken. Die Seite sucht den Eintrag der Registry per RDAP und fragt parallel dns.google und cloudflare-dns nach NS, SOA, A, AAAA, MX und TXT — die aktuelle Antwort der Registry neben zwei unabhängigen Caches.
2. Zuerst die Zeile zur Delegierung lesen. Sie hat genau drei Zustände. NOERROR mit Nameservern heißt: die Delegierung steht, du wartest auf Caches. NXDOMAIN heißt: die übergeordnete Zone hat keine Delegierung für dich, und Warten ändert daran nichts. SERVFAIL heißt: die Delegierung steht, aber die Nameserver dahinter liefern die Zone nicht aus.
3. Dann Registry und Resolver vergleichen. Führt die Registry schon deine neuen Nameserver und ein Resolver liefert noch die alten, hält er eine zwischengespeicherte Kopie — das ist Propagation, sie endet von selbst. Führt die Registry selbst noch den alten Satz, ist nichts unterwegs: die Änderung hat sie nie erreicht. Bei .de, wo der Browser die DENIC nicht lesen darf, vergleichst du die beiden Resolver und holst dir den DENIC-Eintrag mit dem curl-Befehl aus dem Tool.

Drei Antworten, nicht zwei: NOERROR, NXDOMAIN, SERVFAIL

Fast jede Seite zu diesem Thema kennt nur zwei Zustände: es geht, oder es propagiert noch. Dieser Schnitt ist falsch, und er ist der Grund, warum Leute drei Tage auf etwas warten, das sich nie von selbst repariert hätte. NOERROR mit NS-Records = die Delegierung steht, du wartest auf ablaufende Caches; NXDOMAIN = die übergeordnete Zone hat keine Delegierung für deine Domain; SERVFAIL = die Delegierung existiert, aber kein autoritativer Server hat geantwortet.

Linevast bringt es in seiner Wissensdatenbank auf einen Satz: Stehen in der ANSWER SECTION nicht die hinterlegten Nameserver, war das Update nicht erfolgreich. Das Tool liest genau das und zusätzlich den SOA: Eine gesunde Zone antwortet mit ihrem eigenen SOA, eine Domain ohne Delegierung mit NXDOMAIN und dem SOA der übergeordneten Zone in der Authority Section. Im Browser sehen beide gleich aus. Es sind zwei völlig verschiedene Probleme.

„Domain update at registrar failed“: die Vorabprüfung der DENIC

Im netcup-CCP lautet die Meldung „Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed.“ Dein Anbieter hat die Änderung angenommen und beim Weiterreichen an die Registry einen Fehler kassiert. Bei .de gibt es dafür eine Ursache, die .com nicht kennt: Die DENIC prüft neue Nameserver, bevor sie delegiert. Schlägt dieser Predelegation Check bei einem Update fehl, wird der Auftrag laut DENIC-Dokumentation „mit einem ‚Error‘ abgewiesen“; die alte Delegierung bleibt stehen. Die Pflichtregeln sind genau die Stellen, an denen Umzüge scheitern:

• Jeder Nameserver muss die Zone deiner Domain bereits autoritativ ausliefern (ERROR 116/133): erst die Zone beim neuen Anbieter, dann die Umstellung.
• Die NS-Records in der Zone müssen exakt dem Satz im Auftrag entsprechen (ERROR 118); ein vergessener dritter Nameserver genügt.
• Mindestens zwei Nameserver, einer per IPv4, nicht alle unter derselben IP-Adresse.
• Gehen DNSSEC-Schlüssel mit, muss einer davon in der neuen Zone sichtbar sein (ERROR 213); wer nur den Schlüssel des alten Anbieters mitschickt, lässt das Update scheitern.

Bei einer Neuregistrierung heißt dasselbe Scheitern Status failed: registriert, aber nicht in der Zone, bis binnen 30 Tagen ein Update durchgeht. Vorher selbst testen kannst du auf nast.denic.de. Die Anbieter zeigen die Ablehnung so an:

• IONOS („Benutzerdefinierte Nameserver verwenden“): Status „Ungültige DNS-Einstellungen“, erst mit korrigierten Einstellungen wieder nutzbar; IONOS rät zum Predelegation Check vorab.
• INWX: „Nameserver error“, UPDATE FAILED und der DENIC-Code, etwa ERROR: 104, wenn die Nameserver samt Glue nicht in 512 Byte passen.
• STRATO (Reiter DNS → NS-Record → „Eigene Nameserver“): Solange ein eigener A-, MX- oder SPF-Record oder DynDNS gesetzt ist, steht der NS-Record auf inaktiv.
• Alfahosting: Nameserver ändert nur der Support per Ticket; bei .de und .it müssen die neuen vorher konfiguriert sein.

Nach außen ist das Ergebnis immer gleich: Die Registry führt den alten Satz, beide Resolver liefern ihn einig, und Geduld ändert nichts.

Die .de-Zone ist schneller als ihr Ruf: Minuten, nicht vier Stunden

In der IONOS-Hilfe steht bis heute, die DENIC aktualisiere ihre Zone „nur alle 4 Stunden“, und die erste Fassung dieser Seite hat das übernommen. Das stimmt seit Jahren nicht: Im November 2019 hat die DENIC die stündlichen Zonen-Updates durch minütliche Inkremente ersetzt, und ihre DENICdirect-FAQ nennt auch für Nameserver-Änderungen „in der Regel binnen fünf Minuten“. Nachgemessen am 26. September 2026: Die Seriennummer der de.-Zone ist ein Unix-Zeitstempel, und zwischen 09:32 und 09:39 UTC erschienen 13 Versionen, alle 24 bis 64 Sekunden eine.

Daraus folgt: Bei .de gibt es kein Stundenfenster, in dem ein unveränderter NS-Satz noch normal wäre. dig +norecurse NS deine-domain.de @a.nic.de fragt die DENIC-Zone direkt, ohne Cache dazwischen. Steht dort nach einer Viertelstunde noch der alte Satz, wartest du nicht auf Caches, sondern auf ein Update, das nicht durchgegangen ist. Was danach wirklich dauert, sind Resolver mit der alten Delegierung: Die .de-Zone liefert NS-Records mit 86400 Sekunden TTL aus, also bis zu 24 Stunden.

Wie lange darf es dauern — und was „Propagation“ wirklich ist

Je nach Hilfeseite 24, 48 oder 72 Stunden: STRATO und Linevast nennen bis zu 24, IONOS für eigene Nameserver bis zu 48, auf der Seite zur Dauer von DNS-Änderungen „bis zu 72 Stunden“. Als Obergrenze ist keine davon falsch, als Auskunft taugt keine. Es propagiert nämlich nichts: Die Registry schreibt die neue Delegierung, danach wartest du nur auf Resolver, die die alte Antwort gespeichert haben, bis deren TTL abläuft — die TTL der alten Records plus die NS-TTL der übergeordneten Zone, 86400 Sekunden bei .de, 172800 bei .com. Das Tool zeigt zu jeder Antwort die verbleibende TTL. Zwei Resolver mit verschiedenen Nameservern sind Propagation; zwei, die sich über eine Antwort einig sind, die du nicht eingestellt hast, sind keine. Den Zeitplan für den nächsten Umzug rechnet der DNS-TTL-Rechner.

Die Registry-Zeile oben entscheidet ohne Umweg, wo die Registry es zulässt: RDAP liefert über HTTPS die Nameserver, die sie jetzt führt, und RFC 7480 empfiehlt, Browsern das Lesen öffentlicher Einträge zu erlauben. Führt die Registry schon deine neuen Nameserver, wartest du auf Caches; führt sie noch die alten, ist die Änderung nie angekommen. Am 26. September 2026 ging das unter anderem für .com, .net, .org, .app, .dev, .ai, .info und die Stadt- und Regionalendungen .berlin, .hamburg, .koeln, .bayern und .nrw. Im RDAP-Verzeichnis der IANA fehlen .de, .at, .ch und .eu; dort bleibt die Zeile leer, und die Seite sagt das. Die DENIC betreibt RDAP unter rdap.denic.de, schickt aber keinen CORS-Header: Der Browser darf die Antwort nicht lesen, das Terminal schon.

Was nach einem Nameserver-Wechsel wirklich kaputtgeht

Neun Fehler decken fast alles ab; der Zustand der Delegierung oben sagt dir, in welcher Familie du bist.

1. Die Änderung hat die Registry nie erreicht, bei .de etwa nach einer abgelehnten Vorabprüfung. Symptom: Die Registry-Zeile zeigt die alten Nameserver; bei .de sind sich beide Resolver über den alten Satz einig, und die DENIC zeigt ihn im Terminal.
2. Die Zone fehlt auf den neuen Nameservern. SERVFAIL aus beiden Resolvern. Bei .de lässt die DENIC die Umstellung gar nicht erst zu: weiter bei Punkt 1.
3. DNSSEC wurde mitgenommen. Der DS-Record zeigt auf die Schlüssel des alten Anbieters, validierende Resolver verwerfen alles. SERVFAIL überall; bei gTLDs meldet die Registry-Zeile einen DS. DS entfernen, TTL abwarten, DNSSEC neu aktivieren.
4. Die Records wurden nicht kopiert. Delegierung grün, Adress-Zeile leer. Die DENIC-Prüfung fängt das nicht ab: Sie verlangt SOA und NS, keine Adressen.
5. MX, SPF, DKIM, DMARC fehlen. Mail geht leiser und später kaputt; prüf die MX- und TXT-Zeilen. Wer bei STRATO eigene Nameserver setzt und die Mail dort lässt, pflegt MX, SPF und DKIM laut STRATO-FAQ selbst.
6. Eine alte, lange TTL. Nichts ist kaputt; die verbleibende TTL ist der Countdown.
7. Die Domain ist nicht in der Zone. NXDOMAIN mit dem SOA der übergeordneten Zone. Bei gTLDs zeigt die Registry-Zeile client hold, server hold oder redemption period; bei .de nennt die DENIC im Terminal failed (Vorabprüfung durchgefallen), redemptionPeriod (gelöscht, 30 Tage wiederherstellbar) oder serverHold (von der Registry aus dem DNS genommen).
8. Eine Sperre hat das Update abgewiesen. client update prohibited lässt die Registry Änderungen ablehnen, server update prohibited ist dieselbe Sperre auf Registry-Seite. Steht eine davon neben den alten Nameservern, ist sie der erste Verdacht: die Client-Sperre hebt dein Anbieter auf, die Server-Sperre nur die Registry.
9. Ein Stammdaten-Update hat die Nameserver zurückgesetzt. Laut Alfahosting-Hilfe trägt ein Update der Stammdaten wieder die Standardnameserver ein — Wochen nach dem Umzug, deshalb sucht dort niemand. Delegierung gesund, aber der NS-Satz gehört dem alten Anbieter; bei .de steht das Datum im DENIC-Eintrag unter Changed.

Negative Caching: warum NXDOMAIN nach der Reparatur weiterläuft

Nach einer reparierten Delegierung kann NXDOMAIN so lange weiter zurückkommen, wie die Negative-Cache-TTL läuft (das SOA-Minimum). Resolver merken sich „diesen Namen gibt es nicht“ wie eine Adresse; RFC 2308 nimmt dafür den kleineren Wert aus SOA-Minimum und TTL des SOA-Records. In der de.-Zone sind beide 7200: Eine .de-Domain hängt bis zu zwei Stunden nach, eine .com 900 Sekunden (gemessen am 26. September 2026). Gib einer reparierten .de-Domain also zwei Stunden, und dreh in der Zeit nicht ein zweites Mal am Kundencenter.

Wir haben das selbst erlebt: Im Juni 2026 verloren vier .app-Domains ihre Delegierung und antworteten rund vier Tage lang mit NXDOMAIN. Der Registrar schrieb die Delegierung am 30. Juni um 17:30 UTC zurück, und für einen großen Teil des Netzes blieben die Domains an dem Abend trotzdem tot, weil die Resolver noch im negativen Cache-Fenster steckten. Cloudflare-Zone active, Registrar-Status verified — nur das öffentliche DNS aus zwei Resolvern hat die Wahrheit gesagt (der Vorfall, auf Englisch).

Dieselben Prüfungen im Terminal — und der DENIC-Eintrag

Nichts hier ist proprietär: Jede Zeile lässt sich im Terminal nachstellen, und das Tool gibt die Befehle für deine Domain aus. Die fünf wichtigsten:

dig NS beispiel.com +short          # wohin die Delegierung auflöst
      dig @8.8.8.8 NS beispiel.com +short # dieselbe Frage an einen bestimmten Cache
      dig @1.1.1.1 NS beispiel.com +short # und an einen anderen — zwei Antworten = Propagation
      dig SOA beispiel.com                # bei NXDOMAIN: SOA der ablehnenden Zone
      curl -sL https://rdap.org/domain/beispiel.com   # Registry-Eintrag: Nameserver, Status, DNSSEC

Für .de ersetzen drei Befehle die Registry-Zeile, die der Browser nicht lesen darf:

curl -s https://rdap.denic.de/domain/deine-domain.de   # nameservers, status, keyData, last changed
      whois -h whois.denic.de deine-domain.de               # Nserver, Dnskey, Status, Changed
      dig +norecurse NS deine-domain.de @a.nic.de           # was die .de-Zone gerade delegiert

active (RDAP) bzw. Status: connect (whois) heißt registriert und in der Zone. Für DENICs Beispieldomain im Status failed antwortet RDAP mit inactive: Nameserver im Eintrag, Domain nicht in der Zone, NXDOMAIN. Liegt last changed vor deiner Nameserver-Änderung, ist sie bei der DENIC nie angekommen. dig +trace NS beispiel.de zeigt die ganze Kette ab Root; ohne dig antworten dieselben Resolver über HTTPS, genau so fragt die Seite (Status ist der RCODE: 0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN):

curl -s -H 'accept: application/dns-json' \
        'https://dns.google/resolve?name=beispiel.de&type=NS'

Was ein Browser nicht sehen kann — und was die volle Prüfung ergänzt

Ein Browser spricht mit rekursiven Resolvern und, bei vielen Endungen, mit dem RDAP-Dienst der Registry. Er fragt die Nameserver deiner TLD nicht direkt (das macht dig @a.nic.de), sieht weder dein Kundencenter noch dessen Warteschlange, bei .de nicht die Registry und nichts ober- oder unterhalb von DNS: keinen Proxy, kein fehlendes Zertifikat, keine nie angelegte Hosting-Zuordnung, keinen Origin mit 502. Das alles fühlt sich an wie „offline nach dem Nameserver-Wechsel“ und ist kein DNS.

clize domain check <domain> ist dieselbe erste Schicht mit drei weiteren darüber: dieselbe Doppel-Resolver-Abfrage über DoH (dns.google zuerst, cloudflare-dns als Fallback, RCODE als drei Zustände), dann Cloudflare-Zone, Bindung des Hostnamens an den Site-Worker und ausgelieferter Inhalt — Grün heißt erreichbar, nicht bloß delegiert. Ohne Argument prüft es alle Domains des Accounts; die Plattform wiederholt das alle 30 Minuten und warnt erst nach zwei Fehlläufen in Folge. Entstanden ist der Check aus dem Juni-Ausfall, zusammen mit einer Delegierungsprüfung nach jedem Deploy. Mehr: Agent Domains, Domains programmatisch registrieren, Befehlsreferenz (auf Englisch).

$ npm i -g @clize/clize && clize install
$ clize domain check deine-domain.de