NS-Abfrage — Nameserver einer Domain abfragen

Nameserver abfragen für jede Domain: die NS-Einträge, die ihre Registry ausgibt, mit Glue und TTL, neben dem, was jeder Nameserver selbst sagt. Lame Server, Abweichungen und veralteter Glue werden benannt, samt Lösung.

Quellen: die Server der Registry, erreicht über einen Root-Server · die IPv4-Adressen jedes Nameservers, direkt gefragt · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Was ist ein NS-Eintrag?

Ein NS-Eintrag nennt einen Server, der eine Zone hält: den Ort, an dem die Einträge einer Domain liegen. Eine Zone listet einen NS-Eintrag pro Server, daher hat google.com vier, ns1 bis ns4.google.com (RFC 1035 §3.3.11).

Dieselben NS-Einträge gibt es zweimal. Die Parent-Zone, hier .com, hält an der Zonengrenze eine Kopie, um Resolver weiterzuschicken; diese Kopie ist nicht autoritativ. Die Zone hält an ihrer Spitze ihre eigene Kopie, und diese ist es (RFC 1034 §4.2.1, RFC 2181 §6.1). Beide sollten genau gleich sein.

Der Wert ist immer ein Hostname, nie eine Adresse und nie ein Alias: Der Name muss eigene A- oder AAAA-Einträge haben (RFC 2181 §10.3).

Ein NS-Eintrag, Teil für Teilgoogle.com · aufgezeichnet am 2026-10-23
google.com.Inhaber345600TTLINKlasseNSTypns1.google.com.Wert
InhaberDie Zone, zu der der Eintrag gehört.
TTL · 4 TageWie lange ein Resolver ihn behalten darf. Die Kopie der Zone .com nennt 2 Tage.
NSEintragstyp 2: ein Nameserver für diese Zone.
WertEin Hostname mit eigenen A- oder AAAA-Einträgen.
Die Kopie der Parent-Zone · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Nicht autoritativ: ein Verweis, mit Glue
Die eigene Kopie der Zonegoogle.com. 345600 NS ns1.google.com.;; flags: qr aaAutoritativ: was Resolver behalten
ns1.google.com.Ein Hostname mit eigenen Adressen
216.239.32.10Eine Adresse ist kein gültiger Wert
ns.example.com. → CNAMENie ein Alias (RFC 2181 §10.3)
Beide Kopien live aufgezeichnet: der Verweis der .com-Registry von l.gtld-servers.net und die eigene Antwort von ns1.google.com.

So können Sie die Nameserver einer Domain abfragen

Geben Sie oben die Domain ein und drücken Sie Nameserver prüfen: Wir fragen die Registry, dann jeden Server, den sie nennt und den unser Server erreichen kann. Im Terminal: dig NS example.com unter macOS und Linux, nslookup -type=ns example.com unter Windows, Resolve-DnsName -Name example.com -Type NS in PowerShell.

Diese drei fragen Ihren eigenen Resolver und zeigen daher eine Kopie im Cache. Um die Liste der Registry zu sehen, fragen Sie ihren Server ohne Rekursion: dig @a.gtld-servers.net example.com NS +norec. Um einen einzelnen Nameserver zu testen, fragen Sie ihn mit +norec nach dem SOA und achten Sie auf aa in den Flags. whois zeigt ebenfalls die Liste der Registry, nicht die der Zone.

dig NS example.com +short

Die Kopie Ihres Resolvers, ein Nameserver pro Zeile. Mit @a.gtld-servers.net und +norec erhalten Sie die eigene Liste der .com-Registry.

Die beiden Antworten von dig lesengoogle.com · aufgezeichnet am 2026-10-23
dig (macOS, Linux)
$ dig @l.gtld-servers.net google.com NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91
;; AUTHORITY SECTION:
google.com.       172800  IN  NS  ns2.google.com.2
google.com.       172800  IN  NS  ns1.google.com.
…
;; ADDITIONAL SECTION:
ns1.google.com.   172800  IN  A   216.239.32.103
…

