Domain Name System/Resolver: Unterschied zwischen den Versionen

Aktuelle Version vom 14. Juni 2026, 00:44 Uhr

Resolver

Schematische Darstellung der rekursiven und iterativen DNS-Abfrage

Resolver sind einfach aufgebaute Software-Module, die auf dem Rechner eines DNS-Teilnehmers installiert sind und die Informationen von Nameservern abrufen können.

Sie bilden die Schnittstelle zwischen Anwendung und Nameserver.
Der Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie, falls notwendig, zu einem FQDN und übermittelt sie an einen normalerweise fest zugeordneten Nameserver.
Ein Resolver arbeitet entweder rekursiv oder iterativ.

Im rekursiven Modus schickt der Resolver eine rekursive Anfrage an den ihm zugeordneten Nameserver.

Hat dieser die gewünschte Information nicht im eigenen Datenbestand, so kontaktiert der Nameserver weitere Server - und zwar solange, bis er eine Antwort erhält; entweder positive, oder von einem autoritativen Server eine negative.
Rekursiv arbeitende Resolver überlassen also die Arbeit zur vollständigen Auflösung ihrem Nameserver.

Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource Record oder einen Verweis auf weitere Nameserver, die er als Nächstes fragt.

Der Resolver hangelt sich so von Nameserver zu Nameserver, bis er von einem eine verbindliche Antwort erhält.

Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten angefordert hat, beispielsweise an den Webbrowser. Übliche Resolver von Clients arbeiten ausschließlich rekursiv; sie werden dann auch als Stub-Resolver bezeichnet.

Nameserver besitzen in der Regel eigene Resolver.
Diese arbeiten gewöhnlich iterativ.

Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup, host und dig. Vorlage:Siehe auch

Auflösung eines DNS-Requests

Angenommen, ein Rechner X will eine Verbindung zu "de.wikipedia.org." (Rechner Y) aufbauen.

Dazu braucht er dessen IP-Adresse.
In den folgenden Schritten wird beschrieben, wie dies ablaufen könnte.
Falls der Rechner X IPv6-fähig ist, läuft der Vorgang zunächst für IPv6 (Abfrage von AAAA Resource Record) und sofort danach für IPv4 (Abfrage von A Resource Record) ab.
Dabei kann eine Anfrage nach einer IPv6-Adresse mittels IPv4-Übertragung an einen IPv4-DNS-Server gerichtet werden.
Falls am Ende eine IPv6- und eine IPv4-Adresse für Rechner Y ermittelt werden, wird in der Regel laut der Default Policy Table in RFC 6724 die Kommunikation zwischen X und Y über IPv6 bevorzugt,^[1] es sei denn im Betriebssystem oder in den benutzten Anwendungen, wie zum Beispiel dem Webbrowser, wurde dieses Verhalten anders eingestellt.

Der Rechner X sucht in seiner Hosts-Datei, ob die IP-Adresse für "de.wikipedia.org" dort hinterlegt ist.

Falls dem nicht so ist, fragt er beim DNS-Server nach.
Dieser ist entweder fest eingetragen oder wurde per DHCP bzw. DHCPv6 automatisch zugewiesen und hat die Form nameserver 192.0.2.23 oder nameserver 2001:db8::23:cafe:affe:42.

Hat der DNS-Server von Rechner X eine IP-Adresse für den angefragten Namen zwischengespeichert, antwortet er damit und die Anfrage kommt zum Ende (siehe letzter Punkt).

Andernfalls fragt er einen der 13 Root-Nameserver nach "de.wikipedia.org.".

Der Root-Nameserver findet heraus, dass die Auflösung dieses Namens in der "org."-Zone weitergeht und sendet die Namen und die IP-Adressen der "org."-Nameserver (NS Resource Records und deren AAAA bzw. A Resource Records) zum DNS-Server von Rechner X.
Nun fragt der DNS-Server von Rechner X einen der Nameserver für "org."-Domains nach "de.wikipedia.org.".
Der "org."-Nameserver sendet ihm die Namen der Nameserver (und deren IP-Adressen, sofern sie zur selben Top-Level-Domain gehören) für die Zone "wikipedia.org.".
Anschließend fragt der DNS-Server von Rechner X einen "wikipedia.org."-Nameserver wie die IP-Adresse des Namens "de.wikipedia.org." ist.
Mit dieser Adresse wird an den DNS-Server von Rechner X geantwortet und der …
… sendet sie an den Rechner X, welcher nun zum Beispiel seine HTTP-Anfragen an die IP-Adresse von "de.wikipedia.org." senden kann.

