Reverse-DNS-Lookup

So funktioniert dieses Tool

Beim Öffnen der Seite führt das Tool den Lookup für die Adresse aus, von der Sie sich verbinden. Geben Sie eine beliebige andere IPv4- oder IPv6-Adresse ein, um stattdessen diese nachzuschlagen.

Reverse DNS funktioniert über einen besonderen Teil des DNS-Baums. Für eine IPv4-Adresse kehrt der Server die 4 Oktette um und hängt in-addr.arpa an; für IPv6 kehrt er die 32 hexadezimalen Nibbles um und hängt ip6.arpa an. Der entstehende Name wird nach einem PTR-Record abgefragt, und der Wert dieses Records ist der Hostname. Der exakt abgefragte Name wird im Ergebnis gezeigt, damit Sie ihn mit eigenen Tools wiederholen können.

Die Abfrage geht zuerst über den Resolver unseres Servers. Kann dieser nicht antworten, fragt der Server einen öffentlichen DNS-over-HTTPS-Resolver nach demselben PTR-Namen — eine fehlende Antwort bedeutet also viel eher, dass kein Record existiert, als ein Resolver-Problem.

Kommt ein Hostname zurück, folgt ein zweiter Schritt: Das Tool löst den Hostnamen vorwärts zu seinen A- und AAAA-Records auf und prüft, ob die ursprüngliche Adresse darunter ist. Dann gilt das Ergebnis als forward-confirmed. Das ist die Prüfung, die Mailserver FCrDNS nennen, und der Unterschied zwischen einem Namen, den jemand in einen PTR-Record getippt hat, und einem Namen, der wirklich zur Adresse gehört.

Das Tool schlägt außerdem nach, welches autonome System die Adresse ankündigt, und zeigt Nummer und Name, denn das Netzwerk sagt ebenso viel über eine IP wie der Hostname. Private und reservierte Adressen wie 192.168.x.x oder 10.x.x.x werden erkannt und nicht abgefragt. PTR-Antworten werden 10 Minuten gecacht; Lookups fremder Adressen sind pro Besucher ratenbegrenzt.

So lesen Sie das Ergebnis

Hostname gefunden und forward-confirmed. Die Adresse hat einen PTR-Record, und der Name löst zurück auf dieselbe Adresse auf. So sieht ein gut betriebener Mailserver, Webserver oder Anbieteranschluss aus.

Hostname gefunden, nicht bestätigt. Der PTR-Record existiert, aber der Hostname zeigt auf eine andere Adresse oder ins Leere. Der Name kann veraltet sein, oder der Inhaber hat einen PTR ohne passenden Vorwärts-Record gesetzt. Mail von einer solchen Adresse scheitert oft an strengen Prüfungen.

Hostname gefunden, Vorwärtsprüfung nicht verfügbar. Der PTR-Wert konnte gar nicht aufgelöst werden. Wie einen unbestätigten Namen behandeln.

Kein Hostname. Kein PTR-Record veröffentlicht. Der Normalzustand vieler Verbraucheranschlüsse und Cloud-Server, deren Betreiber nie einen gesetzt haben. Für sich kein Zeichen von Missbrauch, aber direkt von einer solchen Adresse gesendete Mail wird von den meisten Empfängern abgewiesen.

Lesen Sie den Hostnamen selbst auf Hinweise. Namen wie 203-0-113-45.dyn.example-isp.net betten die Adresse ein und kennzeichnen den Pool als dynamisch — meist eine Residential-IP für Teilnehmer. Namen wie mail.example.com oder vps-12345.hosting.example identifizieren eine bestimmte Maschine. Ein Hostname, der auf die Domain eines Cloud-Anbieters endet, verrät eine Rechenzentrums-IP, egal was davor steht. Die Netzwerkzeile unter dem Hostnamen zeigt ASN und Organisation; eine Adresse, deren PTR sich als Mailserver einer Bank ausgibt, aber im Netz eines Hosters sitzt, verdient Misstrauen.

Reverse DNS setzen oder korrigieren

Nur wer den Adressblock kontrolliert, kann PTR-Records veröffentlichen; aus der eigenen DNS-Zone heraus geht das nicht.

Für einen Cloud- oder dedizierten Server

1. Die PTR-Einstellung im Control Panel des Anbieters finden, meist als Reverse DNS, rDNS oder PTR bezeichnet, neben den Netzwerkeinstellungen des Servers oder in der IP-Liste.
2. Den gewünschten Hostnamen als vollqualifizierten Namen eintragen, etwa mail.example.com.
3. Vor dem Speichern sicherstellen, dass der Vorwärts-Record existiert: mail.example.com muss bereits einen A- (oder AAAA-)Record auf genau diese Adresse haben, sonst wird der Name nicht forward-confirmed.
4. Warten, bis der Anbieter den Record veröffentlicht, dann hier prüfen. Manche Anbieter brauchen Minuten, andere arbeiten stündlich.
5. Bei einem Mailserver den Hostnamen, den die Mailsoftware in der HELO- oder EHLO-Begrüßung meldet, auf denselben Namen setzen. Empfänger vergleichen alle drei.