$ dig @216.239.32.10 google.com NS +norec
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04
google.com.       345600  IN  NS  ns1.google.com.5
…
  1. Kein aa: ein Verweis. Die Registry bedient google.com nicht; sie sagt, wohin man sich wenden soll.
  2. Die Liste der Parent-Zone und ihre TTL: 2 Tage, gesetzt von der .com-Registry.
  3. Glue: ns1.google.com liegt innerhalb von google.com, daher liefert .com seine Adresse mit.
  4. aa: die Zone selbst. Eine autoritative Antwort des Servers.
  5. Die eigene TTL der Zone: 4 Tage, gesetzt von Google, nicht von der Registry.
nslookup · fragt 8.8.8.8
$ nslookup -type=ns google.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
google.com  nameserver = ns3.google.com.
google.com  nameserver = ns1.google.com.
…
PowerShell
# Kopie Ihres Resolvers
PS> Resolve-DnsName -Name google.com -Type NS

# ein Server, Rekursion aus
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
whois
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
Aufgezeichnet am 2026-10-23. „Non-authoritative answer“ bedeutet die Kopie eines Resolvers im Cache, hier von Google Public DNS, das NS-Einträge höchstens 6 Stunden behält. whois gibt die Liste der Registry aus. Keines davon zeigt, was jeder Server selbst sagt.

Das Ergebnis lesen

Der Befund nennt den DNS-Hoster und den Registrar; die Ansicht Delegation stellt die Liste der Registry neben die der Zone, Server für Server, mit der Antwort jedes Servers und seiner Zeit über TCP (der Verbindungsaufbau eingeschlossen, also etwa zwei Round Trips).

Die marineblaue Spalte ist der Weg eines Resolvers: die Root, die Registry mit ihrer TTL und ihrem DS, dann jeder Nameserver. Ein Server, der die Zone nicht bedient, ist abgetrennt dargestellt.

NS-Abfrage von github.com: acht Nameserver bei NS1 und Route 53, die Antwort jedes Servers und die Delegation von .comNS-Abfrage von github.com: acht Nameserver bei NS1 und Route 53, die Antwort jedes Servers und die Delegation von .comDer BefundWer die Zone bedient, wer sie registriert hat und ob Registry und Zone übereinstimmen.Die Registry neben der ZoneJeder Name in der Liste der Registry und in der eigenen der Zone, mit Glue und der Antwort.Die Antwort jedes ServersAA und seine Zeit über TCP, der Code eines verweigernden Servers oder über 1.1.1.1, wo unser Server sich nicht verbinden kann.Die DelegationRoot, Registry, dann die eigene Antwort jedes Servers, so wie ein Resolver sie durchläuft.
Eine NS-Abfrage von github.com: der Befund, die acht Nameserver der Registry neben der eigenen Liste der Zone, die Antwort jedes Servers und die Delegation von der .com-Registry. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

Parent- vs. Child-Nameserver: warum sie abweichen

Zwei verschiedene Stellen führen die beiden Listen. Die Registry veröffentlicht die Liste der Parent-Zone, wenn Ihr Registrar es ihr aufträgt; Ihr DNS-Hoster liefert die eigene Liste der Zone. Ändern Sie nur eine davon, laufen sie auseinander.

Resolver vertrauen der eigenen Antwort der Zone mehr als dem Verweis (RFC 2181 §5.4.1), daher behalten sie nach einer Abfrage der Zone deren Liste und deren TTL. Am 2026-10-23 hielt der Resolver von Cloudflare den NS-Satz von google.com mit 340.859 s Restlaufzeit: mehr als die 172.800 von .com, die Kopie stammte also von der TTL der Zone von 4 Tagen.

Ein Name nur in der Liste der Registry bekommt weiter Verkehr von Resolvern, die frisch beginnen. Ein Name nur in der Zone ist für sie unsichtbar. Beides sollte behoben werden; keines ist für sich ein Ausfall.

Die Liste der Registry neben der der Zoneaufgezeichnet am 2026-10-23
xserver.ne.jp5 vs. 3

Registry von .jp1 Tg.

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpnur Registry
  • ns5.xserver.jpnur Registry

Zone1 Std.

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp

