Propagation & Diagnose

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

MX-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 MX

Ein MX-Eintrag gibt an, welche Server E-Mails für eine Domain empfangen. Er zeigt auf einen Hostnamen. Der Resolver folgt diesem Namen, um A- oder AAAA-Einträge zu finden. Der sendende Server kann dann die Nachrichten zustellen.
Ein MX-Eintrag enthält einen Namen, einen Typ, eine Priorität, ein Ziel und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver zwischengespeichert bleibt.

Beispiel DNS-Eintrag vom Typ MX

NameTypPrioritätZielTTL in Sekunden
@MX10mail.beispiel.net.3600

In diesem Beispiel zielt der Name @ auf die Domain-Wurzel. Das Ziel ist ein Hostname, der A oder AAAA veröffentlichen muss. Eine niedrigere Priorität wird bevorzugt. Eine TTL von 3600 entspricht einer Stunde.

Beispiel mit mehreren Prioritäten

Das Veröffentlichen mehrerer MX-Einträge für denselben Namen ist üblich. Der sendende Server wählt zuerst die niedrigste Priorität. Im Fehlerfall versucht er die nächste.

NameTypPrioritätZielTTL in Sekunden
@MX10mx1.beispiel.net.3600
@MX20mx2.beispiel.net.3600

Diese Redundanz erhöht die Dienstkontinuität. Sie ersetzt keine aktive Überwachung oder regelmäßige Tests.

Wesentliche Regeln

Ein MX-Eintrag zeigt auf einen Namen, nicht auf eine Adresse. Das Ziel darf kein CNAME sein. Der angezielte Name muss A oder AAAA veröffentlichen und über Port 25 erreichbar sein. Der MX kann am Apex oder auf einer Subdomain existieren, wenn die E-Mail-Adresse diese Subdomain verwendet.

TTL klar erklärt

Eine kurze TTL macht eine Änderung schneller sichtbar. Nützlich beim Wechsel zu einem neuen Messaging-Dienst.
Eine mittlere oder lange TTL reduziert Anfragen an autoritative Server. Geeignet für einen stabilen Dienst.
Die TTL einige Stunden vor der Umstellung reduzieren, dann wieder erhöhen, wenn alles validiert ist.

Gut zu wissen
MX-Einträge dienen dem Empfang. Ausgehende E-Mails verwenden andere Einstellungen wie SPF, DKIM, DMARC und die Konfiguration des ausgehenden Relays.

Wo ein MX-Eintrag verwendet wird

Veröffentlichen Sie den MX auf der Domain, die E-Mails empfängt. Meist ist das die Wurzel. Für eine dedizierte Domain wie support.beispiel.com veröffentlichen Sie den MX auf dieser Subdomain. Die von MX-Einträgen referenzierten Messaging-Hosts behalten ihre eigenen A oder AAAA.

Zu vermeiden
Einen MX auf einen CNAME oder eine direkte Adresse zu richten.
Den A- oder AAAA-Eintrag des Ziels zu vergessen.
Einen alten MX nach einer Migration aktiv zu lassen.

Online überprüfen

Eine Online-DNS-Suche ermöglicht die Eingabe eines Domainnamens. Man erhält die Liste der MX mit ihren Prioritäten, ihren Zielen und der vom Internet aus sichtbaren TTL. Das ist eine nützliche erste Kontrolle. Dann einen lokalen Test von Ihrem Rechner aus durchführen.

Unter Windows überprüfen

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

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

Der erste Teil fragt entsprechend der Netzwerkkonfiguration des Rechners ab. Der zweite erzwingt die Verwendung eines Drittanbieter-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 MX beispiel.com
Spezifischer Resolver
dig MX beispiel.com @1.1.1.1

Schnelles Lesen der Antworten

Mehrere Zeilen zeigen mehrere Server an. Die kleinste Prioritätszahl wird bevorzugt. Identische Prioritäten teilen sich die Versuche in ausgewogener Weise.
Eine hohe verbleibende TTL kann eine Verzögerung nach einer Änderung erklären.
Ein Ziel ohne A oder AAAA verhindert die Zustellung.

Einfache Migrationsverfahren

  1. Messaging-Hosts mit ihren A oder AAAA vorbereiten.
  2. Die TTL der MX auf 300 oder sogar 60 Sekunden einige Stunden vor der Umstellung reduzieren.
  3. Die neuen MX mit der geplanten Priorität hinzufügen. Die alten während der Übergangszeit behalten.
  4. Den Empfang von mehreren Netzwerken aus testen. Die Header der empfangenen Nachrichten überprüfen.
  5. Die alten MX entfernen, dann die TTL erhöhen, wenn alles stabil ist.

Praktischer Tipp
Die vollständige Liste der MX vor der Änderung notieren. Datum, Prioritäten, TTL und Grund für die Änderung aufbewahren. Diese Spur vermeidet Fehler und erleichtert einen Rollback.

Häufige Fälle

Externer Messaging-Dienst

Die vom Anbieter bereitgestellten MX veröffentlichen. Die Ziele gehören zur Domain des Anbieters. Eine vernünftige TTL beibehalten.

Vorgeschaltete Anti-Spam-Filterung

Die MX auf den Filteranbieter richten. Dieser Anbieter leitet dann an Ihre Server weiter. Latenz und Verfügbarkeit überwachen.

Backup-MX

Einen sekundären Server mit höherer Priorität deklarieren. Er hält Nachrichten zurück, wenn der primäre Server nicht verfügbar ist, und stellt sie dann zu, wenn er zurückkehrt.

Schnelle Fehlerbehebung

  1. Bei einem Bounce überprüfen, dass das MX-Ziel zu A oder AAAA auflöst.
  2. Die Netzwerkerreichbarkeit über Port 25 zum Ziel überprüfen.
  3. Wenn MX noch auf den alten Anbieter zeigen, sie nach der Umstellung entfernen.
  4. Wenn die Antwort alt bleibt, auf TTL-Ablauf warten und den lokalen Resolver-Cache wenn möglich löschen.

Zusammenfassend zeigt ein MX-Eintrag den empfangenden Server für eine Domain an. Er zeigt auf einen Hostnamen, der A oder AAAA veröffentlicht. Die niedrigste Priorität wird zuerst gewählt. Eine gut gewählte TTL erleichtert Änderungen. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Orientierungspunkten bleibt die Verwaltung klar. Änderungen verlaufen stressfrei. Nachrichten kommen ohne Zwischenfälle an.