Nameserver prüfen

Warum eine Domain mehrere Nameserver hat

Die NS-Records nennen die Server, die für eine Zone antworten. Sie stehen zweimal: in der Elternzone (bei beispiel.de also bei DENIC, eingetragen über den Registrar) und in der Zone selbst. Ein Resolver wählt einen der Server; antwortet er nicht, versucht er den nächsten. RFC 1034 verlangt deshalb mindestens zwei Nameserver, RFC 2182 empfiehlt, sie in verschiedenen Netzen und an verschiedenen Standorten zu betreiben, damit ein einzelner Ausfall die Domain nicht vom Netz nimmt.

Genau diese Ausfallsicherheit macht Fehler unsichtbar: Fällt einer von zwei Servern aus, weichen die Resolver aus, manche Anfragen dauern ein paar Sekunden länger, sonst passiert nichts. Solche Fehler bleiben oft monatelang unentdeckt, bis auch der zweite Server ausfällt.

NS-Records und SOA-Serial

Jede Zone hat genau einen SOA-Record (Start of Authority). Er nennt den Primary (MNAME), die Adresse des Verantwortlichen (RNAME, das erste @ als Punkt geschrieben) und eine Seriennummer, die bei jeder Änderung der Zone steigt. Secondary-Server vergleichen ihre Serial mit der des Primary und holen die Zone per Zonentransfer (AXFR oder IXFR) neu, sobald sie höher ist. Damit sie nicht auf den nächsten Refresh warten müssen, schickt der Primary nach jeder Änderung ein NOTIFY.

• ns1.hoster.de.: der Primary (MNAME), auf dem die Zone gepflegt wird.
• 2026093001: die Serial, hier im üblichen Schema Datum plus zweistelliger Zähler. Sie muss nur steigen; viele Anbieter setzen sie automatisch, manche als Unix-Zeitstempel.
• 7200 und 3600: Refresh und Retry, also wie oft ein Secondary nachfragt und wie schnell er es nach einem Fehlschlag erneut versucht.
• 1209600: Expire. Erreicht ein Secondary den Primary so lange nicht (hier zwei Wochen), hört er auf, die Zone auszuliefern.

beispiel.de.  IN NS   ns1.hoster.de.
beispiel.de.  IN NS   ns2.hoster.net.
beispiel.de.  IN SOA  ns1.hoster.de. hostmaster.beispiel.de. 2026093001 7200 3600 1209600 3600

Was der Check prüft

Der Check löst jeden Nameserver der Zone auf und fragt ihn direkt, ohne Resolver dazwischen:

• Adresse: Jeder NS-Name muss sich zu mindestens einer IP-Adresse auflösen. Ein Name ohne Adresse ist ein toter Eintrag.
• Erreichbarkeit: Der Server antwortet auf eine SOA-Abfrage. Antwortet keine seiner Adressen, ist er unerreichbar.
• Autorität: Die Antwort trägt das AA-Flag. Antwortet ein Server, aber nicht autoritativ (REFUSED, SERVFAIL, leere Antwort), ist er „lame“: Er steht in der Delegation, kennt die Zone aber nicht.
• Serial und Daten: Weicht die Serial eines Servers desselben Primary (SOA-MNAME) ab, fragt der Check bei jedem Server SOA-Werte, NS, MX, TXT, CAA, A und AAAA der Zone ab. Liefert ein Server andere Daten, hat er die letzten Änderungen nicht bekommen.
• Verteilung: Ein einzelner Nameserver oder alle Adressen im selben /24-Netz sind Hinweise. Ein Stromausfall, ein Routingfehler oder ein DDoS auf dieses Netz nähme die Domain komplett vom Netz.

Lame Delegation nach einem Anbieterwechsel

Der klassische Fall: Die Zone zieht zu einem neuen DNS-Anbieter, beim Registrar bleibt aber einer der alten Nameserver eingetragen, oder in der Zone stehen noch die alten NS-Records. Der alte Anbieter hat die Zone gelöscht und antwortet mit REFUSED. Resolver, die diesen Server erwischen, bekommen keine Antwort und müssen es beim nächsten versuchen; je nach Resolver dauert die Auflösung spürbar länger oder scheitert gelegentlich ganz.

Beim Umzug deshalb die NS-Records beim Registrar und in der Zone gemeinsam umstellen, die alte Zone erst löschen, wenn die TTL der NS-Records abgelaufen ist, und danach mit diesem Check prüfen, ob nur noch die neuen Server antworten.

Secondary bekommt die Zone nicht mehr