ns4.xserver.jp und ns5.xserver.jp stehen nur bei der Registry. Beide antworten autoritativ, daher geht nichts kaputt; die Listen weichen trotzdem ab.

github.comdieselben 8

Registry von .com2 Tg.

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Zone15 Min. · 1 Std.

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Dieselben Namen, verschiedene Uhren: Die Kopie der Registry gilt 2 Tage, die von Route 53 15 Minuten, die von NS1 1 Stunde.

Eine .net-Domain(Name zurückgehalten)kein gemeinsamer Name

Registry von .net2 Tg.

  • ns1.domaindirect.comnur Registry
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comnur Registry

Zone15 Min.

  • ns1.hover.comnur Zone
  • ns2.hover.comnur Zone

Die Registry listet noch die alten Namen. Zwei davon teilen sich Adressen mit den Servern von Hover und antworten; der dritte verweigert.

Linien verbinden die Namen, die beide Listen teilen; eine gestrichelte Linie verbindet zwei Namen auf einer Adresse. Der dritte Fall ist eine echte Registrierung aus einem Zufallsscan; ihr Name wird zurückgehalten.

Was sind Glue-Einträge?

Glue ist eine Adresse, die die Parent-Zone mit ihrem Verweis mitliefert, damit ein Resolver einen Nameserver erreichen kann, dessen Name innerhalb der Zone liegt, die er bedient. Ohne sie hieße das Finden von ns1.google.com, die Server von google.com zu fragen, und das ist genau die Frage, mit der Sie begonnen haben (RFC 1034 §4.2.1).

RFC 9471 macht daraus eine Regel: Ein Verweis MUSS den Glue jedes In-Domain-Servers enthalten (ns1.google.com für google.com) und SOLLTE ihn für Sibling-Server unter derselben Parent-Zone enthalten (ns-421.awsdns-52.com für github.com). Ein fremder Name wie ns-520.awsdns-01.net wird eigenständig aufgelöst.

Glue wird beim Registrar gesetzt, als Host-Einträge, Child-Nameserver oder persönliche DNS-Server. Zieht ein Server um, muss der Glue mitziehen: Veralteter Glue schickt Resolver zu einer Adresse, die nicht mehr antwortet.

Glue, und wann er nötig istbei .com aufgezeichnet, 2026-10-23

In-Domain · google.com

  1. .com: ns1.google.com fragen
  2. Seine Adresse liegt in google.com selbst
  3. ohne Glue dreht sich die Abfrage im Kreis
  4. Daher fügt .com ns1.google.com A 216.239.32.10 hinzu · MUSS: erforderlich

Sibling und fremd · github.com

  1. .com: ns-421.awsdns-52.com, ns-520.awsdns-01.net, … fragen
  2. awsdns-52.com liegt ebenfalls unter .com: Glue 205.251.193.165 · SOLLTE: enthalten
  3. awsdns-01.net liegt anderswo: Der Resolver löst ihn bei .net auf · kein Glue
Veralteter Glue · live64.69.208.141Glue von .com für ns1.register.com · keine Antwort, zweimal gefragt162.214.41.25sein A-Eintrag heute · antwortet autoritativ
Das Host-Objekt von ns1.register.com bei .com, am 2026-10-23 über rdap.verisign.com gelesen: Die Registry hält noch eine Adresse, die der Server verlassen hat, und liefert sie als Glue aus.

Was ist eine Lame Delegation, und wie behebt man sie?

Eine Delegation ist lame (fehlerhaft), wenn die Parent-Zone Resolver zu einem Server schickt, der die Zone nicht bedient: Er verweigert, schweigt oder antwortet ohne Autorität. Ist jeder gelistete Server lame, löst sich die Domain nicht mehr auf; ist es einer von mehreren, werden Abfragen langsamer, während Resolver es erneut versuchen.

RFC 9499 stellt fest, dass „lame delegation“ inzwischen mehrere Fehler umfasst, daher benennt das Tool jeden einzeln: verweigert die Zone (REFUSED), keine Antwort (zweimal gefragt), antwortet ohne Autorität (kein aa), Serverfehler (SERVFAIL). Schweigen allein über TCP gilt nicht als lame, solange Google und Cloudflare die Domain noch auflösen: Es heißt keine TCP-Antwort, da dieser Server über UDP antworten kann.

