DNS-Glossar
Was ist eine Reverse-DNS-Abfrage?
Die Reverse-DNS-Abfrage (Reverse-DNS-Auflösung) ist eine DNS-Abfragemethode, mit der der zu einer IP-Adresse gehörende Domänenname ermittelt wird. Dabei wird ein PTR-Eintrag in der Zone „in-addr.arpa“ für IPv4 bzw. in der Zone „ip6.arpa“ für IPv6 abgefragt, wie in RFC 1035 und RFC 3596 beschrieben.
Die wichtigsten ErkenntnisseDie wichtigsten Erkenntnisse werden mithilfe von KI generiert. Da automatisierte Zusammenfassungen gelegentlich Fehler enthalten oder wichtige Zusammenhänge auslassen können, sollten Sie für vollständige Informationen stets den vollständigen Blogbeitrag lesen.Reverse DNS lookup is a DNS query method that resolves an IP address to its associated hostname by querying PTR records in the in-addr.arpa or ip6.arpa zones, enabling mail servers, logging systems, and security tools to display human-readable names instead of raw IP addresses. Organizations must create and maintain PTR records alongside forward DNS records, as mismatches or missing entries can cause legitimate email to be rejected, complicate incident investigation, and slow network troubleshooting. Automating PTR record creation through IP address management systems reduces errors and ensures consistency between forward and reverse DNS data, supporting both operational visibility and email delivery reliability.
So funktioniert die Reverse-DNS-Abfrage
Bei einer Reverse-DNS-Abfrage wird eine IP-Adresse in einen Namen umgewandelt, indem die Adresse als Domainname umgeschrieben und ein PTR-Eintrag abgefragt wird. Die Delegierung von Reverse-Zonen folgt der Hierarchie der Adressvergabe.
- Umformatierung der Adresse: Der Resolver kehrt die Oktette einer IPv4-Adresse um und hängt „in-addr.arpa“ an. So wird beispielsweise aus 192.0.2.10 die Adresse 10.2.0.192.in-addr.arpa. IPv6-Adressen werden als umgekehrte hexadezimale Nibbles unter „ip6.arpa“ geschrieben.
- Eine PTR-Abfrage senden: Der Resolver fragt nach einem PTR-Eintrag für diesen Namen. Er beginnt an der Root und folgt den Delegierungen zu den für die Reverse-Zone zuständigen Nameservern oder nutzt Antworten aus dem Cache.
- Erreichen des autoritativen Servers: Die Reverse-Zone wird in der Regel an den Netzwerkbetreiber delegiert, häufig über den Internetdienstanbieter oder eine regionale Internet-Registrierungsstelle für den Adressblock.
- Antwort zurückgeben: Der autoritative Server gibt den PTR-Eintrag mit einem Hostnamen zurück oder, falls kein Eintrag vorhanden ist, eine negative Antwort wie z. B. NXDOMAIN.
Ein PTR-Eintrag ist unabhängig vom entsprechenden A- oder AAAA-Eintrag, sodass die beiden voneinander abweichen können. Administratoren müssen beide erstellen und pflegen. Einige Tools überprüfen die Konsistenz, indem sie den zurückgegebenen Namen vorwärts auflösen und das Ergebnis mit der ursprünglichen Adresse vergleichen.
Häufige Probleme bei der Reverse-DNS-Abfrage
Hosts erhalten ihre Adressen über DHCP oder durch statische Zuweisung, aber niemand erstellt den entsprechenden PTR-Eintrag. In Protokollen und Traceroute-Ausgaben werden nur die reinen Adressen angezeigt, und manche Mailserver lehnen Nachrichten von diesen Hosts ab oder stufen sie herab.
Der PTR-Eintrag gibt einen Namen zurück, dessen A- oder AAAA-Eintrag auf eine andere Adresse oder gar keine Adresse verweist. Vorwärtsbestätigte Reverse-DNS-Prüfungen schlagen fehl, und Dienste, die übereinstimmende Einträge erfordern, lehnen die Verbindung ab oder kennzeichnen sie.
Der Netzwerkbetreiber erhält niemals eine Delegierung für den Block vom Provider oder der Adressregistrierungsstelle. Abfragen geben „SERVFAIL“ oder „NXDOMAIN“ zurück oder liefern die generischen Namen des Providers anstelle der beabsichtigten Hostnamen.
Adressen werden neu zugewiesen, aber alte PTR-Einträge bleiben bestehen. In den Protokollen wird der Datenverkehr dann dem falschen Hostnamen zugeordnet, was die Untersuchung von Vorfällen erschwert.
Tools, die jede Adresse auflösen, wie beispielsweise Protokoll-Viewer und Firewalls, kommen zum Stillstand, wenn Reverse-Zonen auf Nameserver verweisen, die nicht antworten. Die Verzögerung zeigt sich in Form von Timeouts, bis der Resolver aufgibt.
Verwandte Begriffe
Einrichtung von geregelten, auditfähigen IPAM-Workflow- und Genehmigungsmodellen für Unternehmensnetzwerke
Entdecken Sie IP-Management-Lösungen für geregelte, auditfähige IPAM-Workflows. Ermöglichen Sie bereichsbezogene Genehmigungen und lückenlose…
Content Hub Das OSI-Modell verstehen: Wo DNS und IP-Adressierung in die 7 Schichten passen
Machen Sie sich mit den sieben Schichten des OSI-Modells vertraut und erfahren Sie, wie DNS und IP-Adressierung in dieses Modell eingebunden sind. Lernen…
Skalierung von DNS und IPAM für IPv6- und Dual-Stack-Unternehmensnetzwerke
Skalieren Sie DNS und IPAM für Dual-Stack-Unternehmensnetzwerke. Erfahren Sie, wie Micetro Teams bei der Verwaltung von IPv6-Migrationen mit integrierten…
Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte Infrastructure-as-Code-Pipelines
Durch die Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte IaC-Pipelines mit Micetro werden Adress- und Eintragsänderungen zu versionierten,…
Podcast Podcast: Wie KI die Entwicklung von Unternehmenssoftware verändert
KI verändert die Netzwerkautomatisierung, doch eine sichere Implementierung erfordert solide Softwarepraktiken, Tests und Fachwissen, um Ausfälle zu…
Podcast Podcast: Why Open Platforms Matter in Network Operations
Open platforms and API-first architecture enable intelligent network operations, automation, and AI-driven workflows across hybrid enterprises.
Erhalten Sie mit LiveAssist Antworten aus den LiveNX-Daten, über die Sie bereits verfügen
Erfahren Sie, wie LiveAssist, das KI-gestützte Add-on für LiveNX, Ihre Netzwerkdaten in schnelle, gezielte Antworten umwandelt – mit einem Mehrwert, den…
Erstellung einer Kostenanalyse für den Ersatz bestehender appliancebasierter DDI-Lösungen durch eine Overlay-Verwaltungsschicht
Manuelle DDI-Arbeiten kosten die befragten Teams 1.040 Stunden pro Jahr. Hier erfahren Sie, wie Sie die Kosten für eine Verlängerung, den…