Zum Hauptinhalt springen

NS-Record-Abfrage (Nameserver)

Identifizieren Sie die autoritativen DNS-Server Ihrer Domain

Probleme mit der DNS-Delegierung? Überprüfen Sie, ob Ihre NS-Records auf die richtigen Server zeigen und diese ordnungsgemäß antworten.

Im iterativen Tracemodus wird der Resolver ignoriert.
Fragt mehrere öffentliche Resolver ab, um die Antworten zu vergleichen.

Autoritative Server

Entdecken Sie, welche DNS-Server für Ihre Zone verantwortlich sind. Überprüfen Sie deren Konsistenz und Verfügbarkeit.

Multi-Resolver

Vergleichen Sie Antworten von Google, Cloudflare und Quad9, um Propagierungsprobleme zu erkennen.

Delegierungsprüfung

Stellen Sie sicher, dass die NS der übergeordneten Zone mit denen in Ihrer Zone übereinstimmen. Erkennen Sie Inkonsistenzen.

TTL und Migration

Überprüfen Sie den TTL jedes Records, um Ihre DNS-Serveränderungen sicher zu planen.

Kostenlos und unbegrenzt

Testen Sie so viele Domains wie nötig. Keine Anmeldung erforderlich.

Wie Sie die Optionen der DNS-Suchmaschine effektiv nutzen

Was ist der iterative Trace?

Der Trace führt die Auflösung Schritt für Schritt aus. Der Resolver fragt zuerst die Root-Server ab, dann die des TLD (.com, .fr, .eu) und anschließend die autoritativen Server der Zielzone. In jedem Schritt zeigt die Seite den abgefragten Server, die Antwort, den RCODE und die Latenz an.

  1. 1. Root

    Ermittlung der TLD-Server für den angefragten Namen.

  2. 2. TLD

    Verweis auf die NS der Zone (Delegation).

  3. 3. Autoritative Server

    Endgültige Antwort (oder Fehler) mit TTL und Latenz.

Wozu dient das?

  • Antworten nach Resolvern und Regionen vergleichen
  • Einen warmen Cache, einen zu langen TTL oder eine unvollständige Delegation erkennen
  • Einen Latenzunterschied oder einen unerwarteten RCODE erklären

Tipp: Lassen Sie den Trace für schnelle Checks deaktiviert; aktivieren Sie ihn, wenn Sie untersuchen oder ein Ticket/Post‑Mortem vorbereiten.

Was ist der klassische Trace?

Der klassische Trace befragt nur den ausgewählten Resolver (UDP oder DoH) und zeigt die Antwort so, wie sie von diesem Netzpunkt wahrgenommen wird. Sie erhalten den RCODE, die Antwortsektionen sowie die Latenz auf dem Abschnitt Client → Resolver.

  1. 1. Gewählter Resolver

    Verwendet das Preset oder die individuelle Konfiguration, um die Anfrage genau wie Ihr Dienst auszuführen.

  2. 2. Protokoll beibehalten

    Respektiert das ausgewählte Transportprotokoll (UDP, TCP oder DoH), um das reale Verhalten nachzustellen.

  3. 3. Detaillierte Antwort

    Zeigt die Bereiche Question, Answer und Authority/Additional, sofern vorhanden, mitsamt TTL und hilfreichen Metadaten.

Warum nutzen?

  • Die Sicht eines bestimmten Resolvers prüfen, bevor Sie die Delegation verdächtigen
  • Zwischengespeicherte Werte und die Wirkung eines TTL oder Flushs bestätigen
  • Eine Auflösung dokumentieren, wie sie ein Client oder Microservice erlebt

Tipp: Lassen Sie die Option für den iterativen Trace deaktiviert, wenn Sie einen bestimmten Resolver auditieren; aktivieren Sie sie anschließend, um den Pfad Root → TLD → Autoritativ zu vergleichen.

Wie funktioniert der Propagationstest?

Der Test befragt parallel eine Reihe öffentlicher Resolver (Google, Cloudflare, Quad9, OpenDNS, ISPs …) und gruppiert die Antworten nach Inhalt und RCODE. Sie sehen sofort, wer die Aktualisierung bereits übernommen hat.

  1. 1. Multipoint-Resolver

    Aktiviert die Propagations-Presets, um mehrere Akteure weltweit abzufragen.

  2. 2. Automatischer Vergleich

    Gruppiert identische Antworten und hebt Abweichungen oder resolver-spezifische Fehler hervor.

  3. 3. Verwertbare Zusammenfassung

    Liefert eine klare Übersicht, die Resolverliste, deren Latenzen und den Status jeder Gruppe.