Die Lösung liegt immer auf einer von zwei Seiten: die Zone bei dem DNS-Hoster anlegen, auf den die Registry zeigt, oder die Registry auf den Hoster zeigen lassen, der die Zone hat. Resolver können sich den Fehler nach der Korrektur bis zu 5 Minuten lang merken (RFC 9520).

Drei lame Server, aufgezeichnet2026-10-23 · Domains zurückgehalten

Verweigert die Zone

ns63 · ns64.domaincontrol.com

Beide Server von GoDaddy, die .com nennt, antworten mit REFUSED: Die Zone ist dort nicht eingerichtet.

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

Ein Timeout, dann REFUSED

ns1 · ns2.eftydns.com

Ein Server lief einmal in ein Timeout und antwortete bei erneuter Frage mit REFUSED. Ein Timeout ist kein Urteil: Das Tool fragt erneut, bevor es einen Zustand benennt.

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# erneut gefragt
;; … status: REFUSED

Einer von dreien

ns1 · ns2 · ns3.domaindirect.com

Zwei Server antworten autoritativ; der dritte verweigert. Die Domain funktioniert, nur langsamer.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Sehen, wohin die Registry zeigtDie Ansicht Delegation listet die Server der Registry und die Antwort jedes einzelnen.
  2. Eine Seite korrigierenDie Zone bei diesem Hoster anlegen oder die Nameserver beim Registrar ändern.
  3. Erneut prüfenAntworten kommen sofort zurück; ein zwischengespeicherter Fehler hält bis zu 5 Minuten.

Was Besucher bekommen, wenn jeder Server lame ist:Google SERVFAILCloudflare SERVFAIL

Aufgezeichnet an Registrierungen aus einem Zufallsscan; ihre Namen werden zurückgehalten und als example.com und example.net gezeigt.

Wie viele Nameserver braucht man?

Mindestens zwei: „The DNS specification and domain name registration rules require at least two servers for every zone“ (RFC 2182 §5, BCP 16). Derselbe Abschnitt empfiehlt drei für die meisten Organisationen, einen davon weit von den anderen entfernt, und vier oder fünf, wo Zuverlässigkeit wichtiger ist.

Zählen Sie Netze, nicht Namen. Server sollten dort stehen, wo ein Ausfall nicht alle erreichen kann (RFC 2182 §3.1): Sechs Server in einem /22 teilen sich ein Routingschicksal. Anycast verteilt eine Adresse auf viele Standorte und ist die übliche Antwort, bleibt aber ein Betreiber; ein zweiter Anbieter überlebt dessen Ausfall (RFC 8901).

Mehr ist in Ordnung. Das alte Limit von sieben in RFC 1912 stammte von UDP-Antworten mit 512 Byte; große Zonen betreiben heute acht (github.com, bbc.co.uk).

Server, nach Netz gruppiertaufgezeichnet am 2026-10-23
DomainServer nach NetzNSNetzeBefund
google.comGoogle · AS15169 · Anycast41Anycast, ein Betreiber
github.comNS1 · AS62597Route 53 · AS16509 · Anycast82Zwei Anbieter
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Zwei Netze
xserver.ne.jpXserver · AS131965Amazon · AS1650952Zwei Netze
craigslist.orgcraigslist · AS2241461Ein /22

„Es wird empfohlen, für die meisten Zonen auf Organisationsebene drei Server bereitzustellen, von denen mindestens einer weit von den anderen entfernt sein muss.“

RFC 2182 §5 · BCP 16, Juli 1997 · zwei erforderlich, drei empfohlen
Ein Kasten ist ein Netz (AS); ein getönter Kasten ist ein Anycast-Anbieter: viele Standorte, ein Betreiber. Das zweite Netz von xserver.ne.jp ist ns2.xserver.jp bei Amazon; die sechs Server von craigslist.org teilen sich ein /22.

So ändern Sie Nameserver, und wie lange es dauert