Für eine IPv6-Adresse

Dieselben Schritte, aber das Panel des Anbieters verlangt womöglich, die Reverse-Zone Ihres Präfixes an eigene Nameserver zu delegieren, statt einen einzelnen Record einzutragen. Bei einem /64 oder größer beim Anbieter nach Reverse-Zonen-Delegation fragen.

Für einen Heim- oder Büroanschluss

Internetanbieter passen PTR-Records für Verbraucheranschlüsse in der Regel nicht an. Brauchen Sie einen forward-confirmed Hostnamen für ausgehende Mail, senden Sie über das Relay des Anbieters oder eines Dritten, oder nutzen Sie einen Geschäftstarif mit statischer Adresse, bei dem PTR-Änderungen meist angeboten werden.

Vom eigenen Computer prüfen

dig -x 203.0.113.45 unter macOS oder Linux bzw. nslookup 203.0.113.45 unter Windows führt dieselbe PTR-Abfrage gegen Ihren eigenen Resolver aus. dig -x funktioniert auch für IPv6 und baut den ip6.arpa-Namen für Sie.

Warum Reverse DNS wichtig ist

Mailzustellung ist der Hauptgrund, einen PTR-Record zu setzen. Empfangende Server schlagen die sendende Adresse nach, bevor sie eine Nachricht annehmen, und eine Adresse ohne Hostnamen oder mit einem nicht zurück auflösenden Hostnamen ist ein starkes Spam-Signal. Zusammen mit einem Blacklist-Check und korrekten SPF- und DKIM-Records gehört forward-confirmed Reverse DNS zu den Grundlagen der Mailzustellung.

Logging und Fehlersuche sind der zweite Grund. Server-Logs, Traceroutes und Firewall-Berichte mit Hostnamen statt nackter Adressen sind viel schneller lesbar; die Hostnamen in einem Traceroute stammen genau aus diesen PTR-Records. Und wer einen Proxy oder ein VPN vor der Nutzung prüft, hat im PTR-Record ein weiteres leicht prüfbares Signal: Eine Verbindung, die wie ein Heimnutzer aussehen soll, deren Adresse aber auf das Namensschema eines Hosters auflöst, wird von jedem Dienst, der hinschaut, als Rechenzentrumsverbindung eingestuft.

Reverse DNS für ganze Blöcke und für IPv6

Für eine einzelne Adresse trägt der Anbieter den PTR-Record ein. Für einen ganzen Block delegieren Anbieter die Reverse-Zone oft an die Nameserver des Kunden, der dann PTR-Records für jede Adresse wie jede andere Zone verwaltet. Ein IPv4-/24 entspricht einer Reverse-Zone der Form 113.0.203.in-addr.arpa. Kleinere Blöcke wie ein /29 lassen sich nicht direkt delegieren, weil der Reverse-Baum nach Oktetten organisiert ist; Anbieter lösen das mit einer klassenlosen Delegation über CNAME-Records. Fehlen die PTR-Records Ihres Blocks, prüfen Sie mit dem DNS-Lookup die NS-Records der Reverse-Zone, ob die Delegation überhaupt existiert.

IPv6-Reverse-Zonen bestehen aus den 32 umgekehrten Nibbles unter ip6.arpa; ein /64 ergibt eine Zone mit 16 Nibble-Labels, ein /48 eine mit 12. Die Delegation ist einfacher, weil jede übliche Präfixlänge auf eine Nibble-Grenze fällt.

Grenzen dieses Tools

• Ein fehlender PTR-Record wird als „kein Hostname“ gemeldet. Ob der Inhaber keinen veröffentlichen wollte oder die Reverse-Zone defekt ist, kann das Tool nicht unterscheiden.
• Die Vorwärtsbestätigung prüft nur A- und AAAA-Records des PTR-Hostnamens.
• Ein PTR-Record kann beliebigen Text enthalten. Der Hostname ist eine Behauptung; erst das Forward-confirmed-Flag und die Netzwerkinformation machen sie verifiziert.
• Das Tool liefert den ersten PTR-Record; wenige Adressen veröffentlichen mehrere.
• Antworten werden 10 Minuten gecacht.
• Private, Loopback- und reservierte Adressen werden nicht nachgeschlagen.
• Reverse DNS verrät nichts über die Person hinter einer Adresse; für Standort und Netzwerktyp nutzen Sie den IP-Lookup.