Zum Hauptinhalt springen

SOA-Record-Abfrage (Start of Authority)

Analysieren Sie die Metadaten und Synchronisierungseinstellungen Ihrer DNS-Zone

Probleme mit der DNS-Synchronisierung? Überprüfen Sie den SOA-Record, um Ihre Zoneneinstellungen zu verstehen und Replikationsprobleme zu diagnostizieren.

Eintragstypjeder Typ ist eine eigene Seite

Das Ergebnis wird weiter unten automatisch angezeigt

Auflösungsmodus
DNS-Propagation testen

Einfach = eine Abfrage an den Resolver · Trace = Abstieg von der Root

OptionenErweiterte Optionen

Wichtige Funktionen

Zonen-Metadaten

Sehen Sie den primären Server, den administrativen Kontakt und die Seriennummer, die Ihre Zonenversion identifiziert.

Multi-Resolver

Vergleichen Sie Antworten von Google, Cloudflare und Quad9, um Serial-Propagationsprobleme zu erkennen.

Sync-Parameter

Analysieren Sie Refresh-, Retry- und Expire-Werte, die die Synchronisierung zwischen primären und sekundären Servern steuern.

TTL und negativer Cache

Überprüfen Sie den Minimum-TTL, der definiert, wie lange negative Antworten (NXDOMAIN) gecacht werden.

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 der TLD (.com, .de, .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, eine zu lange 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 einer 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. Resolver weltweit

    Fragt zahlreiche öffentliche Resolver in mehreren Regionen gleichzeitig ab.

  2. 2. Automatischer Vergleich

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

  3. 3. Verwertbare Zusammenfassung

    Liefert eine klare Übersicht mit der Resolverliste, deren Latenzen und dem 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: Der Propagationstest ist ein eigenständiges Tool. Nutzen Sie den DNS-Lookup für eine gezielte Einzelabfrage und den Propagationstest, um mehrere Resolver weltweit zu vergleichen.

Was ist ein SOA-Record?

Ein SOA-Record (Start of Authority) definiert die Autorität einer DNS-Zone. Er enthält wesentliche Zoneninformationen: primärer Server, administrativer Kontakt, Seriennummer und Synchronisierungsparameter.

SOA-Record-Struktur:

FeldBeschreibungBeispiel
MNAMEPrimärer DNS-Serverns1.provider.com.
RNAMEAdministrativer Kontakt (E-Mail)hostmaster.captaindns.com.
SerialZonen-Versionsnummer2025012801
RefreshPrüfintervall (Sek)7200
RetryVerzögerung nach Fehler (Sek)900
ExpireZonenaufgabe (Sek)1209600
MinimumNegativer Cache (Sek)3600

SOA-Record-Beispiel

captaindns.com.  3600  IN  SOA  ns1.provider.com. hostmaster.captaindns.com. (
    2025012801  ; Serial
    7200        ; Refresh (2 Stunden)
    900         ; Retry (15 Minuten)
    1209600     ; Expire (14 Tage)
    3600        ; Minimum TTL (1 Stunde)
)

RNAME-Kontakt-Erklärung

Der Kontakt wird als DNS-Name geschrieben: hostmaster.captaindns.com. entspricht der E-Mail hostmaster@captaindns.com. Der erste Punkt ersetzt das @-Symbol.


Empfohlene Werte

ParameterEmpfohlener WertErklärung
Refresh3600-7200Prüfung alle 1-2 Stunden
Retry600-900Wiederholung nach 10-15 Minuten
Expire604800-1209600Aufgabe nach 1-2 Wochen
Minimum300-3600Negativer Cache 5 Min bis 1 Stunde

Serial-Format

Das JJJJMMTTNN-Format wird empfohlen:

  • 2025012801 = 28. Januar 2025, Änderung Nr. 1
  • 2025012802 = 28. Januar 2025, Änderung Nr. 2

Wichtige Regeln

SOA-Eindeutigkeit

RegelErklärung
Nur ein SOAImmer am Zonen-Apex
Mit NS-RecordsSOA und NS koexistieren am Apex
Kein CNAMEApex kann kein CNAME sein

Best Practices

PraxisWarum
Serial inkrementierenBei jeder Änderung erforderlich
Gültiger KontaktUm Benachrichtigungen zu erhalten
Ausreichendes ExpireVerhindert Zonenverlust bei Sekundären

Häufige Probleme

Serial nicht inkrementiert

Sekundäre aktualisieren nicht, weil das Serial unverändert ist.

  1. Inkrementieren Sie das Serial in der Zone
  2. Laden Sie die Zone auf dem Primären neu
  3. Überprüfen Sie die Propagation

Synchronisierung fehlgeschlagen

Ein sekundärer Server zeigt ein altes Serial.

  1. Überprüfen Sie den Netzwerkzugang zwischen Primär und Sekundär
  2. Kontrollieren Sie die Zonentransfer-Berechtigungen
  3. Warten Sie auf einen Refresh-Zyklus

Zone von Sekundär aufgegeben

Der Sekundäre hat das Ablaufzeitlimit überschritten.

  1. Überprüfen Sie, ob der Primäre erreichbar ist
  2. Erhöhen Sie den Expire-Wert bei Bedarf
  3. Erzwingen Sie einen Zonentransfer

Befehlszeilenüberprüfung

Linux/Mac

dig SOA captaindns.com

Serials auf verschiedenen Servern vergleichen:

dig SOA captaindns.com @ns1.provider.com +short
dig SOA captaindns.com @ns2.provider.com +short

Windows

nslookup -type=soa captaindns.com

Ergänzende Tools

ToolZweck
NS-Record-AbfrageAutoritative Server prüfen
A-Record-AbfragePrimärserver-IP prüfen
DNS-PropagationsprüfungWeltweite Propagation prüfen

Nützliche Ressourcen