Was ist Reverse DNS? PTR-Records erklärt

Gewöhnliches DNS beantwortet die Frage „Welche Adresse gehört zu diesem Namen?“. Reverse DNS beantwortet die umgekehrte Frage: „Welcher Name gehört zu dieser Adresse?“. Der Record, der die Antwort enthält, ist der PTR-Record. Er ist eine Kleinigkeit, die an wenigen Stellen zählt (vor allem bei der E-Mail-Zustellung), und er verwirrt viele, weil er nicht in der Zone Ihrer Domain liegt und Sie ihn in der Regel nicht in Ihrer DNS-Verwaltung setzen können.

Wie Reverse DNS funktioniert

DNS kann nur Namen nachschlagen, also muss eine IP-Adresse zuerst in einen Namen verwandelt werden. Bei IPv4 werden die vier Oktette umgekehrt und .in-addr.arpa angehängt:

192.0.2.25   →   25.2.0.192.in-addr.arpa.

Durch die Umkehrung steht der bedeutendste Teil rechts, wie bei jedem Domainnamen, und das macht die Delegation möglich: Wer für 192.0.2.0/24 zuständig ist, betreibt die Zone 2.0.192.in-addr.arpa und kann darin für jede Adresse einen Record veröffentlichen:

25.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.example.com.

Bei IPv6 wird die Adresse vollständig ausgeschrieben, Hexadezimalziffer für Hexadezimalziffer (Nibble für Nibble) umgekehrt, unter ip6.arpa:

2001:db8::25   →
5.2.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.

Das tippen Sie nie von Hand; dig -x bildet den Namen für Sie:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short -x 2001:db8::25
mail.example.com.

host 192.0.2.25 und nslookup 192.0.2.25 tun dasselbe.

Wer den PTR-Record kontrolliert

Der Reverse-Baum folgt der Adresszuteilung, nicht dem Domainbesitz. Die regionalen Internet-Registries (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) delegieren Reverse-Zonen an die Organisationen, die Adressblöcke halten (Internetprovider, Hosting- und Cloud-Anbieter), und diese entscheiden, wie Kunden PTR-Records setzen dürfen.

Die Folgen:

Einen PTR-Record in die Zone von example.com einzutragen bewirkt nichts. Niemand wird ihn dort je abfragen.
VPS oder dedizierter Server: Die meisten Anbieter haben in ihrer Verwaltungsoberfläche für jede IP ein Feld „Reverse DNS“. Viele verlangen, dass der Forward-Record zuerst existiert.
Cloud-Plattformen: meist für statische oder reservierte Adressen unterstützt, manchmal nur per API-Aufruf oder Support-Anfrage, und manchmal für ausgehende E-Mails gar nicht.
Privat- oder Büroanschluss: Der Provider setzt ihn. Geschäftsanschlüsse mit statischer IP bekommen auf Anfrage oft einen eigenen PTR; Privatanschlüsse in der Regel nicht.
Shared Hosting: Die Adresse wird von vielen Websites geteilt, und der PTR nennt den Server des Hosting-Unternehmens. Das ist normal und muss nicht behoben werden.
Eigener Adressblock: Sie betreiben die Reverse-Zone selbst oder lassen sie sich delegieren. Für Blöcke kleiner als ein /24, bei denen sich eine ganze in-addr.arpa-Zone nicht entlang der Oktettgrenzen delegieren lässt, verwenden Anbieter die CNAME-basierte Technik aus RFC 2317.

Wen Sie fragen müssen, erfahren Sie, indem Sie nachschlagen, wer die Adresse hält; siehe Wo wird eine Website gehostet.

Forward-confirmed Reverse DNS

Ein PTR-Record allein beweist wenig, denn wer die Reverse-Zone kontrolliert, kann einen beliebigen Namen hineinschreiben, auch mail.yourbank.example. Was Empfänger tatsächlich prüfen, ist, ob beide Richtungen übereinstimmen:

IP → PTR → ein Name
dieser Name → A/AAAA → dieselbe IP

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com A
192.0.2.25

Schließt sich der Kreis, nennt man das Forward-confirmed Reverse DNS (FCrDNS). Es zeigt, dass die Person, die die Adresse kontrolliert, und die Person, die den Namen kontrolliert, zusammenarbeiten. Das ist ein bescheidenes, aber echtes Signal.

Warum es für E-Mail wichtig ist

E-Mail-Empfänger nutzen Reverse DNS seit Jahrzehnten als Eingangsgröße für Spamfilter, denn eine Maschine ohne PTR oder mit einem generischen wie host-192-0-2-25.dynamic.isp.example ist weit eher ein infizierter Heimrechner als ein Mailserver. Große Postfachanbieter schreiben in ihren Absenderrichtlinien, dass sendende IPs gültiges Forward- und Reverse-DNS haben müssen; ohne das sind Abweisungen oder Verzögerungen mit Meldungen zu erwarten, in denen „PTR record“ oder „reverse DNS“ vorkommt.

Bringen Sie für einen Mailserver drei Namen in Einklang:

Was	Sollte sein
PTR der sendenden IP	`mail.example.com`
`A`/`AAAA` von `mail.example.com`	die sendende IP
Name in der SMTP-Begrüßung (`HELO`/`EHLO`)	`mail.example.com`

Der PTR muss nicht zur Domain in der From-Adresse passen. Ein Server mail.hosting.example kann für Hunderte Kundendomains versenden; diese in Einklang zu bringen ist die Aufgabe von SPF, DKIM und DMARC, erklärt in MX, SPF, DKIM und DMARC.

Versenden Sie über einen E-Mail-Dienstleister oder einen gehosteten Postfachdienst, gehören die sendenden IPs diesem, und der PTR ebenso. Da gibt es für Sie nichts zu konfigurieren.

IPv6 verdient eine eigene Warnung: Hat Ihr Server eine IPv6-Adresse, bevorzugt er sie oft für ausgehende E-Mails, und Empfänger sind bei IPv6 tendenziell strenger mit dem PTR. Setzen Sie entweder auch für diese Adresse PTR und AAAA, oder lassen Sie den Mailserver nur über IPv4 versenden.

Wo Ihnen PTR-Records sonst begegnen

traceroute und mtr zeigen Routernamen aus PTR-Records, die oft Netz und Stadt jedes Hops verraten.
Logs und Sicherheitswerkzeuge lösen Client-Adressen zu Namen auf. Betrachten Sie diese Namen als Hinweise; die Gegenseite kontrolliert sie.
Zugriffsregeln auf Basis von Reverse DNS (etwa „erlaube *.crawler.example“) sind nur sicher, wenn die Software den Namen vorwärts bestätigt. So empfehlen Suchmaschinen, ihre Crawler zu verifizieren.
Manche SSH- und FTP-Server führen bei jeder Verbindung eine Reverse-Abfrage durch; eine kaputte Reverse-Zone zeigt sich als Verzögerung von mehreren Sekunden beim Anmelden (UseDNS in OpenSSH).

Was ein PTR-Record nicht verrät

Nicht, welche Websites dort laufen. Eine IP kann Tausende Websites hosten; der PTR ist ein einzelner Name, den der Adressinhaber gewählt hat. „Reverse-IP“-Dienste, die Domains auf einer Adresse auflisten, nutzen eigene gesammelte Daten, keine PTR-Records.
Nicht, wem der Server gehört. server42.hosting.example nennt Ihnen das Hosting-Unternehmen. Die Registrierungsdaten des Adressblocks sagen Ihnen dasselbe, zuverlässiger.
Nicht, wo er steht. Flughafencodes in Routernamen sind bestenfalls Hinweise.
Ziemlich oft gar nichts. Viele Adressen haben überhaupt keinen PTR. Für einen Webserver ist das harmlos.

Einrichten: eine Checkliste

Wählen Sie einen Hostnamen in einer Domain, die Sie kontrollieren: mail.example.com. Vermeiden Sie die reine Domain und Namen, die bereits einem anderen Zweck dienen.
Legen Sie zuerst den Forward-Record an: mail.example.com A 192.0.2.25 (und AAAA, falls zutreffend).
Setzen Sie den PTR in der Oberfläche des Anbieters, oder bitten Sie Anbieter oder Provider darum, auf genau diesen Hostnamen.
Konfigurieren Sie den Mailserver so, dass er sich mit demselben Namen meldet (etwa myhostname in Postfix).
Prüfen Sie beide Richtungen mit dig, für IPv4 und IPv6.
Rechnen Sie mit der TTL des alten PTR, bevor Sie das Ergebnis beurteilen. Wie das Caching funktioniert, beschreibt Was ist die TTL im DNS.

Häufige Fehler

Einen PTR-Record in der Forward-Zone anlegen und sich wundern, warum sich nichts ändert.
Ein PTR, der auf einen Namen zeigt, der nicht auflöst oder auf eine andere IP auflöst.
Mehrere PTR-Records auf einer Adresse. Das ist zulässig, aber viele Prüfungen nehmen nur einen davon, und zwar unvorhersehbar. Verwenden Sie genau einen.
Den generischen Standard-PTR des Anbieters auf einer Adresse belassen, die E-Mails versendet.
IPv4 sorgfältig einrichten und vergessen, dass der Server auch über IPv6 versendet.
Die IP des Servers ändern und nur den Forward-Record aktualisieren.
Einen PTR als Identitätsnachweis lesen. Ohne Vorwärtsbestätigung beweist er nichts.

Mit OrbitProbe prüfen

Die IP-Abfrage von OrbitProbe löst einen Hostnamen zu seinen IPv4- und IPv6-Adressen auf und zeigt für jede Adresse den Reverse-DNS-Namen zusammen mit dem autonomen System und dem Netzinhaber. Geben Sie den Hostnamen Ihres Mailservers ein: Ist der für jede Adresse gezeigte Reverse-Name der Hostname, den Sie eingegeben haben, ist der Kreis geschlossen. Fehlt der Reverse-Name oder ist er generisch, ist der daneben gezeigte Netzinhaber die Organisation, die ihn ändern kann.