Reverse PTR Name Builder (IPv4)
Erstelle in-addr.arpa PTR-Namen aus IPv4-Adressen
Der Reverse-PTR-Name-Builder für IPv4 wandelt IPv4-Adressen in die entsprechenden in-addr.arpa-Reverse-DNS-Namen um, die für PTR-Records verwendet werden. Geben Sie eine Adresse wie 192.168.1.100 ein und das Tool gibt 100.1.168.192.in-addr.arpa zurück. Es verarbeitet auch Masseneingaben und konvertiert Listen von IP-Adressen für die Batch-Vorbereitung von Zonendateien.
Reverse-DNS und PTR-Records verstehen
Reverse-DNS ist der Mechanismus, der IP-Adressen zurück auf Hostnamen abbildet. Während Forward-DNS die Frage beantwortet "Was ist die IP-Adresse für mail.example.com?", beantwortet Reverse-DNS das Gegenteil: "Welcher Hostname ist mit 192.168.1.100 verbunden?". Diese Zuordnung wird in PTR-(Pointer-)Records unter der speziellen Domain in-addr.arpa gespeichert und wird im gesamten Netzwerkbereich für Protokollierung, Sicherheitsüberprüfung und E-Mail-Zustellung verwendet.
Der Grund, warum Reverse-DNS ein spezielles Format anstelle einer direkten IP-Abfrage verwendet, ist, dass DNS Namen hierarchisch von rechts nach links auflöst. Für Forward-DNS wird mail.example.com aufgelöst, indem zuerst die com-Nameserver, dann example.com, dann mail.example.com abgefragt werden. Damit die IP-Adressdelegation auf die gleiche Weise funktioniert, müssen die Oktette der Adresse umgekehrt werden. Die IP 192.168.1.100 wird zu 100.1.168.192.in-addr.arpa, was es der DNS-Delegierung ermöglicht, dem gleichen Top-Down-Muster zu folgen: Die Zone 192.in-addr.arpa wird an den Inhaber des 192.0.0.0/8-Blocks delegiert, der dann 168.192.in-addr.arpa an den Inhaber von 192.168.0.0/16 delegieren kann, und so weiter bis zu einzelnen /24-Zonen.
Diese Umkehrung ist vom Konzept her einfach genug, aber in der Praxis fehleranfällig. Das Transponieren von Oktetten von Hand ist eine zuverlässige Quelle von Tippfehlern, besonders wenn man mit Dutzenden von Adressen in einer Zonendatei arbeitet. Dieses Tool eliminiert dieses Risiko, indem es den korrekten in-addr.arpa-Namen automatisch berechnet, einschließlich der Zonendelegierungsgrenzen für CIDR-Blöcke.
So erstellen Sie einen IPv4-Reverse-PTR-Namen
- Geben Sie eine oder mehrere IPv4-Adressen ein (z.B.
192.168.1.100) - Das Tool kehrt die Oktettreihenfolge um und hängt
.in-addr.arpaan - Überprüfen Sie den generierten PTR-Namen, der bereit für die Verwendung in DNS-Zonendateien ist
- Bei Masseneingabe werden alle Adressen auf einmal konvertiert, mit Ergebnissen pro Zeile aufgelistet
Beispiele für IPv4-Reverse-DNS-Namen
| IPv4-Adresse | Reverse-PTR-Name |
|---|---|
192.168.1.100 | 100.1.168.192.in-addr.arpa |
10.0.0.1 | 1.0.0.10.in-addr.arpa |
172.16.254.3 | 3.254.16.172.in-addr.arpa |
8.8.8.8 | 8.8.8.8.in-addr.arpa |
203.0.113.50 | 50.113.0.203.in-addr.arpa |
1.2.3.4 | 4.3.2.1.in-addr.arpa |
Beispiele für Reverse-DNS-Zonendelegierung
| CIDR-Block | Reverse-Zonenname | PTR-Record-Präfix |
|---|---|---|
192.168.1.0/24 | 1.168.192.in-addr.arpa | Einzelnes Oktett (z.B. 100) |
10.0.0.0/16 | 0.10.in-addr.arpa | Zwei Oktette (z.B. 1.0) |
172.16.0.0/8 | 172.in-addr.arpa | Drei Oktette (z.B. 3.254.16) |
Wann Sie den IPv4-PTR-Name-Builder verwenden sollten
- Reverse-DNS-Zonen konfigurieren in BIND, PowerDNS oder anderen autoritativen DNS-Servern
- E-Mail-Server-Einrichtung -- Mailserver prüfen PTR-Records, um die Legitimität der Absender-IP zu verifizieren; falsche PTR-Namen verursachen Zustellungsfehler
- Zonendatei-Einträge vorbereiten für die Massenerstellung von PTR-Records über ein /24 oder größere Netzwerkblöcke
- Reverse-Lookups troubleshooten, indem der korrekte
in-addr.arpa-Name bestätigt wird, bevordig -xodernslookupausgeführt wird - ISP-Delegierungsanfragen -- Bereitstellung des korrekten Zonennamens bei der Anforderung einer Reverse-DNS-Delegierung von Ihrem Upstream-Provider
- Audit und Dokumentation -- Generierung des Reverse-Namens für jede IP in Ihrer Zuweisung für Infrastruktur-Aufzeichnungen
Wie IPv4-Reverse-DNS funktioniert
Reverse-DNS bildet IP-Adressen zurück auf Hostnamen ab, unter Verwendung der Domain in-addr.arpa. Das System nutzt die DNS-Hierarchie selbst, indem es die IP-Adressen-Oktette umkehrt, sodass die Delegierung dem gleichen Top-Down-Muster wie Forward-DNS folgt.
Warum Oktette umgekehrt werden
DNS löst Namen von rechts nach links durch die Hierarchie auf. Für Forward-DNS wird mail.example.com aufgelöst, indem die com-Server, dann example.com, dann mail.example.com abgefragt werden. Damit die IP-Adressdelegation auf die gleiche Weise funktioniert, müssen die Oktette umgekehrt werden:
- IP
192.168.1.100befindet sich im Block192.0.0.0/8 - Die Reverse-Zone dieses Blocks ist
192.in-addr.arpa - Die
/16-Zone192.168.0.0/16wird zu168.192.in-addr.arpa - Die
/24-Zone192.168.1.0/24wird zu1.168.192.in-addr.arpa - Der einzelne Host-PTR ist
100.1.168.192.in-addr.arpa
PTR-Records in Zonendateien
Ein PTR-Record in der Zonendatei 1.168.192.in-addr.arpa sieht so aus:
100 IN PTR mail.example.com.
Die 100 ist relativ zur Zone (repräsentiert das letzte Oktett), und der Ziel-Hostname muss mit einem Punkt enden, um anzuzeigen, dass er vollqualifiziert ist.
Klassenloses Reverse-Delegation (RFC 2317)
Für Zuweisungen kleiner als ein /24, wie ein /28 oder /29, gilt die Standard-Oktettgrenzen-Delegierung nicht. RFC 2317 definiert einen Workaround unter Verwendung von CNAME-Records, um Teile einer /24-Zone zu delegieren. Der PTR-Name-Builder behandelt diese Fälle, indem er sowohl den Standard-in-addr.arpa-Namen als auch das entsprechende Delegierungsformat anzeigt.
Reverse-DNS in der Praxis
Der wichtigste einzelne Grund, Reverse-DNS korrekt einzurichten, ist E-Mail. Wenn Ihr Mailserver sich mit einem anderen Server verbindet, um eine Nachricht zuzustellen, führt der empfangende Server fast immer einen Reverse-DNS-Lookup auf Ihre IP-Adresse durch. Wenn kein PTR-Record vorhanden ist oder der PTR-Record auf einen Hostnamen zeigt, der nicht zurück zu Ihrer IP auflöst (ein Forward-Confirmed Reverse DNS Check, oder FCrDNS), wird Ihre Nachricht wahrscheinlich abgelehnt oder als Spam eingestuft. Jeder legitime Mailserver benötigt einen PTR-Record, der mit seinem Forward-DNS übereinstimmt, und dieses Tool hilft Ihnen, den korrekten in-addr.arpa-Namen für diesen Record zu erstellen.
Über E-Mail hinaus erscheint Reverse-DNS in Sicherheitsprotokollen, Intrusion-Detection-Systemen und Netzwerküberwachungs-Dashboards. Wenn Sie eine IP-Adresse in einem Protokoll sehen, macht ein Hostname daneben die Untersuchung viel schneller. Reverse-DNS spielt auch bei der Zugangskontrolle eine Rolle: Einige Dienste erlauben oder verweigern den Zugang basierend darauf, ob die verbindende IP einen gültigen PTR-Record hat. Obwohl dies allein keine starke Sicherheitsmaßnahme ist, gehört es zur grundlegenden Hygiene, die von gut verwalteten Netzwerken erwartet wird.
Wenn Sie eine Reverse-DNS-Delegierung von Ihrem ISP anfordern, müssen Sie den exakten Zonennamen angeben. Für eine /24-Zuweisung ist dies unkompliziert: 1.168.192.in-addr.arpa für den Block 192.168.1.0/24. Für kleinere Zuweisungen verwaltet der ISP typischerweise die Zone und erstellt einzelne PTR-Records in Ihrem Auftrag oder verwendet das RFC-2317-CNAME-Delegierungsschema, um Ihnen die Kontrolle über Ihren Teil der Zone zu geben.
Häufig gestellte Fragen
Warum benötigen Mailserver PTR-Records?
Viele Mailserver führen einen Reverse-DNS-Check auf verbindende IP-Adressen als Anti-Spam-Maßnahme durch. Wenn eine IP keinen PTR-Record hat oder der PTR-Hostname nicht zurück zu dieser IP auflöst (ein Forward-Confirmed Reverse DNS Check), kann der empfangende Server die Nachricht ablehnen oder unter Quarantäne stellen. Die Einrichtung korrekter PTR-Records ist eine der grundlegenden Voraussetzungen für die E-Mail-Zustellbarkeit.
Kann ich PTR-Records für Adressen erstellen, die mir nicht gehören?
Nein. PTR-Records müssen in der Reverse-DNS-Zone erstellt werden, die an den Inhaber des IP-Adressblocks delegiert ist. Wenn Sie eine /24-Zuweisung von Ihrem ISP haben, kann dieser die Reverse-Zone an Ihre Nameserver delegieren. Für kleinere Zuweisungen bitten Sie typischerweise den ISP, PTR-Records in Ihrem Auftrag zu erstellen.
Was ist der Unterschied zwischen dig -x und der manuellen Abfrage des PTR-Namens?
Der Befehl dig -x 192.168.1.100 ist eine Abkürzung, die automatisch die Abfrage für 100.1.168.192.in-addr.arpa mit dem Typ PTR konstruiert. Das Ergebnis ist identisch mit der manuellen Ausführung von dig PTR 100.1.168.192.in-addr.arpa.
Sollte der PTR-Record-Hostname mit dem Forward-DNS-A-Record übereinstimmen?
Ja. Best Practice ist sicherzustellen, dass der PTR-Record für eine IP-Adresse auf einen Hostnamen zeigt, der einen A-Record hat, der zurück zu derselben IP auflöst. Dieses Forward-Confirmed Reverse DNS (FCrDNS) wird von vielen Mailservern und Sicherheitstools geprüft. Eine Nichtübereinstimmung oder unterbrochene Kette verursacht Zustellbarkeitsprobleme und kann Sicherheitsalarme auslösen.
Wie richte ich Reverse-DNS für einen Cloud-gehosteten Server ein?
Cloud-Anbieter wie AWS, Azure und GCP bieten Mechanismen zur Konfiguration von PTR-Records für Ihre Instanzen. Bei AWS senden Sie ein Antragsformular, um einen PTR-Record mit einer Elastic IP zu verknüpfen. Bei Azure und GCP können PTR-Records über die DNS- oder Netzwerkschnittstelleneinstellungen der Plattform konfiguriert werden. Der genaue Prozess variiert je nach Anbieter, aber Sie müssen trotzdem den korrekten in-addr.arpa-Namen für Ihre IP kennen.
Verwandte Tools
- Reverse-PTR-Name-Builder (IPv6) - ip6.arpa-PTR-Namen aus IPv6-Adressen erstellen
- BIND-Zone-A/AAAA-Generator - BIND-Zone-A- und AAAA-Records aus CSV generieren
- Hostname-Validator - Hostnamen gemäß RFC 1123 validieren
- FQDN-Validator - Vollqualifizierte Domainnamen validieren
- Zonendatei-Linter - Zonendateien auf Syntaxfehler und Duplikate prüfen