Zum Hauptinhalt springen

PTR-Record-Abfrage (Reverse DNS)

Führen Sie eine Reverse-DNS-Auflösung für Ihre IP-Adresse durch

Probleme mit der E-Mail-Zustellbarkeit? Überprüfen Sie, ob Ihre IP-Adresse einen gültigen PTR-Record hat, der mit Ihrer DNS-Konfiguration konsistent ist.

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

Reverse-Auflösung

Entdecken Sie, welcher Hostname mit einer IP-Adresse verbunden ist. Unverzichtbar für E-Mail und Netzwerk-Logging.

Multi-Resolver

Vergleichen Sie Antworten von Google, Cloudflare und Quad9, um Propagierungsprobleme zu erkennen.

Forward-Reverse-Konsistenz

Überprüfen Sie, ob der vom PTR zurückgegebene Name über A/AAAA-Record zur ursprünglichen IP-Adresse auflöst.

IPv4 und IPv6

Volle Unterstützung für in-addr.arpa (IPv4) und ip6.arpa (IPv6) Zonen für alle Ihre Adressen.

Kostenlos und unbegrenzt

Testen Sie so viele Adressen 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 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.

Was ist ein PTR-Record?

Ein PTR-Record (Pointer) führt die Reverse-DNS-Auflösung durch: Er ordnet eine IP-Adresse einem Hostnamen zu. Dies ist die umgekehrte Operation von A- (IPv4) und AAAA-Records (IPv6).

PTR-Record-Struktur:

FeldBeschreibungBeispiel
NameUmgekehrte Adresse + arpa-Zone10.113.0.203.in-addr.arpa.
TypImmer PTRPTR
ZielZugehöriger Hostnamemail.captaindns.com.
TTLCache-Dauer in Sekunden3600

PTR-Record-Beispiele

IPv4 (in-addr.arpa)

Adresse 203.0.113.10 umgekehrt geschrieben:

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.captaindns.com.

IPv6 (ip6.arpa)

Adresse 2001:db8::10 mit jedem Hex-Nibble umgekehrt:

0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  3600  IN  PTR  host.captaindns.com.

Forward-confirmed Reverse DNS (FCrDNS)

Forward-Reverse-Konsistenz ist wesentlich:

  1. PTR: IP 203.0.113.10 gibt mail.captaindns.com zurück
  2. A: Name mail.captaindns.com löst zu 203.0.113.10 auf

Diese Konsistenz wird verlangt von:

  • E-Mail-Servern (Anti-Spam)
  • Sicherheitsdiensten
  • Logging-Systemen

Wichtige Regeln

Korrekte Konfiguration

RegelErklärung
Ein PTR pro IPVermeiden Sie mehrere PTRs für dieselbe Adresse
FCrDNS-KonsistenzName muss zur ursprünglichen IP auflösen
Aussagekräftiger NameVerwenden Sie einen Namen, der den Dienst identifiziert

E-Mail-Best-Practices

PraxisWarum
PTR erforderlichViele Server lehnen ohne PTR ab
HELO entsprechenName sollte mit SMTP-HELO übereinstimmen
Keine generischen NamenVermeiden Sie Namen wie host-203-0-113-10.isp.com

Häufige Probleme

Fehlender PTR (NXDOMAIN)

Kein PTR-Record existiert für die Adresse.

  1. Kontaktieren Sie Ihren IP-Adressanbieter
  2. Fordern Sie PTR-Erstellung mit gewünschtem Namen an
  3. Überprüfen Sie nach Propagierung

FCrDNS-Inkonsistenz

Zurückgegebener Name löst nicht zur ursprünglichen IP auf.

  1. Überprüfen Sie den A/AAAA-Record für den Namen
  2. Korrigieren Sie, wenn IP nicht übereinstimmt
  3. Warten Sie auf Propagierung

E-Mails wegen PTR abgelehnt

Zielserver lehnen Ihre E-Mails ab.

  1. Überprüfen Sie, ob PTR existiert
  2. Stellen Sie FCrDNS-Konsistenz sicher
  3. SMTP-HELO-Name abstimmen

Befehlszeilenüberprüfung

Linux/Mac

Einfache Reverse-Abfrage:

dig -x 203.0.113.10

Oder mit vollständiger Notation:

dig PTR 10.113.0.203.in-addr.arpa

Windows

nslookup 203.0.113.10

PTR-Verwaltung

Wer verwaltet die Reverse-Zone?

SituationVerwalter
Dedizierter ServerDer Host (über deren Interface oder Support)
Cloud (AWS, GCP, Azure)Der Cloud-Anbieter (über deren Konsole)
Eigener IP-BlockSie (wenn Sie die Delegierung haben)
Residential-IPDer ISP (selten änderbar)

Ergänzende Tools

ToolZweck
A-Record-AbfrageForward-IPv4-Auflösung prüfen
AAAA-Record-AbfrageForward-IPv6-Auflösung prüfen
E-Mail-TestVollständige E-Mail-Konfiguration prüfen

Nützliche Ressourcen