Bei Setups mit Primary und Secondary, etwa bei selbst betriebenem DNS mit einem Secondary-Dienst, kommt jede Änderung per NOTIFY und Zonentransfer beim Secondary an. Ist der Transfer gestört, durch eine Firewall, eine geänderte IP-Adresse des Primary oder einen abgelaufenen TSIG-Schlüssel, bleibt der Secondary auf dem alten Stand. Seine Serial hinkt hinterher, und ein Teil der Anfragen bekommt veraltete Records: der alte Mailserver, die alte IP der Website. Nach Ablauf von Expire aus dem SOA hört er ganz auf zu antworten und wird lame.

Mehrere Anbieter und Anycast

Wer DNS über zwei Anbieter betreibt, etwa Cloudflare und Route 53 mit einem Werkzeug, das beide Zonen synchron hält, hat zwei Primaries mit je eigener Serial. Der Check vergleicht Serials deshalb nur zwischen Servern mit demselben SOA-MNAME und meldet das Setup mit mehreren Anbietern als Hinweis.

Einige große Anbieter mit Anycast-Netzen liefern je Server oder Standort bewusst unterschiedliche Serials, weil Änderungen nicht überall gleichzeitig ankommen oder die Serial aus einem Zeitstempel entsteht. Google etwa liefert an ns1 bis ns4 dauerhaft verschiedene Serials bei identischen Daten. Der Check vergleicht deshalb die Daten selbst: Sind sie gleich, ist die andere Serial nur ein Hinweis; A- und AAAA-Records zählen dabei erst als abweichend, wenn ein Server keine einzige Adresse mit den anderen teilt, weil große Anbieter die Adressen je Antwort rotieren. Lässt sich der Abgleich nicht vollständig machen (keine Antwort, Zeitbudget), gibt es weder Warnung noch Entwarnung; er folgt beim nächsten Lauf.

Subdomains und IPv6-only-Nameserver

Eine Subdomain hat meist keine eigenen Nameserver. Gibst du shop.beispiel.de ein, prüft der Check die Zone, zu der sie gehört, hier beispiel.de; hat die Subdomain eigene NS-Records (eine delegierte Subzone), prüft er deren Server. Nameserver, die nur IPv6-Adressen haben, werden nur befragt, wenn der Prüfstandort IPv6 hat. Sonst stehen sie als nicht prüfbar in der Liste, ohne Befund.

So liest du das Ergebnis

• Alle Server erreichbar, autoritativ, gleiche Serial: alles in Ordnung.
• Unerreichbar, lame oder ohne Adresse: Warnung für den betroffenen Server. Die Domain funktioniert meist noch, aber mit einem Server weniger Reserve.
• Abweichende Serial und abweichende Daten beim selben Primary: Warnung mit den betroffenen Record-Typen. Ein Server liefert einen veralteten Stand der Zone. Abweichende Serial bei gleichen Daten: Hinweis.
• Kein Server antwortet autoritativ: kritisch. Die Zone ist aus, Website und Mail sind nicht erreichbar.
• Nur ein Nameserver, alle im selben /24-Netz oder Zonen bei mehreren Anbietern: Hinweise. Im Domain-Check kosten sie keine Punkte.

Nameserver dauerhaft überwachen

Ein toter Secondary tut nicht weh, bis der Primary auch ausfällt, und ein vergessener alter Nameserver fällt nur als gelegentliche Verzögerung auf. DomainWarn prüft die Nameserver jeder Kundendomain je nach Tarif alle 6 bis 24 Stunden, bestätigt einen Befund im nächsten Lauf und meldet tote, lame und hinterherhinkende Server, solange die übrigen die Domain noch tragen.

Häufige Fragen

Was ist der Unterschied zu den Nameservern im Domain Checker?

Der Domain Checker zeigt, welche Nameserver bei der Registry eingetragen sind. Der Nameserver-Check fragt die Server der Zone einzeln ab und prüft, ob sie auch antworten, autoritativ sind und denselben Stand ausliefern.

Wie viele Nameserver sollte eine Domain haben?

Mindestens zwei, besser drei oder vier, in verschiedenen Netzen. Die meisten DNS-Anbieter liefern das von Haus aus; ein einzelner Server oder zwei Server im selben Rechenzentrum kommen vor allem bei selbst betriebenem DNS vor.

Ist eine abweichende Serial immer ein Fehler?

Nein. Manche Anycast-Anbieter zählen die Serial je Server, und direkt nach einer Änderung weicht sie für Sekunden bis Minuten ab. Der Check warnt deshalb erst, wenn ein Server auch andere Daten liefert. Das Monitoring eröffnet einen Vorfall zudem erst nach zwei Läufen in Folge, eine kurze Verteilungsphase löst also keinen Alarm aus.

Warum ist ein Server lame, obwohl er antwortet?

Lame heißt nicht stumm, sondern ohne Autorität: Der Server antwortet, kennt die Zone aber nicht (REFUSED) oder kann sie nicht ausliefern (SERVFAIL). Meist ist es ein Server des früheren DNS-Anbieters, der noch in der Delegation steht.