[宁夏新闻]撸起袖子加油干 中卫：今年计划实施...
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.