Was ist Reverse DNS?

Reverse DNS (rDNS) ist der Prozess, bei dem ein Name aus einer IP-Adresseingabe erkannt wird, während „herkömmliche“ DNS-Abfragen die gegenteilige Aufgabe umsetzen, indem sie einen Hostnamen in eine IP übersetzen. 

dig -x 24.117.59.59

Beispiel für eine Reverse-DNS-Suche auf einem Mac (mit Terminal)

nslookup 24.117.59.59

Beispiel für eine Reverse-DNS-Suche für Windows und Linux

Konkret umfasst rDNS die umgekehrte Auflösung des IP-Werts mit dem Zusatz „in-addr.arpa“ am Ende.¹ Der Befehl im obigen Beispiel sucht also tatsächlich nach „59.59.117.24.in-addr.arpa”. Wenn der Eigentümer der IP erfolgreich das rDNS konfiguriert hat, gibt diese Abfrage einen PTR-Datensatz (Pointer) zurück, der die IP einer Domain zuordnet:

59.59.117.24.in-addr.arpa. 43200 IN PTR 24-117-59-59.cpe.sparklight.net.

Während rDNS nicht universell für den herkömmlichen Webtraffic eingesetzt wird, sind PTR-Datensätze besonders wichtig für E-Mail-Server, die häufig rDNS-Abfragen durchführen, um Spam zu blockieren oder herauszufiltern. Um sicherzustellen, dass Nachrichten ohne Warnsignale empfangen werden, müssen legitime E-Mail-Anbieter rDNS für IP-Adressen ordnungsgemäß implementieren und DNS für die resultierenden Hostnamen weiterleiten. Diese Erwartung wurde etabliert, um zu verhindern, dass Spammer E-Mails von kompromittierten Computern senden, da diese IPs oft keine rDNS-Datensätze haben. Wenn sie dies tun, handelt es sich häufig um eine generische, dynamische Ausgabe, die darauf hindeutet, dass der Client kein gültiger E-Mail-Dienst ist.

Wie oben gezeigt, verweist die private IP 24.117.59.59 auf einen PTR-Datensatz von 24-117-59-59.cpe.sparklight.net, bei dem es sich um eine dynamische Ausgabe handelt, da es schlicht die IP-Adresse mit der angehängten Sparlight-Domain ist. Wenn also ein Spammer das Gerät hackt und eine E-Mail von der privaten IP sendet, würde der Empfänger die Nachricht wahrscheinlich blockieren oder filtern, da dynamische Antworten ein starkes Spam-Signal sind (eine hypothetische akzeptable Antwort wäre email.sparklight.net). Kurz gesagt, ein Spammer müsste über einen IP-Bereich verfügen, um die erforderlichen DNS-Einstellungen für die universelle Akzeptanz der Nachricht zu arrangieren – ein unerschwinglicher Preis für die meisten Cyberkriminellen.

Schließlich verlassen sich einige E-Mail-Server auf differenziertere rDNS-Einstellungen mit Hilfe von SMTP (Simple Mail Transfer Protocol), einem standardisierten Kommunikationsprotokoll für die E-Mail-Übertragung. E-Mail-Server können beispielsweise so konfiguriert werden, dass sie E-Mails ablehnen, wenn die rDNS-Abfrage nicht mit dem HELO-Befehl übereinstimmt, einer Nachricht, die die SMTP-Sitzung startet. Wenn ein Botnet also Tausende von E-Mails von Hunderten oder Tausenden von gekaperten Computern senden könnte, die zu einer Vielzahl von Netzwerken gehören, wäre es für den Cyberkriminellen schwierig, die richtige Domain in jeder HELO-Nachricht anzukündigen, selbst wenn das rDNS ordnungsgemäß für die IP konfiguriert war. 

Kunde: HELO mail.example.com

Server: 250 mail.example.com Hello

Damit eine rDNS-Abfrage eine gültige Antwort zurückgibt, muss eine rDNS-Zonendatei für in-addr.arpa erstellt werden, die den festen Netzwerkbereich widerspiegelt, der dem IP-Eigentümer zugewiesen ist. Insbesondere sollte der Zonenadministrator das letzte gepunktete Quartettt entfernen, das die Werte enthält, die explizit unter seiner Kontrolle stehen, die Reihenfolge des verbleibenden gepunkteten Oktetts umkehren und .in-add.arpa hinzufügen.

Da Sparklight eine Klasse-B-Adresse besitzt, lautet ihr rDNS-Zonendateiname 117.24.in-addr.arpa. Im Hinblick auf den Prozess der vollständigen Auflösung ist ARPA Eigentümer der Klasse-A-Adressen² 24.0.0.0/8, delegiert jedoch 117.24-Anfragen an Sparklight:  

Genau wie bei Forward DNS ist jeder „Punkt“ in einem rDNS-Hostnamen ein potenzieller Delegationspunkt. ICANN verwaltet die Zone in-addr.arpa und delegiert Unterzonen an Eigentümer eines IP-Bereichs.