Rekursive und iterative Namensauflösung

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Abfrage des DNS

Rekursive und iterative Namensauflösung beschreibt verschiedene Arten der Namensauflösung im Domain Name System (DNS).

Eine DNS-Anfrage kann von einem Nameserver nach drei verschiedenen Verfahren beantwortet werden:

  • autoritativ (der Server holt die Daten aus einer lokalen Zonendatei)
  • nicht-autoritativ
    • rekursiv (der Server holt die Daten von einem anderen Nameserver)
    • iterativ (der Server antwortet mit einem Verweis auf andere Nameserver)

Welches Verfahren angewandt wurde, ergibt sich aus den Flags im Header der DNS-Antwort.

Autoritative Antwort

[Bearbeiten | Quelltext bearbeiten]

Eine autoritative Antwort erfolgt, wenn der angefragte Domainname in einer Zone enthalten ist, für die der angefragte Nameserver zuständig ist. Ob eine Anfrage autoritativ, also aus einer lokalen Zonendatei, beantwortet wurde, wird durch das Flag Authoritative Answer (AA) in der DNS-Antwort definiert.

Rekursive Antwort

[Bearbeiten | Quelltext bearbeiten]

Der Administrator eines Nameservers kann konfigurieren, ob der Nameserver Anfragen rekursiv bearbeiten kann oder nicht. Gängige Praxis ist es, Rekursion für unbekannte Clients zu deaktivieren, da ein offener DNS-Resolver für DNS Amplification Attacks missbraucht werden kann. Ein anfragender Resolver setzt im Header einer DNS-Anfrage das Flag Recursion Desired (RD), wenn er eine rekursive Auflösung seiner Anfrage wünscht. Der Nameserver kopiert das RD-Flag von der Anfrage in die Antwort unverändert. Zusätzlich zeigt der Nameserver über das Flag Recursion Available (RA) an, ob er Rekursion unterstützt. Nur wenn die Antwort sowohl das RD-Flag, als auch das RA-Flag enthält, kam tatsächlich Rekursion zum Einsatz.

Ein Nameserver kann eine rekursive Anfrage entweder selbst auflösen, indem er nacheinander Nameserver anfragt, bis er eine autoritative Antwort erhält, oder die Anfrage an einen anderen rekursiv arbeitenden Nameserver weiterleiten. Im Falle einer Weiterleitung wird der Nameserver, an den eine rekursive Anfrage weitergeleitet wird, Forwarder genannt.[1]

Eine rekursive Antwort enthält entweder die gesuchten Resource Records oder einen Fehlercode, jedoch niemals einen Verweis auf einen anderen Nameserver.[1] Der anfragende Resolver erhält bei einer rekursiven Antwort das Ergebnis einer abgeschlossenen Namensauflösung zurück.

Iterative Antwort

[Bearbeiten | Quelltext bearbeiten]

Eine iterative Antwort enthält anstelle der gesuchten Daten einen Verweis auf andere Nameserver, die der Resolver als Nächstes anfragen kann. Ein derartiger Verweis enthält einen Zonennamen, für den ein oder mehrere andere Nameserver zuständig sind, sowie die Domainnamen der zuständigen Nameserver. Falls bekannt, sind auch die IP-Adressen der Nameserver enthalten (Glue Records).

Eine iterative Antwort bringt den anfragenden Resolver im hierarchischen Domain-Namensraum einen Schritt näher an die gesuchten Daten. Die Root-Nameserver beispielsweise verweisen mit einer iterativen Antwort auf die zuständigen Nameserver der Top-Level-Domain, die wiederum mit einer iterativen Antwort auf die Nameserver der Second-Level-Domain verweisen. Durch wiederholte (iterative) Anfrage erreicht der anfragende Resolver schließlich einen autoritativen Nameserver, von dem er eine autoritative Antwort mit den gesuchten Resource Records erhält.

Das folgende fiktive Beispiel zeigt eine iterative DNS-Antwort mit nslookup:

C:\> nslookup test.example.com

Name:   test.example.com
Served by:
 - dns01.extern.com
       172.27.182.11, 172.27.158.208
       example.com
 - dns02.extern.com
       example.com
 - dns03.extern.com
       172.27.157.16
       example.com

Der Nameserver teilt in diesem Beispiel dem Resolver mit, dass er den Namen test.example.com nicht auflösen kann, dass er aber drei Nameserver kennt, die Informationen zu diesem Namen besitzen. Für den Nameserver dns01.extern.com werden zwei IP-Adressen mitgeliefert, für dns02.extern.com keine und dns03.extern.com eine.

Beispiel Namensauflösung

[Bearbeiten | Quelltext bearbeiten]

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.

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 z. B. 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.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. a b RFC 8499 – DNS Terminology. Januar 2019 (englisch).