Propagation & Diagnose

Vergleichen Sie öffentliche Resolver und analysieren Sie die gelieferten Antworten.

NS-Eintrag Suche

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

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.

Zusätzliche Informationen zu DNS-Einträgen vom Typ NS

Ein NS-Record gibt an, welche Server für eine DNS-Zone autoritativ sind. Er listet die Namen der Server auf, die die Zone verwalten. Resolver fragen diese Server ab, um andere Einträge zu erhalten.
Ein NS-Record enthält einen Namen, einen Typ, ein NS-Ziel und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver zwischengespeichert bleibt.

Beispiel für DNS-Eintrag vom Typ NS

NameTypNS-ServerTTL in Sekunden
@NSns1.beispiel.net.3600

In diesem Beispiel zielt der Name @ auf den Apex der Zone ab. Das Ziel ist ein Hostname. Dieser Name muss A- oder AAAA-Einträge veröffentlichen und erreichbar sein.

Beispiel mit mehreren Servern

Eine Zone muss mehrere NS-Records veröffentlichen. Dies bietet Redundanz und bessere Verfügbarkeit.

NameTypNS-ServerTTL in Sekunden
@NSns1.beispiel.net.3600
@NSns2.beispiel.net.3600

Zwei oder mehr Server vorsehen. Sie müssen kohärent antworten.

Delegierung einer Subdomain

Um sub.beispiel.com zu delegieren, NS-Einträge für diesen Namen in der übergeordneten Zone hinzufügen. Jedes Ziel muss sich zu A oder AAAA auflösen. Wenn der Servername innerhalb der Subdomain liegt, kann die übergeordnete Zone unterstützende Adressen veröffentlichen, die man Glue Records nennt. Das Ziel bleibt einfach. Resolvern ermöglichen, die Server der Subdomain schnell zu erreichen.

TTL einfach erklärt

Eine kurze TTL macht einen Serverwechsel sichtbarer. Nützlich in der Umstellungsphase.
Eine mittlere oder lange TTL reduziert die Anfragen an die autoritativen Server. Geeignet für eine stabile Zone.
TTL einige Stunden vor einer Änderung reduzieren, dann nach Validierung wieder erhöhen.

Gut zu wissen
NS und SOA werden am Apex einer Zone veröffentlicht. Ein CNAME darf nicht auf einem Namen erscheinen, der NS trägt. Ein NS-Ziel ist immer ein Name, keine Adresse.

Wo ein NS-Record verwendet wird

Am Apex der Zone zur Bezeichnung der autoritativen Server dieser Zone.
Auf einer Subdomain, wenn man diese Subdomain an dedizierte Server delegiert.
Tochterzonen besitzen ihren eigenen SOA und ihre eigenen NS.

Zu vermeiden
Einen NS-Eintrag auf eine direkte Adresse zeigen zu lassen.
Nur einen NS auf einer Zone zu veröffentlichen.
Ein NS-Ziel ohne A oder AAAA zu lassen.
Unterschiedliche NS-Sätze zwischen übergeordneter Zone und Tochterzone ohne Grund zu haben.

Online überprüfen

Ein Online-DNS-Lookup ermöglicht die Eingabe eines Domainnamens. Das Ergebnis zeigt die Liste der NS-Server und die vom Internet aus sichtbare TTL. Das ist eine nützliche erste Kontrolle. Anschließend einen lokalen Test von der eigenen Maschine durchführen.

Unter Windows überprüfen

Windows stellt nslookup zur Verfügung. Man kann es im interaktiven Modus verwenden.

Lokaler Resolver
nslookup
set q=ns
beispiel.com
Spezifischer Resolver
nslookup
set q=ns
server 1.1.1.1
beispiel.com

Der erste Teil fragt entsprechend der Netzwerkkonfiguration der Maschine ab. Der zweite erzwingt die Verwendung eines Drittanbieters-Resolvers, hier den von Cloudflare.

Unter Linux und Mac überprüfen

Auf diesen Systemen ist der Befehl dig praktisch und einfach zu verwenden.

Lokaler Resolver
dig NS beispiel.com
Spezifischer Resolver
dig NS beispiel.com @1.1.1.1

Schnelles Lesen der Antworten

Mehrere NS-Zeilen zeigen mehrere Server an. Nach verschiedenen Namen und unterschiedlichen Netzwerken für bessere Resilienz suchen.
Eine hohe verbleibende TTL kann eine Verzögerung nach einer Änderung erklären.
Eine Abweichung zwischen den NS, die von der übergeordneten Zone aus gesehen werden, und denen, die in der Zone selbst gesehen werden, zeigt mangelnde Synchronisation.

Einfaches Migrationsverfahren

  1. Die neuen Server und ihre A- oder AAAA-Einträge vorbereiten.
  2. Die TTL der NS einige Stunden vor der Umstellung auf 300 oder sogar 60 Sekunden reduzieren.
  3. Die Zone mit der neuen NS-Liste aktualisieren.
  4. Die Delegierung bei der Registrierungsstelle bei Bedarf aktualisieren.
  5. Von mehreren Netzwerken aus überprüfen, dann die TTL erhöhen, wenn alles stabil ist.

Praktischer Tipp
Eine Liste der NS führen, die sowohl zone- als auch registrarseitig veröffentlicht sind. Datum, TTL und Grund der Änderung notieren. Diese Spur vermeidet Abweichungen bei Aktualisierungen.

Häufige Fälle

Wechsel des DNS-Anbieters

Die neuen NS in der Zone veröffentlichen. Die Delegierung beim Registrar aktualisieren. Konsistenz überprüfen.

Delegierung einer Subdomain an ein Team

NS auf der Subdomain in der übergeordneten Zone hinzufügen. Das Team verwaltet anschließend seine Tochterzone mit eigenem SOA.

Hinzufügung eines zusätzlichen Servers

Einen weiteren NS hinzufügen. Überprüfen, dass er sich zu A oder AAAA auflöst und die aktuelle Zone bereitstellt.

Schnelle Fehlerbehebung

  1. Wenn die Zone manchmal mit alten Einträgen antwortet, die Konsistenz der veröffentlichten NS überprüfen.
  2. Wenn ein NS-Server nicht antwortet, seinen Eintrag vorübergehend entfernen, bis die Reparatur erfolgt ist.
  3. Wenn die Delegierung nicht funktioniert, das Vorhandensein von Glue-Adressen überprüfen, wenn sie erforderlich sind.
  4. Wenn die Antwort trotz Aktualisierung veraltet bleibt, das Ablaufen der TTL abwarten und wenn möglich den Cache des lokalen Resolvers leeren.

Zusammengefasst bezeichnet ein NS-Eintrag die autoritativen Server einer Zone. Er muss auf erreichbare und konsistente Namen zeigen. Eine Zone veröffentlicht mehrere NS für die Verfügbarkeit. Eine gut eingestellte TTL erleichtert Übergänge. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Anhaltspunkten bleibt die Verwaltung klar. Änderungen laufen stressfrei ab. Resolver finden die Zone ohne Zwischenfälle.