Reverse DNS (PTR)-Lookup: den Hostnamen hinter einer IP bestaetigen
Reverse DNS ist das Spiegelbild eines normalen DNS-Lookups. Ein normaler Forward-Lookup macht aus `mail.example.de` die IP `85.118.219.232`. Ein Reverse-Lookup geht in die andere Richtung: du gibst DNS die IP, und es liefert einen PTR-Record mit dem Hostnamen zurueck.
Das klingt akademisch, bis du einen Mailserver betreibst. Gmail, Outlook und Yahoo pruefen alle den PTR jeder IP, die ihnen SMTP-Traffic zustellen will. Kein PTR oder ein PTR, der nicht zum Forward-Record passt, heisst stille Ablehnung oder Einbahnstrasse in den Spam-Ordner.
Dieses Tool fragt den PTR ueber Nodes `dns/promises` (denselben Resolver, den `dig` nutzt, ohne DoH-Proxy dazwischen) ab und verifiziert dann FCrDNS, indem es A- und AAAA-Records des PTR-Ziels rueck-aufloest. Du bekommst einen gruenen Haken, wenn beide Richtungen passen, eine rote Flagge, wenn nicht, und einen Schritt-fuer-Schritt-Fix, wenn etwas kaputt ist.
So benutzt du es
- IP eingeben: plain IPv4 (`8.8.8.8`) oder IPv6 (`2606:4700:4700::1111`). Kein Port, kein CIDR-Prefix.
- Check klicken. Das Ergebnis kommt meist unter einer Sekunde, manchmal 2 bis 3 Sekunden bei IPv6-Adressen mit langsamen Upstream-Resolvern.
- Den PTR-Record oben lesen: das ist der Hostname, fuer den die IP sich ausgibt (z. B. `dns.google` fuer `8.8.8.8`).
- Darunter die Forward A- und AAAA-Records dieses Hostnamens. Das ist der Round-Trip-Check.
- FCrDNS-Badge: gruenes Pass heisst, der Round-Trip stimmt, rotes Fail heisst, PTR existiert, aber die Forward-Records zeigen nicht auf deine IP zurueck.
- Wenn FCrDNS scheitert, lies die vorgeschlagene Aktion: sie sagt dir genau, was du beim Hosting-Provider beantragen musst.
- Gar kein PTR? Bei Heim-ISPs und kleinen VPS-Plans normal. Die Aktionsbox erklaert, wie du einen anforderst.
Wann das nuetzlich ist
Sieben typische Situationen, in denen ein Reverse-DNS-Check deinen Verstand rettet:
- Setup eines neuen Mailservers, bevor du DNS produktiv schaltest. PTR vor der ersten Mail bestaetigen, sonst routet Gmail ab Tag eins alles in Spam.
- Deliverability debuggen: Kunden beschweren sich, deine Mails kommen nicht an. Du pruefst die IP, die dein MTA fuer Outbound-SMTP nutzt, du entdeckst, dass der PTR auf den generischen Hosting-Hostnamen (`ec2-54-203-xxx.compute.amazonaws.com`) zeigt statt auf `mail.deine-domain.de`. Ein Ticket reicht.
- Auditen eines Drittanbieter-SMTP-Relays: du zahlst SendGrid / Mailgun / Postmark fuers Senden. Du pruefst stichprobenartig die sendende IP. PTR passt zu ihrer oeffentlichen Mail-Domain, alles gut.
- Eine Abuse-Beschwerde untersuchen: eine Logzeile sagt "Missbrauch von 185.220.101.7". Du PTRst sie. Der Hostname sagt TOR exit node in Klartext, du weisst also, womit du es zu tun hast.
- Verifizieren des Hosts eines SSL-Zertifikats: manche selbstsignierten Zertifikate codieren nur die Server-IP. PTR bestaetigt, welcher Hostname der kanonische Eigentuemer ist.
- Netzwerk-Forensik auf eingehendem Traffic: ein Request trifft deinen Server von einer unbekannten IP. PTR zeigt `crawl-66-249-66-1.googlebot.com`. Jetzt weisst du, dass es echter Googlebot ist und nicht jemand, der den User-Agent spooft.
- Residential vs Datacenter bestaetigen: ein TLS-Handshake von einem "Browser" kommt von einer IP mit PTR `example.linode.com`. Das ist kein Browser, das ist ein Skript auf einem VPS.
Verwandt: DNS-Lookup, Wie ist meine IP, IP-Info / ASN-Lookup, E-Mail-DNS-Pruefer.