Ändern Sie sie dort, wo die Domain registriert ist, nicht beim DNS-Hoster: Der Registrar schickt die neue Liste an die Registry, und die Registry veröffentlicht sie. Legen Sie die Zone zuerst beim neuen Hoster an, mit allen Einträgen, damit die neuen Server in dem Moment antworten, in dem sie genannt werden.

Dann laufen zwei Uhren. Resolver, die den Verweis der Registry zwischengespeichert haben, behalten die alte Liste bis zu der TTL der Parent-Zone: 2 Tage bei .com, 1 Tag bei .de und .jp, 1 Stunde bei .org. Resolver, die die Zone schon gefragt haben, behalten den alten eigenen NS-Satz der Zone für dessen TTL, die länger sein kann: Bei google.com sind es 4 Tage. Google Public DNS behält NS höchstens 6 Stunden.

Es sind also nie pauschal „24–48 Stunden“. Lassen Sie den alten DNS-Hoster dieselben Einträge weiter beantworten, bis die längere Uhr abgelaufen ist, und entfernen Sie bei einer signierten Domain den DS vor dem Umzug (RFC 6781).

Wo man sie ändert, und die UhrenTTLs gemessen am 2026-10-23

Beim Registrar: die jeweils eigene Anleitung

Wie lange die Kopie der Registry gilt (NS-TTL der Parent-Zone)

  • .ru4 Tage345.600 s
  • .com2 Tage172.800 s
  • .uk2 Tage172.800 s
  • .de1 Tag86.400 s
  • .jp1 Tag86.400 s
  • .tr12 Stunden43.200 s
  • .dev3 Stunden10.800 s
  • .org1 Stunde3.600 s
  • .io1 Stunde3.600 s
  • .in15 Minuten900 s

Die Uhren nach einer Änderung

  • Alter Verweis in Cachesdie TTL der Parent-Zone.com: bis zu 2 Tage
  • Alter NS-Satz der Zone in Cachesdie TTL der alten Zonegoogle.com: bis zu 4 Tage
  • Google Public DNSseine Obergrenze für NShöchstens 6 Stunden
TTLs der Parent-Zonen von den eigenen Servern jeder Registry (dig +norec); .io antwortete 3.600 s, nicht die oft genannten 300 s. Registrare nennen weiter pauschale Zeiten: GoDaddy „up to 48 hours“, Namecheap „up to 24 hours“.

NS vs. SOA vs. Glue-Einträge

Drei Einträge treffen an einer Delegation zusammen. NS nennt die Server: Die Kopie der Parent-Zone weist den Weg, die Kopie der Zone ist die Autorität. Glue ist ein A- oder AAAA-Eintrag, den die Parent-Zone nur für Server hält, die innerhalb der Zone benannt sind. SOA gibt es einmal pro Zone, an ihrer Spitze: den Primary-Server, eine Kontaktadresse, die Seriennummer und die Timer.

Ein Server, der das SOA mit dem Flag aa beantwortet, hält die Zone, deshalb fragt das Tool jeden Server danach. Die Seriennummer zeigt, ob die Server dieselbe Version haben; Route 53 beginnt bei 1 und ändert sie nie von selbst, und eine Zone bei zwei Anbietern trägt zwei Seriennummern, beides normal.

Zwei Zonen, eine Grenzegoogle.com · aufgezeichnet am 2026-10-23

Die Zone .combetrieben von Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Delegation: wohin es weitergeht · nicht autoritativ
  • Ans1.google.com. 172800 A 216.239.32.10Glue: die Adresse des Servers, damit er erreichbar ist
  • DSkein DS: google.com ist nicht signiertDS: verweist auf den Signierschlüssel der Child-Zone; nur bei signierten Zonen (cloudflare.com DS 2371 13 2)

Zonengrenze · google.com

Die Zone google.combetrieben von Google

  • NSgoogle.com. 345600 NS ns1.google.com.Die eigene Liste der Zone · autoritativ
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Einer pro Zone: Primary, Kontakt, Seriennummer, Timer
  • Ans1.google.com. 345600 A 216.239.32.10Die eigene Adresse des Servers: Der Glue sollte dazu passen
