Propagation & Diagnose

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

TXT-Eintrag Abfrage

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 TXT

Ein TXT-Record veröffentlicht einen Text, der mit einem Domainnamen verknüpft ist. Dienste nutzen ihn, um die Eigentumsrechte an der Domain zu beweisen, E-Mail-Einstellungen wie SPF DKIM DMARC zu konfigurieren oder technische Informationen preiszugeben.
Ein TXT-Record enthält einen Namen, einen Typ, einen Wert und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver im Cache bleibt.

Beispiel TXT DNS-Eintrag

NameTypWertTTL in Sekunden
@TXT"v=spf1 ip4:203.0.113.0/24 ~all"3600

In diesem Beispiel zielt der Name @ auf die Wurzel der Domain. Der Wert enthält eine SPF-Regel als Text. Eine TTL von 3600 entspricht einer Stunde.

Häufige Beispiele

NameTypWertTTL in Sekunden
selector1._domainkeyTXT"v=DKIM1; k=rsa; p=MII...AB"3600
_dmarcTXT"v=DMARC1; p=quarantine; adkim=s; aspf=s"3600
@TXT"eigenschaft=token12345"300

Diese Zeilen zeigen einen DKIM-Selektor, eine DMARC-Richtlinie und ein Verifizierungs-Token. Der anvisierte Name hängt vom verwendeten Dienst ab.

Mehrere TXT auf demselben Namen

Es ist möglich, mehrere TXT-Records auf derselben Bezeichnung zu veröffentlichen. Jeder Wert erscheint in der Antwort. Für SPF nur einen Eintrag pro Name behalten und die Mechanismen darin gruppieren. Für DKIM einen anderen Selektor für jeden Schlüssel verwenden.

TTL einfach erklärt

Eine kurze TTL macht eine Änderung schneller sichtbar. Nützlich während einer SPF-Aktualisierung oder einer Domain-Verifizierung.
Eine mittlere oder lange TTL reduziert die Anfragen an die autoritativen Server. Geeignet für eine stabile Konfiguration.
Die TTL einige Stunden vor der Änderung reduzieren und dann nach der Validierung wieder erhöhen.

Gut zu wissen
Ein TXT-Wert kann 255 Bytes überschreiten. Er wird dann in mehrere in Anführungszeichen gesetzte Zeichenketten in der Zone aufgeteilt. Die Resolver fügen diese Zeichenketten clientseitig zusammen.

Wo einen TXT-Record verwenden

Den TXT auf dem vom Dienst angeforderten Namen veröffentlichen. SPF wird oft am Apex platziert. DKIM wird auf selector._domainkey veröffentlicht. DMARC wird auf _dmarc platziert. Verifizierungsdienste geben einen spezifischen Namen vor. Ein TXT kann mit A AAAA MX auf demselben Namen koexistieren.

Zu vermeiden
Zwei SPF-Einträge auf demselben Namen haben. Zu einem einzigen Wert zusammenführen.
Anführungszeichen vergessen oder Sonderzeichen falsch escapen.
Ein DKIM am falschen Selektor veröffentlichen.

Online überprüfen

Eine Online-DNS-Lookup ermöglicht die Eingabe eines Domainnamens. Man erhält die Liste der TXT-Werte sowie die vom Internet aus sichtbare TTL. Das ist eine nützliche erste Kontrolle. Danach 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=txt
beispiel.com
Spezifischer Resolver
nslookup
set q=txt
server 1.1.1.1
beispiel.com

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

Unter Linux und Mac überprüfen

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

Lokaler Resolver
dig TXT www.beispiel.com
Spezifischer Resolver
dig TXT www.beispiel.com @1.1.1.1

Schnelles Lesen der Antworten

Mehrere Zeilen zeigen mehrere TXT-Werte an. Die Präfixe v=spf1 v=DKIM1 v=DMARC1 lesen, um die Funktion jedes Eintrags zu erkennen.
Eine hohe verbleibende TTL kann eine Verzögerung nach einer Änderung erklären.
Ein leerer oder abgeschnittener Wert signalisiert oft ein fehlendes Anführungszeichen oder einen schlecht verwalteten Schnitt.

Einfaches Migrationsverfahren

  1. Die aktuellen Werte und die TTL notieren.
  2. Die TTL einige Stunden vor der Änderung auf 300 oder sogar 60 Sekunden reduzieren.
  3. Den neuen Wert vorbereiten. Für SPF die Mechanismen in eine einzige Zeile zusammenführen.
  4. Den neuen Wert veröffentlichen und dann den alten entfernen, falls notwendig.
  5. Mit nslookup oder dem dig-Befehl von mehreren Netzwerken aus überprüfen und die TTL erhöhen, wenn alles stabil ist.

Praktischer Tipp
Für DKIM einen neuen Schlüssel auf einem neuen Selektor veröffentlichen. Den alten während der Übergangszeit belassen. Dann den alten Schlüssel entfernen, wenn alles validiert ist.

Häufige Fälle

SPF für den korrekten E-Mail-Empfang

Eine SPF-Regel am Apex mit den autorisierten Adressen und Domains veröffentlichen. Vor der Produktionseinführung testen.

DKIM zum Signieren von Nachrichten

Den öffentlichen Schlüssel am vom E-Mail-Dienst bereitgestellten Selektor veröffentlichen. Überprüfen, dass der Schlüssel vollständig ist.

DMARC für die Domain-Richtlinie

Eine Richtlinie auf _dmarc mit der p-Direktive und nützlichen Optionen veröffentlichen. Die Berichte überwachen, falls aktiviert.

Eigentumsverifizierung

Ein temporäres TXT-Token veröffentlichen, das von einem Dienst bereitgestellt wird. Es nach der Validierung entfernen, falls der Dienst dies erlaubt.

Schnelle Fehlerbehebung

  1. Wenn SPF als ungültig gemeldet wird, überprüfen, dass nur ein SPF-Eintrag auf demselben Namen existiert.
  2. Wenn DKIM fehlschlägt, den Selektor und den Schlüssel überprüfen. Nach einem Bruch oder einem überschüssigen Leerzeichen suchen.
  3. Wenn DMARC nicht erkannt wird, den _dmarc-Namen und den Wert v=DMARC1 überprüfen.
  4. Wenn die Antwort alt bleibt, das Ablaufen der TTL abwarten und den Cache des lokalen Resolvers leeren, falls möglich.

Zusammenfassend veröffentlicht ein TXT-Eintrag Textinformationen für einen Domainnamen. Er dient Verifizierungen, E-Mail-Richtlinien und anderen technischen Verwendungszwecken. Die TTL regelt die Cache-Dauer. Mehrere TXT können auf demselben Namen koexistieren, aber nur ein SPF-Eintrag sollte existieren. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Orientierungspunkten bleibt die Verwaltung klar. Änderungen verlaufen stressfrei. Die Dienste funktionieren wie erwartet.