Das DNS ist ein weltweit auf Tausenden von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in sogenannte Zonen unterteilt, für die jeweils unabhängige Administratoren zuständig sind. Für lokale Anforderungen – etwa innerhalb eines Firmennetzes – ist es auch möglich, ein vom Internet unabhängiges DNS zu betreiben.
Hauptsächlich wird das DNS zur Umsetzung von Domainnamen in IP-Adressen (forward lookup) benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenketten. So kann man sich einen Domainnamen wie example.org in der Regel leichter merken als die dazugehörende IP-Adresse 192.0.32.10. Dieser Punkt gewinnt im Zuge der Einführung von IPv6 noch mehr an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet. So löst sich beispielsweise der Name www.kame.net in die IPv4-Adresse 203.178.141.194 und die IPv6-Adresse 2001:200:dff:fff1:216:3eff:feb1:44d7 auf.
Ein weiterer Vorteil ist, dass IP-Adressen – etwa von Web-Servern – relativ risikolos geändert werden können. Da Internetteilnehmer nur den (unveränderten) DNS-Namen ansprechen, bleiben ihnen Änderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden können, kann sogar eine einfache Lastverteilung per DNS (Load Balancing) realisiert werden.
Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (reverse lookup) möglich. In Analogie zum Telefonbuch entspricht dies einer Suche nach dem Namen eines Teilnehmers zu einer bekannten Rufnummer, was innerhalb der Telekommunikationsbranche unter dem Namen Inverssuche bekannt ist.
Das DNS wurde 1983 von Paul Mockapetris entworfen und in RFC 882 und RFC 883 (RFC = Request for Comments) beschrieben. Beide wurden inzwischen von RFC 1034 und RFC 1035 abgelöst und durch zahlreiche weitere Standards ergänzt. Ursprüngliche Aufgabe war es, die lokalen hosts-Dateien abzulösen, die bis dahin für die Namensauflösung zuständig waren und der enorm zunehmenden Zahl von Neueinträgen nicht mehr gewachsen waren. Aufgrund der erwiesenermaßen hohen Zuverlässigkeit und Flexibilität wurden nach und nach weitere Datenbestände in das DNS integriert und so den Internetnutzern zur Verfügung gestellt (siehe unten: Erweiterung des DNS).
DNS zeichnet sich aus durch:
- dezentrale Verwaltung
- hierarchische Strukturierung des Namensraums in Baumform
- Eindeutigkeit der Namen
- Erweiterbarkeit
Nameserver
Ein Nameserver ist ein Server, der Namensauflösung anbietet. Namensauflösung ist das Verfahren, das es ermöglicht, Namen von Rechnern bzw. Diensten in eine vom Computer bearbeitbare Adresse aufzulösen (z. B. www.wikipedia.org in 91.198.174.192).
Die meisten Nameserver sind Teil des Domain Systems, das auch im Internet benutzt wird.
Nameserver sind zum einen Programme, die auf Basis einer DNS-Datenbank Anfragen zum Domain-Namensraum beantworten, im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme zum Einsatz kommen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.
Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per Zonentransfer.
Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS-Daten normalerweise nur sehr selten ändern, speichern nicht-autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen RAM ab, damit diese bei einer erneuten Anfrage schneller vorliegen. Diese Technik wird als Caching bezeichnet. Jeder dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das kann unter Umständen bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefert, wenn sich die Daten zwischenzeitlich geändert haben.
Ein Spezialfall ist der Caching Only Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich und muss alle eintreffenden Anfragen über weitere Nameserver (Forwarder) auflösen. Dafür stehen verschiedene Strategien zur Verfügung:
- Zusammenarbeit der einzelnen Nameserver
Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien:
- Delegierung
- Teile des Namensraumes einer Domain werden oft an Subdomains mit dann eigens zuständigen Nameservern ausgelagert. Ein Nameserver einer Domäne kennt die zuständigen Nameserver für diese Subdomains aus seiner Zonendatei und delegiert Anfragen zu diesem untergeordneten Namensraum an einen dieser Nameserver.
- Weiterleitung (forwarding)
- Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.
- Auflösung über die Root-Nameserver
- Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Nameserver befragt. Dazu werden in Form einer statischen Datei die Namen und IP-Adressen der Root-Server hinterlegt. Es gibt 13 Root-Server (Server A bis M). Die Root-Server beantworten ausschließlich iterative Anfragen. Sie wären sonst mit der Anzahl der Anfragen schlicht überlastet.
Anders konzipierte Namensauflösungen durch Server, wie der NetWare Name Service oder der Windows Internet Naming Service, sind meistens auf Local Area Networks beschränkt und werden zunehmend von der Internetprotokollfamilie verdrängt.
Resolver
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 entweder eine positive Antwort oder bis er von einem autoritativen Server eine negative Antwort erhält. 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.
Protokoll
DNS-Anfragen werden normalerweise per UDP Port 53 zum Namensserver gesendet. Der DNS-Standard fordert aber auch die Unterstützung von TCP für Fragen, deren Antworten zu groß für UDP-Übertragungen sind.[1] Falls kein Extended DNS verwendet wird (EDNS), beträgt die maximal zulässige Länge des DNS-UDP-Pakets 512 Bytes. Überlange Antworten werden daher abgeschnitten übertragen. Durch Setzen des Truncated-Flags wird der anfragende Client über diesen Sachverhalt informiert. Er muss dann entscheiden, ob ihm die Antwort reicht oder nicht. Gegebenenfalls wird er die Anfrage per TCP Port 53 wiederholen.
Zonentransfers werden stets über Port 53 TCP durchgeführt. Die Auslösung von Zonentransfers erfolgt aber gewöhnlich per UDP.
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,[2] 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.