Wann einsetzen?

  • Verfolgen, wie sich eine DNS-Änderung weltweit verbreitet
  • Veraltete Caches erkennen und über einen gezielten Flush entscheiden
  • Einen Propagationsstatus in einem Ticket oder Post-Mortem teilen

Tipp: Während des Propagationstests ist die Resolverauswahl gesperrt. Deaktivieren Sie den Modus, um zur Einzelanalyse zurückzukehren.

Was ist ein NS-Record?

Ein NS-Record (Name Server) bezeichnet die autoritativen DNS-Server für eine Zone. Diese Server halten die DNS-Daten der Domain und beantworten Anfragen von rekursiven Resolvern.

NS-Record-Struktur:

FeldBeschreibungBeispiel
NameApex oder Subdomain@ oder subdomain
TypImmer NSNS
ZielDNS-Servernamens1.provider.com.
TTLCache-Dauer in Sekunden86400

Anwendungsbeispiele

Server am Apex

Standard-Deklaration autoritativer Server:

captaindns.com.  86400  IN  NS  ns1.provider.com.
captaindns.com.  86400  IN  NS  ns2.provider.com.

Subdomain-Delegierung

Eine Subdomain an dedizierte Server delegieren:

api.captaindns.com.  3600  IN  NS  ns1.api-provider.com.
api.captaindns.com.  3600  IN  NS  ns2.api-provider.com.

Glue Records

Wenn der NS-Server innerhalb der Domain liegt, die er bedient:

captaindns.com.      86400  IN  NS  ns1.captaindns.com.
ns1.captaindns.com.  86400  IN  A   203.0.113.10

Wichtige Regeln

Konsistenz erforderlich

RegelErklärung
Zone = RegistrarNS müssen in Zone und beim Registrar identisch sein
Mindestens 2 NSRedundanz für Verfügbarkeit erforderlich
Verschiedene NetzwerkeServer sollten geografisch verteilt sein

Best Practices

PraxisWarum
3-4 NS-ServerBessere Resilienz
Langer TTL (86400)Zonenstabilität
Glue bei BedarfVerhindert Auflösungsschleifen

Häufige Probleme

NS-Inkonsistenz

NS in Zone unterscheiden sich vom Registrar. Intermittierende Auflösung.

  1. Überprüfen Sie NS in Ihrer DNS-Zone
  2. Vergleichen Sie mit Registrar-Delegierung
  3. Synchronisieren Sie beide Listen

Unerreichbarer NS-Server

Ein NS-Server antwortet nicht.

  1. Testen Sie jeden Server einzeln
  2. Überprüfen Sie, ob Glue Records korrekt sind
  3. Entfernen Sie den fehlerhaften Server vorübergehend

Nicht funktionierende Delegierung

Delegierte Subdomain löst nicht auf.

  1. Überprüfen Sie NS in der übergeordneten Zone
  2. Stellen Sie sicher, dass Zielserver betriebsbereit sind
  3. Fügen Sie Glue Records hinzu, wenn NS innerhalb der Subdomain liegen

Befehlszeilenüberprüfung

Linux/Mac

dig NS captaindns.com

Konsistenz mit übergeordneter Zone prüfen:

dig NS captaindns.com @a.gtld-servers.net

Windows

nslookup -type=ns captaindns.com

DNS-Server-Migration

Empfohlenes Verfahren

  1. Vorbereiten: Neue Server mit vollständiger Zone konfigurieren
  2. TTL senken: NS-TTL auf 300 Sekunden setzen, alten TTL abwarten
  3. Zone aktualisieren: Neue NS in Zone hinzufügen
  4. Registrar aktualisieren: Delegierung beim Registrar ändern
  5. Überprüfen: Von mehreren Netzwerken testen
  6. Abschließen: Alte NS entfernen, TTL erhöhen

Ergänzende Tools

ToolZweck
A-Record-AbfrageNS-Server-IPs prüfen
SOA-Record-AbfrageZonen-Metadaten prüfen
DNS-PropagierungsprüfungWeltweite Propagierung prüfen

Nützliche Ressourcen