Glue und der eigene A-Eintrag des Servers sind zwei Kopien einer Tatsache; weichen sie ab, ist der Glue veraltet.

NS-Abfrage vs. der Befehl nslookup

Unter „ns lookup“ suchen Leute zwei Dinge: die Nameserver einer Domain und den Befehl nslookup, der bei Windows, macOS und Linux dabei ist. nslookup fragt Ihren Resolver und gibt aus, was er im Cache hat; mit -type=ns listet es den NS-Satz der Zone so, wie Ihr Resolver ihn hält.

Diese Kopie kann Stunden alt sein, und sie zeigt nie die Liste der Registry, den Glue oder ob jeder Server die Zone hält. Diese Seite fragt jeden davon, den sie erreichen kann, direkt.

Drei Wege, Nameserver abzufragen
Dieser NS Lookupdnsrobot.netnslookup-type=nsdigNS · +norec
Fragtdie Registry, dann jeden ServerIhren Resolvereinen beliebigen Server, den Sie nennen
Registry vs. Zonebeide, Name für Namedie Kopie im Cacheeine Liste pro Befehl
aa jedes Serversjede IPv4-Adresse (A und Glue)Neinein Server pro Befehl
Glue und TTLsbeide TTLsmit -debugin der Ausgabe
Diagnosebenannt, mit LösungNeinNein
Läuft injedem BrowserWindowsmacOSLinuxmacOSLinux

NS-Abfrage: häufig gestellte Fragen

Was ist eine NS-Abfrage?

Eine NS-Abfrage fragt das DNS, welche Nameserver die Zone einer Domain halten. Dieses Tool fragt zuerst die Registry, nach der Liste der Parent-Zone mit Glue und TTL, dann die IPv4-Adressen jedes Nameservers direkt über TCP nach dem SOA der Zone und ihrem eigenen NS-Satz und vergleicht beides. Sie sehen, wer das DNS hostet, welche Server autoritativ antworten und alles, was Resolver scheitern oder langsamer werden lässt.

Wie finde ich heraus, wer mein DNS-Anbieter ist?

Schauen Sie auf die Nameserver-Namen: ns1.google.com ist Google, *.ns.cloudflare.com ist Cloudflare, ns-*.awsdns-* ist Amazon Route 53, 01.dnsv.jp ist Onamae.com. Diese Abfrage benennt den DNS-Hoster nach dem dokumentierten Namensmuster jedes Anbieters und zeigt das Netz hinter jeder Adresse getrennt, weil manche Hoster im Netz einer anderen Firma laufen: Porkbun und Hostinger bei Cloudflare, Vercel bei NS1.

Warum listen Registry und Zone unterschiedliche Nameserver?

Die Liste der Registry, beim Registrar gesetzt, und die eigenen NS-Einträge der Zone, beim DNS-Hoster gesetzt, sind zwei getrennte Kopien, und laut RFC 1034 sollten sie genau gleich sein. Sie laufen auseinander, wenn jemand nur eine ändert, oft nach einem Umzug zwischen DNS-Hostern. Resolver, die bei der Registry beginnen, nutzen deren Liste, solche, die die Zone gefragt haben, behalten die der Zone.

Was ist eine Lame Delegation?

Eine Lame Delegation ist ein von der Registry gelisteter Nameserver, der die Zone nicht bedient: Er antwortet REFUSED oder SERVFAIL, antwortet ohne Autorität oder gar nicht. Ist jeder gelistete Server lame, löst sich die Domain nicht mehr auf, und Google und Cloudflare antworten mit SERVFAIL. Beheben Sie das, indem Sie die Zone bei diesem DNS-Hoster anlegen oder die Nameserver beim Registrar auf den Hoster ändern, der sie hat.

Wie lange dauert die Verbreitung einer Nameserver-Änderung?

