Propagation & Diagnose

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

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

Ein PTR-Record verknüpft eine IP-Adresse mit einem Hostnamen. Man spricht von Rückwärtsauflösung. Systeme verwenden ihn für Protokolle, Netzwerkkontrollen und E-Mail. Um zu einer Adresse zu gelangen, stützt man sich auf A oder AAAA. Um zu einem Namen zurückzukehren, stützt man sich auf PTR.
Ein PTR-Record enthält einen Namen, einen Typ, ein Ziel und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver zwischengespeichert bleibt.

Beispiel für DNS-Eintrag vom Typ PTR für IPv4

NameTypZielTTL in Sekunden
10.113.0.203.in-addr.arpa.PTRmail.beispiel.net.3600

In diesem Beispiel entspricht der Name der Adresse 203.0.113.10, die umgekehrt in der Zone in-addr.arpa geschrieben ist. Das Ziel ist der erwartete Hostname. Eine TTL von 3600 entspricht einer Stunde.

Beispiel für DNS-Eintrag vom Typ PTR für IPv6

NameTypZielTTL in Sekunden
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.PTRhost.beispiel.net.3600

Hier nimmt der Name jede Hexadezimalziffer von 2001:db8::10 umgekehrt in der Zone ip6.arpa auf. Das Ziel ist der erwartete Hostname.

Konsistenz hin und zurück

Eine gute Einstellung lässt PTR und A oder AAAA übereinstimmen. Der von PTR zurückgegebene Name muss sich selbst zur ursprünglichen Adresse auflösen. Diese Konsistenz hilft bei E-Mail und Diagnose.

TTL einfach erklärt

Eine kurze TTL macht eine Änderung schneller sichtbar. Praktisch bei einer Adressumstellung.
Eine mittlere oder lange TTL reduziert die Anfragen an die autoritativen Server. Nützlich für eine stabile Konfiguration.
TTL einige Stunden vor einer Änderung reduzieren, dann nach Validierung wieder erhöhen.

Gut zu wissen
Eine Adresse kann einen einzigen nützlichen PTR veröffentlichen. Mehrere PTR für dieselbe Adresse schaffen Mehrdeutigkeit. Besser ist ein klarer Name, der sich dann zu A oder AAAA auflöst.

Wo ein PTR-Record verwendet wird

In der Reverse-Zone, die vom Adressinhaber bereitgestellt wird. Für IPv4 geschieht dies unter in-addr.arpa. Für IPv6 geschieht dies unter ip6.arpa. Bei Blöcken, die von einem Betreiber bereitgestellt werden, wird die PTR-Verwaltung oft in seinem Dashboard geregelt.

Zu vermeiden
Einen PTR auf einen Namen zeigen zu lassen, der keinen A- oder AAAA-Eintrag besitzt.
Ein altes Ziel nach einer Adressänderung zu belassen.
Einen generischen Namen zu veröffentlichen, der den tatsächlichen Dienst nicht widerspiegelt.

Online überprüfen

Ein Online-DNS-Lookup ermöglicht die Eingabe einer Adresse. Das Ergebnis zeigt den von PTR zurückgegebenen Namen 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=ptr
10.113.0.203.in-addr.arpa

Oder einfach

nslookup 203.0.113.10
Spezifischer Resolver
nslookup
set q=ptr
server 1.1.1.1
10.113.0.203.in-addr.arpa

Die erste Methode folgt der Netzwerkkonfiguration der Maschine. Die 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 PTR 10.113.0.203.in-addr.arpa
Spezifischer Resolver
dig PTR 10.113.0.203.in-addr.arpa @1.1.1.1

Für IPv6 fragt man die ip6.arpa-Form desselben Namens ab.

Schnelles Lesen der Antworten

Eine Antwort mit NXDOMAIN zeigt das Fehlen eines PTR an. Den Eintrag in der Reverse-Zone hinzufügen.
Ein zurückgegebener Name, der sich nicht zu A oder AAAA auflöst, signalisiert eine Inkonsistenz. Die Direktzone korrigieren.
Eine hohe TTL kann eine Verzögerung nach einer Änderung erklären.

Einfaches Einrichtungsverfahren

  1. Die Kontrolle über die Reverse-Zone beim Internetanbieter oder Cloud-Anbieter überprüfen.
  2. Einen klaren Hostnamen wählen, der sich zu A oder AAAA zur Adresse auflöst.
  3. Den PTR mit reduzierter TTL erstellen.
  4. Mit nslookup oder dem dig-Befehl von mehreren Netzwerken aus testen.
  5. Die TTL erhöhen, wenn alles stabil ist.

Praktischer Tipp
Für E-Mail den PTR-Eintrag, den vom SMTP-Server verwendeten Namen und den zugehörigen A- oder AAAA-Eintrag aufeinander abstimmen. Diese Konsistenz verbessert die Zustellbarkeit.

Häufige Fälle

E-Mail-Server

Einen PTR verlangen, der einen dedizierten Namen zurückgibt. Der Name muss sich zur Serveradresse auflösen.

Adressbereich bei einem Betreiber

Die Delegierung der Reverse-Zone beantragen oder die vorgesehene Schnittstelle zur PTR-Verwaltung verwenden.

Vergängliche Maschinen in der Cloud

Die Erstellung und Löschung des PTR beim Eintreffen und Verlassen von Instanzen automatisieren.

Schnelle Fehlerbehebung

  1. Wenn ein Dienst die Verbindung verweigert, das Vorhandensein eines PTR und die Konsistenz mit A oder AAAA überprüfen.
  2. Wenn die Antwort veraltet bleibt, das Ablaufen der TTL abwarten und wenn möglich den Cache des lokalen Resolvers leeren.
  3. Wenn der Anbieter die Reverse-Zone verwaltet, ein Ticket öffnen und die Adresse sowie den gewünschten Namen angeben.

Zusammengefasst liefert ein PTR-Eintrag den zu einer Adresse gehörenden Namen. Er ergänzt die A- und AAAA-Einträge. Eine angepasste TTL und Konsistenz hin und zurück vereinfachen die Kontrollen. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Anhaltspunkten bleibt die Verwaltung klar. Änderungen laufen stressfrei ab. Dienste identifizieren sich korrekt bei der Rückwärtsauflösung.