Beispiel Namensauflösung

Im folgenden, kommentierten Beispiel wird zum Namen "www.heise.de." die IPv4-Adresse mit Hilfe des Resolver-Tools dig bestimmt. "+trace" bedeutet, dass die einzelnen Antworten auf iterative Anfragen an die Nameserver-Hierarchie angegeben werden, "+additional" sorgt dafür, dass zusätzlich dargestellt wird, dass die Nameserver für Delegierungen nicht nur NS Resource Records verwalten, sondern teilweise auch deren IP-Adressen in Form von A oder AAAA Resource Records kennen und mit ausliefern, "-t A" schließlich verlangt nach dem A Resource Record, also der IPv4-Adresse.

Es zeigt sich, dass nacheinander vier Nameserver befragt werden müssen, um zur Antwort zu gelangen:

$ dig +trace +additional -t A www.heise.de.

; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t A www.heise.de.
;; global options: printcmd
.            6086  IN   NS   B.ROOT-SERVERS.NET.
.            6086  IN   NS   D.ROOT-SERVERS.NET.
.            6086  IN   NS   J.ROOT-SERVERS.NET.
.            6086  IN   NS   G.ROOT-SERVERS.NET.
.            6086  IN   NS   K.ROOT-SERVERS.NET.
.            6086  IN   NS   C.ROOT-SERVERS.NET.
.            6086  IN   NS   M.ROOT-SERVERS.NET.
.            6086  IN   NS   I.ROOT-SERVERS.NET.
.            6086  IN   NS   H.ROOT-SERVERS.NET.
.            6086  IN   NS   E.ROOT-SERVERS.NET.
.            6086  IN   NS   F.ROOT-SERVERS.NET.
.            6086  IN   NS   A.ROOT-SERVERS.NET.
.            6086  IN   NS   L.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.   6644  IN   A    128.8.10.90
J.ROOT-SERVERS.NET.   10421  IN   A    192.58.128.30
J.ROOT-SERVERS.NET.   1289  IN   AAAA  2001:503:c27::2:30
G.ROOT-SERVERS.NET.   10940  IN   A    192.112.36.4
K.ROOT-SERVERS.NET.   4208  IN   A    193.0.14.129
K.ROOT-SERVERS.NET.   7277  IN   AAAA  2001:7fd::1
C.ROOT-SERVERS.NET.   6126  IN   A    192.33.4.12
M.ROOT-SERVERS.NET.   3274  IN   A    202.12.27.33
M.ROOT-SERVERS.NET.   7183  IN   AAAA  2001:dc3::35
I.ROOT-SERVERS.NET.   9788  IN   A    192.36.148.17
H.ROOT-SERVERS.NET.   10421  IN   A    128.63.2.53
H.ROOT-SERVERS.NET.   13739  IN   AAAA  2001:500:1::803f:235
E.ROOT-SERVERS.NET.   11125  IN   A    192.203.230.10
F.ROOT-SERVERS.NET.   9973  IN   A    192.5.5.241
;; Received 500 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms

192.168.2.1 (siehe letzte Zeile) ist der eingetragene Nameserver des abfragenden Rechners, welcher auf die Root-Nameserver verweist, die alle weiter via IPv4 befragt werden können, einige zusätzlich auch mittels IPv6.

Die Root-Nameserver verwalten die Wurzel-Zone (Zone, die die Nameserver für .org, .de, .com und andere Top Level Domains enthält) der Namensauflösung, dargestellt durch einen Punkt.
Die IP-Adressen der Root-Nameserver ändern sich sehr selten und müssen allen Nameservern bekannt sein, sofern sie das Internet betreffende Anfragen beantworten. (Diese IP-Adressen können beispielsweise in einer als "Root Hints" bezeichneten Textdatei mitgeliefert werden.)

de.           172800 IN   NS   F.NIC.de.
de.           172800 IN   NS   L.DE.NET.
de.           172800 IN   NS   S.DE.NET.
de.           172800 IN   NS   Z.NIC.de.
de.           172800 IN   NS   A.NIC.de.
de.           172800 IN   NS   C.DE.NET.
A.NIC.de.        172800 IN   A    194.0.0.53
C.DE.NET.        172800 IN   A    208.48.81.43
F.NIC.de.        172800 IN   A    81.91.164.5
F.NIC.de.        172800 IN   AAAA  2001:608:6:6::10
L.DE.NET.        172800 IN   A    89.213.253.189
S.DE.NET.        172800 IN   A    195.243.137.26
Z.NIC.de.        172800 IN   A    194.246.96.1
Z.NIC.de.        172800 IN   AAAA  2001:628:453:4905::53
;; Received 288 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 58 ms