Bis zur längeren von zwei Uhren: der NS-TTL der Registry (2 Tage für .com und .net, 4 Tage für .ru, 1 Tag für .de und .jp, 1 Stunde für .org und .io, 15 Minuten für .in) und der eigenen NS-TTL der alten Zone, die Resolver behalten, die den alten Hoster schon gefragt haben. Google Public DNS begrenzt sie auf etwa 6 Stunden. Ein pauschales „24–48 Stunden“ ist in beide Richtungen falsch.

Wie viele Nameserver sollte eine Domain haben?

Mindestens zwei: RFC 2182 verlangt zwei, empfiehlt drei für die meisten Organisationen mit mindestens einem weit von den anderen entfernten und vier oder fünf für höhere Zuverlässigkeit. Wichtiger als die Zahl ist, dass kein einzelner Ausfall alle trifft: andere Netze oder Anbieter. Anycast-Server eines Betreibers, etwa Cloudflare oder Route 53, sind viele Standorte, aber doch ein Betreiber.

Was sind Glue-Einträge, und wann brauche ich sie?

Glue ist die Adresse, die die Registry mit ihrem Verweis für einen Nameserver ausgibt, der innerhalb der Zone benannt ist, etwa ns1.example.com für example.com: Ohne sie bräuchte ein Resolver die Adresse des Servers, um den Server zu finden. RFC 9471 macht Glue für solche In-Domain-Namen verpflichtend. Setzen Sie ihn beim Registrar, wo er Host-Einträge, Child-Nameserver oder persönliche DNS-Server heißt.

Warum zeigen verschiedene Tools unterschiedliche Nameserver?

Die meisten Nameserver-Checker fragen einen Resolver, der eine Kopie im Cache zeigt, die nach einer Änderung Tage alt sein kann, während Registry und Zone für sich selbst antworten. Manche Tools zeigen nur die eigene Liste der Zone. Diese Abfrage zeigt die Liste der Registry, die eigene Antwort jedes Servers und die Kopien von Google und Cloudflare nebeneinander, mit der Zeit, die jede Kopie noch hat.

Was bedeutet „nicht direkt geprüft“?

Unser Server läuft im Netz von Cloudflare, und ein Cloudflare Worker kann keine Verbindung zu einer Adresse in diesem Netz öffnen. Nameserver dort, die von Cloudflare selbst und die von Hostern, die darauf laufen, wie Porkbun, Hostinger und DigitalOcean, werden stattdessen über den Resolver 1.1.1.1 von Cloudflare gelesen: der NS-Satz und seine TTL, aber nicht das AA-Bit, die Seriennummer oder die Antwortzeit jedes Servers.

Ist eine NS-Abfrage dasselbe wie nslookup?

Nein. nslookup ist ein Kommandozeilenwerkzeug für Windows, macOS und Linux, das einen Resolver nach jedem Eintragstyp fragt, auch NS (nslookup -type=ns example.com). Eine NS-Abfrage ist die Frage selbst: welche Nameserver eine Domain bedienen. Wie dig NS zeigt nslookup die Kopie Ihres Resolvers im Cache; wer wie dieses Tool die Registry und jeden Server direkt fragt, sieht, ob sie übereinstimmen.

Warum zeigt sich meine Nameserver-Änderung noch nicht?

Prüfen Sie drei Stellen: ob die Registry die neuen Server listet (wenn nicht, hat die Änderung Ihren Registrar noch nicht verlassen), ob die neue Zone autoritativ antwortet und wie lange die alten Kopien in Resolvern halten. Der Modus „Ich habe meine Nameserver geändert“ nimmt Ihre neuen Server, vergleicht jede Kopie damit und zählt bis zu dem Zeitpunkt herunter, an dem jeder Resolver sie hat.

Sollte ich DNSSEC vor einem Nameserver-Wechsel entfernen?

Ja, es sei denn, alter und neuer DNS-Hoster arbeiten zusammen. Behält die Registry einen DS-Eintrag, zu dem die Schlüssel des neuen Hosters nicht passen, antworten validierende Resolver wie Google und Cloudflare mit SERVFAIL, und die Domain ist für deren Nutzer nicht erreichbar. Entfernen Sie den DS beim Registrar, warten Sie seine TTL ab, ändern Sie die Nameserver und veröffentlichen Sie dann den DS des neuen Hosters.