Reverse DNS Lookup

Was ist Reverse DNS?

Reverse DNS (rDNS) ist die umgekehrte Richtung von normalem DNS. Während Forward DNS einen Namen (kernelhost.com) auf eine IP-Adresse abbildet, bildet Reverse DNS die IP zurück auf einen Namen ab. Der zugehörige Record-Typ ist PTR (Pointer). Reverse-Namen leben in zwei eigenen Namensräumen: in-addr.arpa für IPv4 und ip6.arpa für IPv6, jeweils konstruiert aus der IP in umgekehrter Oktett- oder Nibble-Reihenfolge.

Beispiel: Aus der IP 8.8.8.8 wird 8.8.8.8.in-addr.arpa. Eine PTR-Abfrage gegen diesen Namen liefert den Hostnamen zurück (in diesem Fall dns.google). Bei IPv6 wird aus der Adresse 2001:db8::1 der Name 1.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, jedes Hex-Nibble der Adresse einzeln und umgekehrt dargestellt.

Wer kontrolliert einen PTR Record? Der Eigentümer des IP-Bereichs, also normalerweise der Upstream-Provider, das Hosting-Unternehmen oder der ISP. Domain-Inhaber können PTR Records nicht selbst setzen, außer der IP-Bereich wird ihnen delegiert (selten, möglich ab /24 Blöcken oder größer). Bei einem einzelnen VPS wird der PTR im Hosting-Control-Panel oder per Support-Ticket gesetzt.

FCrDNS: forward-confirmed Reverse DNS

FCrDNS ist der wichtigste Grund, sich überhaupt um PTR Records zu kümmern. Die Idee ist simpel: Der PTR Record liefert dir einen Hostnamen, diesen Hostnamen löst du dann vorwärts via A oder AAAA auf, und die zurückgegebene IP muss zur ursprünglichen IP passen. Stimmt sie überein, gilt der PTR als vertrauenswürdig. Wenn nicht, gilt der PTR als gefälscht und wird von den meisten modernen Prüfungen ignoriert.

Mailserver (Postfix, Exim, OpenSMTPD) und Spamfilter (SpamAssassin, rspamd, Postscreen) verifizieren FCrDNS bei jeder eingehenden Verbindung. Ein FCrDNS-Fail addiert typischerweise 1.0 bis 3.5 Punkte zum Spam-Score (oft genug für den Junk-Ordner) und viele große Provider (Google, Microsoft, Yahoo) lehnen die Verbindung direkt mit einem 550er-Fehler ab. Ohne gültiges FCrDNS existiert dein Mailserver praktisch nicht.

FCrDNS-Verifizierung durch dieses Tool: Wir lesen den PTR Record, lösen dann jeden zurückgegebenen Hostnamen vorwärts via A (IPv4) oder AAAA (IPv6) auf und vergleichen die zurückgegebenen IPs mit der ursprünglichen IP. Das Badge sagt dir sofort Bescheid: grün bei verifiziert, gelb wenn gar kein Forward-Eintrag existiert, rot bei Mismatch mit der Liste, wohin der PTR tatsächlich zeigt.

Typische Anwendungsfälle

Wofür du dieses Tool im täglichen Betrieb wirklich brauchst:

• Mailserver in Betrieb nehmen: Bevor du die erste Mail von einer neuen IP verschickst, muss der PTR gesetzt und FCrDNS grün sein. Sonst werden Gmail, Outlook und andere jede Mail ablehnen oder in den Junk-Ordner schieben. Hier prüfen, im Provider-Control-Panel fixen, erneut prüfen.
• Spam-Analyse: Wenn du Spam bekommst, schau den PTR der Quell-IP nach. Ein fehlender oder kaputter PTR ist ein starkes Spam-Signal. Ein PTR, der auf einen generischen ISP-Pool-Namen zeigt (dsl-broadband-pool-... usw.), ist ein weiterer klassischer Indikator.
• Log-Analyse und Forensik: Eine IP taucht in deinen Logs auf. Wer ist das? rDNS liefert dir den Hostnamen (oft etwas wie ec2-..., crawler-..., cdn-...) und zusammen mit der ASN bekommst du Cloud-Provider, Land und Organisation. In Sekunden entscheidest du, ob es ein legitimer Bot, ein bekannter Cloud-Kunde oder etwas zum Blocken ist.
• Netzwerk-Operations: Beim Debuggen einer Traceroute werden Zwischen-Hops per PTR angezeigt. Router entlang der Strecke haben üblicherweise sprechende PTRs (frankfurt-edge1.isp.net, lhr-core2.example.com usw.), die dir den geografischen und topologischen Weg deines Pakets verraten.
• Abuse-Meldungen: Du willst einen Abuse-Report einreichen? PTR plus ASN sagen dir, welcher Provider zu kontaktieren ist (abuse@<org>). Ohne rDNS müsstest du die IP in RIPE/ARIN Whois-Datenbanken nachschlagen, was deutlich langsamer ist.

So setzt du einen PTR Record

PTR Records werden nicht auf deinem autoritativen Nameserver für die Forward-Zone gesetzt. Sie liegen auf der Reverse-Zone, die vom IP-Eigentümer (ARIN, RIPE, APNIC, LACNIC, AfriNIC) bis zu dem Unternehmen delegiert wird, das den IP-Block hält. Bei einem einzelnen VPS oder Dedicated Server heißt das: den Hosting-Provider bitten, den PTR zu setzen, nicht im eigenen DNS-Panel versuchen.

Die meisten Hosting-Provider bieten Self-Service-PTR-Verwaltung im Kundenportal. Bei KernelHost VPS und Dedicated Servern steht das rDNS-Feld direkt im Server-Management-Panel zur Verfügung und PTR-Änderungen sind innerhalb von 5 bis 10 Minuten live. Für colocated IPs ist der Standardweg ein Support-Ticket mit dem gewünschten Hostnamen pro IP.

Best Practice für Mail: PTR und HELO müssen übereinstimmen. Wenn dein Mailserver sich als mail.example.com meldet (HELO mail.example.com), dann muss der PTR der IP mail.example.com sein, und mail.example.com muss per A-Record wieder auf dieselbe IP zeigen. Alle drei in einer Linie = FCrDNS grün = saubere Reputation.

rDNS bei KernelHost

Jeder KernelHost VPS, Dedicated Server, Mail- und Minecraft-Server kommt mit Self-Service-PTR-Verwaltung für IPv4 und IPv6. Du setzt den Hostnamen pro IP im Control Panel und die Änderung ist innerhalb von Minuten aktiv, ohne Support-Ticket. Für IP-Blöcke (/29 oder größer) lässt sich die komplette Reverse-Zone an deine eigenen Nameserver delegieren.

Unsere DNS-Plane läuft als DNSSEC-signiertes Anycast in Frankfurt und Wien, sodass PTR-Lookups von überall auf der Welt in zweistelligen Millisekunden auflösen. Wenn du gerade dabei bist, einen Mailserver auf einer neuen IP in Betrieb zu nehmen, und vom ersten Tag an die sauberste mögliche Reputation willst, spart dir die Kombination aus KernelHost rDNS plus DKIM/SPF/DMARC im selben Panel den üblichen Debugging-Zyklus am ersten Tag.

Häufige Fragen