Rekursive und iterative Namensauflösung
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]
Forward Lookup[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.
Reverse Lookup[Bearbeiten | Quelltext bearbeiten]
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.