// KOSTENLOSES TOOL · NAMESERVER-DELEGIERUNG PRÜFEN
Nameserver-Änderung nicht aktiv?
Du hast die Nameserver geändert und nach außen passiert nichts. Gib die Domain ein: diese Seite fragt zwei unabhängige öffentliche Resolver, was die Registry für sie wirklich gespeichert hat. Eine NS-Abfrage auf deine Domain hat drei Antworten, nicht zwei — NOERROR mit NS-Records heißt, die Delegierung steht und du wartest auf ablaufende Caches; NXDOMAIN heißt, die übergeordnete Zone hat gar keine Delegierung für deine Domain; SERVFAIL heißt, die Delegierung existiert, aber kein autoritativer Server hat geantwortet. Kostenlos, sofort, ohne Anmeldung, alles im Browser.
Domain, Hostname oder komplette URL — www.beispiel.de und https://beispiel.de/blog funktionieren beide. NS, SOA, MX und TXT werden auf der registrierbaren Domain abgefragt, A und AAAA auf dem Hostnamen, den du eingibst.
Einer pro Zeile oder durch Komma getrennt. Wenn du das ausfüllst, sagt dir die Prüfung zusätzlich, ob genau dieser Satz auch der ist, den das öffentliche Internet zurückgibt.
Oder eines dieser Beispiele — jedes trifft eine andere der drei Antworten:
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.
- Domain eingeben. Domain, Hostname oder URL eintippen und auf Prüfen klicken. Die Seite fragt dns.google und cloudflare-dns parallel nach NS, SOA, A, AAAA, MX und TXT — zwei unabhängige Sichten auf dasselbe öffentliche DNS.
- 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.
- Dann die beiden Resolver vergleichen. Liefern dns.google und cloudflare-dns unterschiedliche Nameserver oder Adressen, hält einer von beiden noch eine ältere Kopie — das ist Propagation und sie endet von selbst. Sind sich beide einig und die Antwort ist trotzdem falsch, ist gar nichts unterwegs: die Änderung hat die Registry nie erreicht.
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.
| Antwort | Bedeutung | Hilft Warten? |
|---|---|---|
NOERROR + NS-Records | Die Registry hat eine Delegierung, und die Nameserver dahinter haben geantwortet. Was hier steht, sieht das öffentliche Internet. | Ja — wenn der gezeigte Satz der neue ist. Steht dort der alte, halten einzelne Caches ihn noch, und die laufen von allein ab. |
NXDOMAIN | Die übergeordnete Zone — de., com., eu. — wurde gefragt und sagt, den Namen gibt es nicht. Es gibt keine Delegierung, der man folgen könnte. | Nein. An diesem Zustand ist nichts unterwegs. |
SERVFAIL | Der Resolver hat von der übergeordneten Zone einen Verweis bekommen, also existiert die Delegierung — und die Server dahinter konnten nicht antworten. Falsche Nameserver, eine Zone, die auf dem neuen Hoster nie angelegt wurde, oder ein DS-Record, der nicht mehr zu den DNSSEC-Schlüsseln passt. | Nein. Da muss jemand die Zone oder den DS-Record reparieren. |
Panel Linevast sagt in seiner Hilfe als einziger Anbieter in diesem Umfeld den richtigen Satz: schau nach 24 Stunden in die ANSWER SECTION, ob dort deine Nameserver stehen. Das Tool oben macht genau das, und noch einen Schritt mehr — es liest zusätzlich den SOA. Eine gesunde Zone beantwortet SOA mit ihrem eigenen SOA; das ist der Beweis, dass die Kette von der Root über die TLD bis zu deinen Nameservern durchläuft. Eine Domain ohne Delegierung antwortet NXDOMAIN und legt den SOA der übergeordneten Zone in die Authority Section — die Registry sagt dir damit wörtlich, dass sie nichts für dich hat. Im Browser sehen beide Fälle identisch aus: eine Seite, die nicht lädt. Es sind zwei völlig verschiedene Probleme.
„Domain update at registrar failed" — was diese Meldung bedeutet
Diese Zeile kennt jeder, der sie einmal gesehen hat: „Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed." Sie bedeutet nicht, dass dein Eintrag falsch war. Sie bedeutet, dass dein Anbieter die Änderung entgegengenommen und beim Weiterreichen an die Registry einen Fehler kassiert hat. Im Kundencenter steht danach je nach Anbieter der neue Satz, der alte Satz — oder, im schlimmsten Fall, gar keiner mehr.
Nach außen ist das nicht sichtbar, und genau deshalb ist die Prüfung oben der einzige verlässliche Weg: sie fragt nicht dein Kundencenter, sondern das öffentliche DNS. Drei mögliche Befunde, drei verschiedene Konsequenzen. Liefern beide Resolver noch den alten Satz und sind sich einig, ist nichts unterwegs — das Update ist nie angekommen, und du brauchst ein Ticket, keinen weiteren Tag Geduld. Liefern sie verschiedene Sätze, ist das Update angekommen und du wartest tatsächlich noch auf Caches. Kommt NXDOMAIN zurück, hat die Domain gerade überhaupt keine Delegierung; das passiert, wenn ein fehlgeschlagenes Update den alten Satz gelöscht hat, bevor der neue geschrieben war.
Warum .de anders ist: DENIC-Zone alle vier Stunden, Nameserver-Vorabprüfung bei .de und .it
Zwei Eigenheiten des deutschen Marktes erklären einen großen Teil der Fälle, die im englischsprachigen Netz gar nicht vorkommen. Beide stehen in Hilfeseiten deutscher Anbieter, aber nirgends zusammen mit dem, was man danach messen soll.
- Die DENIC aktualisiert ihre Zone nicht laufend, sondern in Intervallen — die IONOS-Hilfe nennt alle vier Stunden. Eine Nameserver-Änderung an einer
.de-Domain kann also korrekt eingetragen sein und trotzdem stundenlang nach außen unsichtbar bleiben, ohne dass irgendetwas kaputt ist. Erwarte bei.denicht dieselbe Reaktionszeit wie bei.com. - Bei
.deund.itprüft die Vergabestelle die Nameserver vor der Änderung — so beschreibt es die Alfahosting-Hilfe. Die neuen Nameserver müssen die Zone für deine Domain bereits ausliefern, sonst weist die Registry das Update ab. Das ist die häufigste Ursache hinter „Domain update at registrar failed" bei einer.de: erst die Zone beim neuen Anbieter anlegen, dann die Delegierung umstellen. Andersherum funktioniert es nicht.
Praktische Folge für die Prüfung oben: Bei einer .de-Domain ist ein unveränderter NS-Satz in den ersten vier Stunden noch kein Befund. Ein SERVFAIL dagegen ist sofort einer — dann existiert die Delegierung und die Zone fehlt auf der anderen Seite.
Die stille Ursache: ein Stammdaten-Update setzt die Nameserver zurück
Der Fall, den niemand sucht, weil er zeitlich nicht zur Ursache passt: Laut Alfahosting-Hilfe setzt eine Änderung der Stammdaten im Kundencenter die Nameserver der betroffenen Domains automatisch auf die Standardwerte des Anbieters zurück. Du änderst eine Rechnungsadresse oder einen Ansprechpartner, und drei Wochen nach deinem eigentlichen Umzug fällt die Domain auf die Nameserver des alten Hosters zurück — mit einer alten Zone, in der die halben Records fehlen.
Symptom in der Prüfung oben: die Delegierung ist NOERROR und kerngesund, aber der NS-Satz gehört dem Anbieter, von dem du weggezogen bist, und die Adress-Zeile ist leer oder zeigt auf einen alten Server. Wenn du weißt, welche Nameserver du eingetragen hattest, trag sie in das zweite Feld ein: dann sagt dir die Prüfung wörtlich, welcher Server fehlt und welcher noch ausgeliefert wird. Das ist derselbe Vergleich, den der vierschichtige Domain-Check in der CLI automatisch bei jedem Durchlauf macht.
Wie lange darf es dauern?
Die Antwort, die überall steht, lautet „bis zu 72 Stunden". Sie ist als Obergrenze nicht falsch und als Auskunft wertlos, weil sie dir nichts über deinen Fall sagt. Es propagiert nämlich gar nichts: Nichts wird von Server zu Server kopiert. Die Registry schreibt die neue Delegierung innerhalb von Minuten, und was du danach abwartest, sind ausschließlich Resolver, die die alte Antwort noch zwischengespeichert halten, bis deren TTL abläuft.
Deshalb ist die Obergrenze nicht ein Kalenderwert, sondern die TTL, die auf den alten Records stand, plus die NS-TTL der übergeordneten Zone — bei vielen Registries bis zu 48 Stunden. Standen auf deinen alten Records fünf Minuten, ist die Sache in fünf Minuten erledigt. Standen dort zwei Tage, hilft kein Neuladen. Das Tool oben zeigt zu jeder Antwort die verbleibende TTL der Kopie, die dieser Resolver gerade hält: das ist genau die Zeit, die dieser eine Cache dich noch anlügen kann. Vor dem nächsten Umzug lohnt sich deshalb der umgekehrte Handgriff — die TTL rechtzeitig, mindestens eine alte TTL-Periode vorher, auf 300 Sekunden senken und erst danach umstellen.
Negative Caching: warum NXDOMAIN nach der Reparatur weiterläuft
Die unangenehmste Variante ist die, in der du das Problem behebst und trotzdem nichts passiert. 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" genauso wie eine Adresse; RFC 2308 setzt die Lebensdauer dieser Erinnerung auf den kleineren Wert aus SOA-Minimum und der TTL des SOA-Records selbst — deshalb nennt das Tool dazu genau eine Zahl. Bei com. sind das 900 Sekunden, bei manchen Registries und an der Root ein ganzer Tag.
Wir haben das an eigenen Domains erlebt. Im Juni 2026 verloren vier .app-Domains ihre Delegierung bei der Registry und antworteten weltweit 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 diesem Abend trotzdem tot, weil die Resolver noch in ihrem negativen Cache-Fenster steckten. Zwei Dashboards meldeten die ganze Zeit „alles in Ordnung": die Cloudflare-Zone stand auf active, das Statusfeld beim Registrar auf verified. Nur das öffentliche autoritative DNS, aus zwei unabhängigen Resolvern gelesen, hat die Wahrheit gesagt.
Was ein Browser nicht sehen kann
Die Grenze dieser Seite gehört dazu. Ein Browser kann nur mit rekursiven Resolvern über HTTPS sprechen. Er liest also zwei Dinge: ob die Delegierungskette auflöst und was die Zone antwortet. Er kann die Nameserver deiner TLD nicht direkt befragen, er sieht dein Kundencenter nicht, und er sieht nichts ober- oder unterhalb von DNS — keinen Proxy vor deiner Seite, kein Zertifikat, das noch nicht ausgestellt ist, keine Hosting-Zuordnung, die nie angelegt wurde, keinen Origin, der 502 liefert. Alle diese Fälle fühlen sich an wie „die Seite ist nach dem Nameserver-Wechsel offline", und keiner davon ist DNS.
clize domain check <domain> ist dieselbe erste Schicht mit drei weiteren darüber. Es fährt exakt dieselbe Doppel-Resolver-Abfrage über DoH — dns.google zuerst, cloudflare-dns als Fallback, RCODE als drei Zustände gelesen — und prüft danach die Cloudflare-Zone, die Bindung des Hostnamens an den Site-Worker und ob tatsächlich Inhalt ausgeliefert wird. Vier Schichten, ein Befehl. Ohne Domain-Argument läuft die Prüfung über alle Domains des Accounts. Zusätzlich prüft die Plattform im Hintergrund: ein Cron alle 30 Minuten, und eine Warn-E-Mail erst nach zwei aufeinanderfolgenden Fehlläufen, damit ein einzelner wackeliger DoH-Antwortsatz niemanden weckt.
Genau dieser Check ist das Ergebnis des Juni-Ausfalls oben. Wenn du wissen willst, was daran noch hängt: Agent Domains zeigt Kauf, Import und Anbindung von Domains über die CLI, Domains programmatisch registrieren beschreibt denselben Weg aus dem Code heraus, und die Befehlsreferenz listet alles auf, was die CLI kann (beides auf Englisch).
// FAQ
Nameserver-Änderung nicht aktiv — wie erkenne ich, ob sie nur dauert oder kaputt ist?
Frag NS auf deiner Domain ab und lies den Antwortcode, nicht die Uhr. NOERROR mit NS-Records heißt: die Delegierung steht und du wartest auf ablaufende Caches. NXDOMAIN heißt: die übergeordnete Zone hat keine Delegierung für deine Domain, und Warten ändert daran nichts. SERVFAIL heißt: die Delegierung existiert, aber kein autoritativer Server hat geantwortet. Vergleich danach zwei unabhängige Resolver: widersprechen sie sich, ist das Propagation und sie endet von selbst; sind sie sich einig und die Antwort ist trotzdem falsch, hat die Änderung die Registry nie erreicht.
Was heißt „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 bekommen. Der Eintrag im Kundencenter sagt darüber nichts aus — prüf die Delegierung im öffentlichen DNS. Liefern beide Resolver einig den alten Satz, ist nichts unterwegs und du brauchst ein Ticket. Bei .de ist die häufigste Ursache die Vorabprüfung der Vergabestelle: die neuen Nameserver müssen die Zone für deine Domain bereits ausliefern, sonst weist die Registry das Update ab.
Wie lange dauert eine Nameserver-Änderung bei einer .de-Domain?
Es gibt keine feste Zahl, und „bis zu 72 Stunden" ist nur eine Obergrenze. Die DENIC aktualisiert ihre Zone in Intervallen — die IONOS-Hilfe nennt alle vier Stunden —, danach wartest du nur noch auf Resolver, die die alte Antwort zwischengespeichert halten. Die tatsächliche Wartezeit ist die TTL der alten Records plus die NS-TTL der übergeordneten Zone. Das Tool auf dieser Seite zeigt zu jeder Antwort die verbleibende TTL, damit du die Zahl ablesen statt schätzen kannst.
Warum liefern zwei DNS-Checker unterschiedliche Nameserver?
Weil sie verschiedene Caches fragen und einer davon noch die Antwort von vor der Änderung hält. Mehr bedeutet „Propagation" nie. Keine der beiden Antworten ist falsch: jeder Resolver meldet, was er zwischengespeichert hat und wie lange diese Kopie noch gilt. Der Widerspruch verschwindet, sobald die ältere Kopie abläuft. Deshalb sagt dir auch eine weltweite Propagations-Karte nur, welche Caches nachgezogen sind — nicht, ob deine Änderung richtig ist.
Meine Nameserver stehen plötzlich wieder auf den Standardwerten. Wie kann das sein?
Ein Update der Stammdaten im Kundencenter setzt bei manchen Anbietern die Nameserver der betroffenen Domains automatisch auf die Standardwerte zurück; die Alfahosting-Hilfe beschreibt das ausdrücklich. Der Zeitpunkt passt dann nicht mehr zu deinem eigentlichen Umzug, deshalb sucht niemand dort. In der Prüfung oben sieht das so aus: die Delegierung ist NOERROR und gesund, aber der NS-Satz gehört dem alten Anbieter und die Adress-Records fehlen oder zeigen woanders hin.
Schickt dieses Tool meine Domain irgendwohin?
Es schickt den Domainnamen an die zwei öffentlichen DNS-Resolver, die es abfragt — dns.google und cloudflare-dns —, denn das ist die Abfrage selbst. An Clize geht nichts: kein Konto, keine Anmeldung, kein Logging auf unserer Seite; die Prüfung ist ein kleines Skript in deinem Browser. Wenn du gar keinen fremden Resolver benutzen willst, kopier die dig-Befehle, die das Tool ausgibt, und führ sie gegen den Resolver deiner Wahl aus.
Ein Browser sieht zwei Schichten. Die CLI sieht vier.
Dieselbe Doppel-Resolver-Prüfung der Delegierung, dazu die Cloudflare-Zone, die Hostname-Bindung und ob wirklich Inhalt ausgeliefert wird — für eine Domain oder für alle im Account. Die Plattform wiederholt das alle 30 Minuten und warnt erst nach zwei aufeinanderfolgenden Fehlläufen.
$ npm i -g @clize/clize && clize install $ clize domain check deine-domain.de[ Agent Domains von Clize → ]