Aus den 13 genannten Root-Nameservern wurde zufällig "I.ROOT-SERVERS.NET." ausgewählt, um ihm die Frage nach "www.heise.de." zu stellen.

Er antwortete mit sechs Nameservern zur Auswahl, die für die Zone "de." verantwortlich sind.
Auch hier ist bei zwei Servern die Abfrage mittels IPv6 möglich.

heise.de.        86400  IN   NS   ns.plusline.de.
heise.de.        86400  IN   NS   ns.heise.de.
heise.de.        86400  IN   NS   ns2.pop-hannover.net.
heise.de.        86400  IN   NS   ns.pop-hannover.de.
heise.de.        86400  IN   NS   ns.s.plusline.de.
ns.s.plusline.de.    86400  IN   A    212.19.40.14
ns.heise.de.      86400  IN   A    193.99.145.37
ns.plusline.de.     86400  IN   A    212.19.48.14
ns.pop-hannover.de.   86400  IN   A    193.98.1.200
;; Received 220 bytes from 81.91.164.5#53(F.NIC.de) in 52 ms

Aus den sechs genannten Nameservern wurde zufällig "F.NIC.de." ausgewählt, um Näheres über "www.heise.de." zu erfahren.

Er beantwortet die Anfrage mit fünf möglichen Delegierungen.
Unter anderem mit einer Delegierung auf den Server "ns.heise.de.".
Diese Information würde ohne den dazugehörigen A Resource Record, auf 193.99.145.37 zeigend, auf demselben Server nichts helfen, denn der Name liegt in der Zone "heise.de.", die er selbst verwaltet.
Man spricht bei dieser Art von Information auch von Glue Records (von engl. glue, kleben).
Sollte der Server "ns2.pop-hannover.net." für den nächsten Schritt ausgewählt werden, so wäre in einer gesonderten Namensauflösung zunächst dessen IP-Adresse zu bestimmen, da diese hier nicht mitgesendet wurde.

www.heise.de.      86400  IN   A    193.99.144.85
heise.de.        86400  IN   NS   ns.pop-hannover.de.
heise.de.        86400  IN   NS   ns.plusline.de.
heise.de.        86400  IN   NS   ns2.pop-hannover.net.
heise.de.        86400  IN   NS   ns.s.plusline.de.
heise.de.        86400  IN   NS   ns.heise.de.
ns.heise.de.      86400  IN   A    193.99.145.37
ns.pop-hannover.de.   10800  IN   A    193.98.1.200
ns2.pop-hannover.net.  86400  IN   A    62.48.67.66
;; Received 220 bytes from 193.98.1.200#53(ns.pop-hannover.de) in 4457 ms

Aus den fünf genannten Nameservern wurde zufällig "ns.pop-hannover.de." herangezogen, um die Frage nach "www.heise.de." zu beantworten.

Die Antwort lautet 193.99.144.85.
Damit ist die Anfrage am Ziel angelangt.
Es werden auch wieder dieselben Nameserver als verantwortlich für "heise.de." genannt, ohne also auf andere Nameserver zu verweisen.

Beispiel Reverse Lookup

Für den Reverse Lookup, also das Auffinden eines Namens zu einer IP-Adresse, wandelt man die IP-Adresse zunächst formal in einen Namen um, für den man dann das DNS nach einem PTR Resource Record befragt.

Da die Hierarchie bei IP-Adressen von links nach rechts spezieller wird (siehe Subnetz), beim DNS aber von rechts nach links, dreht man beim ersten Schritt die Reihenfolge der Zahlen um und aus der IPv4-Adresse 193.99.144.85 wird beispielsweise
der Name "85.144.99.193.in-addr.arpa." sowie aus der IPv6-Adresse 2a02:2e0:3fe:100::6 der Name "6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa." erzeugt. (Dieser Name ist lang, da die implizit enthaltenen Nullen nun wieder explizit genannt werden müssen.)

Der PTR Resource Record für die so umgeformte IPv4-Adresse lässt sich analog zum vorigen Beispiel bestimmen:

$ dig +trace +additional -t PTR 85.144.99.193.in-addr.arpa.

; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t ptr 85.144.99.193.in-addr.arpa.
;; global options: printcmd
.            2643  IN   NS   M.ROOT-SERVERS.NET.
.            2643  IN   NS   A.ROOT-SERVERS.NET.
.            2643  IN   NS   B.ROOT-SERVERS.NET.
.            2643  IN   NS   C.ROOT-SERVERS.NET.
.            2643  IN   NS   D.ROOT-SERVERS.NET.
.            2643  IN   NS   E.ROOT-SERVERS.NET.
.            2643  IN   NS   F.ROOT-SERVERS.NET.
.            2643  IN   NS   G.ROOT-SERVERS.NET.
.            2643  IN   NS   H.ROOT-SERVERS.NET.
.            2643  IN   NS   I.ROOT-SERVERS.NET.
.            2643  IN   NS   J.ROOT-SERVERS.NET.
.            2643  IN   NS   K.ROOT-SERVERS.NET.
.            2643  IN   NS   L.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.   10978  IN   A    198.41.0.4
A.ROOT-SERVERS.NET.   2470  IN   AAAA  2001:503:ba3e::2:30
C.ROOT-SERVERS.NET.   387   IN   A    192.33.4.12
D.ROOT-SERVERS.NET.   2747  IN   A    128.8.10.90
E.ROOT-SERVERS.NET.   7183  IN   A    192.203.230.10
F.ROOT-SERVERS.NET.   14225  IN   AAAA  2001:500:2f::f
H.ROOT-SERVERS.NET.   7950  IN   A    128.63.2.53
H.ROOT-SERVERS.NET.   13245  IN   AAAA  2001:500:1::803f:235
I.ROOT-SERVERS.NET.   6172  IN   A    192.36.148.17
J.ROOT-SERVERS.NET.   7168  IN   A    192.58.128.30
J.ROOT-SERVERS.NET.   13860  IN   AAAA  2001:503:c27::2:30
K.ROOT-SERVERS.NET.   3541  IN   A    193.0.14.129
K.ROOT-SERVERS.NET.   9369  IN   AAAA  2001:7fd::1
L.ROOT-SERVERS.NET.   3523  IN   A    199.7.83.42
;; Received 512 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms

193.in-addr.arpa.    86400  IN   NS   ns3.nic.fr.
193.in-addr.arpa.    86400  IN   NS   sec1.apnic.net.
193.in-addr.arpa.    86400  IN   NS   sec3.apnic.net.
193.in-addr.arpa.    86400  IN   NS   sunic.sunet.se.
193.in-addr.arpa.    86400  IN   NS   ns-pri.ripe.net.
193.in-addr.arpa.    86400  IN   NS   sns-pb.isc.org.
193.in-addr.arpa.    86400  IN   NS   tinnie.arin.net.
;; Received 239 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 170 ms

99.193.in-addr.arpa.  172800 IN   NS   auth50.ns.de.uu.net.
99.193.in-addr.arpa.  172800 IN   NS   ns.ripe.net.
99.193.in-addr.arpa.  172800 IN   NS   auth00.ns.de.uu.net.
;; Received 120 bytes from 202.12.28.140#53(sec3.apnic.net) in 339 ms

144.99.193.in-addr.arpa. 86400 IN   NS   ns.heise.de.
144.99.193.in-addr.arpa. 86400 IN   NS   ns.s.plusline.de.
144.99.193.in-addr.arpa. 86400 IN   NS   ns.plusline.de.
;; Received 114 bytes from 194.128.171.99#53(auth50.ns.de.uu.net) in 2456 ms

85.144.99.193.in-addr.arpa. 86400 IN  PTR   www.heise.de.
144.99.193.in-addr.arpa. 86400 IN   NS   ns.heise.de.
144.99.193.in-addr.arpa. 86400 IN   NS   ns.s.plusline.de.
144.99.193.in-addr.arpa. 86400 IN   NS   ns.plusline.de.
ns.heise.de.      86400  IN   A    193.99.145.37
;; Received 148 bytes from 193.99.145.37#53(ns.heise.de) in 4482 ms

Die Antwort lautet also "www.heise.de.".

Es ist jedoch weder notwendig, dass jeder IP-Adresse ein Name zugeordnet ist, noch müssen Hin- und Rückauflösung einander entsprechen.
Die Auflösung beginnt wieder mit dem Verweis auf die Root-Nameserver und die Delegierungen finden offensichtlich an den durch Punkte markierten Grenzen zwischen den Zahlen statt.
Man sieht in dem Beispiel jedoch auch, dass nicht an jedem Punkt in einem Namen delegiert werden muss.

↑ RFC 6724 - Default Address Selection for Internet Protocol Version 6 (IPv6). Network Working Group of the IETF, S. 7 (Stand September 2012) Vorlage:"

[ietf-1] RFC 6724 - Default Address Selection for Internet Protocol Version 6 (IPv6). Network Working Group of the IETF, S. 7 (Stand September 2012) Vorlage:"

[1]