DNS: Unterschied zwischen den Versionen

Aus Zebradem WIKI
Zur Navigation springenZur Suche springen
VisuellWikitext
Die Seite wurde neu angelegt: „{| class="wikitable float-right" |----- ! bgcolor="#ffC0FF" colspan="2" font="size:larger" | Domain Name System (DNS) |----- | align="left" | '''Familie:''' | …“
 
 
(14 dazwischenliegende Versionen derselben Benutzerin werden nicht angezeigt)
Zeile 1: Zeile 1:
{| class="wikitable float-right"
<div style="margin: 0; margin-top:10px; margin-right:10px; border: 1px solid #333333; padding: 0em 1em 1em 1em; background-color:#1B1C2D; align:right;">
|-----
<br><center>[[Datei:ZD-Logo.png]]</center>
! bgcolor="#ffC0FF" colspan="2" font="size:larger" | Domain Name System (DNS)
<center><big><span style="color:#B5B5B5;">'''''Das Board mit Freiheiten'''''</span></big></center>
|-----
<font color=white></font>
| align="left" | '''Familie:'''
----
| align="left" | [[Internetprotokollfamilie]]
<br>
|-----
<div style="margin: 0px 20px 15pt 15pt; border: 2px solid rgb(223, 223, 223); padding: 0em 1em 1em; background-color:#303140; border: 1px solid #000000;">
| align="left" | '''Einsatzgebiet:'''
<br/>
| align="left" | [[Namensauflösung]]
|-----
| '''Ports:''' || 53/UDP, 53/TCP
|-----
| align="center" colspan="2" |
{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll|DNS|}}
|-----
| align="left" | '''Standards:'''
| align="left" |
RFC 1034 (1987)<br /><hr>
RFC 1035 (1987)
|}


Das '''Domain Name System''' ('''DNS''') ist einer der wichtigsten Dienste im [[Netzwerk]]. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur [[Namensauflösung]].


In Analogie zu einer Telefonauskunft soll das DNS bei Anfrage mit einem [[Hostname]]n (dem für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel <tt>www.example.org</tt> – als Antwort die zugehörige [[IP-Adresse]] (die „Anschlussnummer“ im Internet) – zum Beispiel eine [[IPv4]]-Adresse der Form <tt>192.0.2.42</tt> oder eine [[IPv6]]-Adresse wie <tt>2001:db8:85a3:8d3:1319:8a2e:370:7347</tt> – nennen.


== Überblick ==
Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Netzwerk. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung.
Das DNS ist ein weltweit auf tausende von [[Server]]n verteilter hierarchischer [[Verzeichnisdienst]], der den [[Namensraum]] des Internets verwaltet. Dieser Namensraum ist in so genannte [[Zone (DNS)|Zonen]] unterteilt, für die jeweils unabhängige Administratoren zuständig sind. Für lokale Anforderungen –&nbsp;etwa innerhalb eines Firmennetzes&nbsp;– ist es auch möglich, ein vom Internet unabhängiges DNS zu betreiben.
In Analogie zu einer Telefonauskunft soll das DNS bei Anfrage mit einem Hostnamen (dem für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel www.example.org – als Antwort die zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) – zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 – nennen.


Hauptsächlich wird das DNS zur Umsetzung von [[Domain]]namen in IP-Adressen (''„{{lang|en|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 Zahlenkolonnen. So kann man sich einen Domainnamen wie ''example.org'' in der Regel leichter merken als die dazugehörende IP-Adresse <tt>192.0.32.10</tt>. Dieser Punkt gewinnt im Zuge der Einführung von [[IPv6]] noch 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 <tt>203.178.141.194</tt> und die IPv6-Adresse <tt>2001:200:0:8002:203:47ff:fea5:3085</tt> auf.
Ein weiterer Vorteil ist, dass IP-Adressen –&nbsp;etwa von Web-Servern&nbsp;– 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]] (''{{lang|en|Load Balancing}}'') realisiert werden.
Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (''„[[Reverse DNS|{{lang|en|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 [[Request for Comments|RFC]] 882 und 883 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 die 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|Erweiterung des DNS]]).


== Überblick ==
Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte 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 Zahlenkolonnen. 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 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:0:8002:203:47ff:fea5:3085 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 883 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 die 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:
DNS zeichnet sich aus durch:
* dezentrale Verwaltung,
*dezentrale Verwaltung,
* hierarchische Strukturierung des Namensraums in Baumform,
*hierarchische Strukturierung des Namensraums in Baumform,
* Eindeutigkeit der Namen,
*Eindeutigkeit der Namen,
* Erweiterbarkeit.
*Erweiterbarkeit.


== Komponenten des DNS ==
== Komponenten des DNS ==
=== Domain-Namensraum ===
=== Domain-Namensraum ===
[[Datei:Dns-raum.svg|miniatur|schematische Darstellung der DNS-Hierarchie]]
[[Datei:Dns-raum.svg.png|miniatur|schematische Darstellung der DNS-Hierarchie]]
Der Domain-Namensraum hat eine baumförmige Struktur. Die [[Blatt (Graphentheorie)|Blätter]] und [[Knoten (Graphentheorie)|Knoten]] des Baumes werden als Labels bezeichnet. Ein kompletter [[Domain]]name eines Objektes besteht aus der Verkettung aller Labels eines Pfades.
 
Label sind Zeichenketten ([[Alphanumerische Zeichen|alphanumerisch]], als einziges Sonderzeichen ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind, mit einem Buchstaben oder einer Zahl beginnen müssen und nicht mit '-' enden dürfen (RFC 1035, Abschnitt „2.3.1. Preferred name syntax“). Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Somit lautet ein korrekter, vollständiger Domainname (auch [[Fully Qualified Domain Name|{{lang|en|Fully Qualified Domain-Name}} (FQDN)]] genannt) zum Beispiel <code>www.example.com.</code> <!-- sic! siehe [[Fully Qualified Domain-Name]] --> und darf inklusive aller Punkte maximal 255 Zeichen lang sein.
 
Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (engl. ''{{lang|en|root}}'').
Diese erste Ebene wird auch als [[Top-Level-Domain]] (TLD) bezeichnet.
Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von [[Resource Record]]s meist in einer [[Zonendatei]] gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist. Anstelle von ''Zonendatei'' wird meist der etwas allgemeinere Ausdruck [[Zone (DNS)|Zone]] verwendet.


=== Nameserver ===
Der Domain-Namensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels eines Pfades.
Ein '''Nameserver''' ist ein [[Server (Software)|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 (von bspw. ''www.wikipedia.org'' in ''145.97.39.155'').
Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind, mit einem Buchstaben oder einer Zahl beginnen müssen und nicht mit '-' enden dürfen (RFC 1035, Abschnitt „2.3.1. Preferred name syntax“). Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Somit lautet ein korrekter, vollständiger Domainname (auch Fully Qualified Domain-Name (FQDN) genannt) zum Beispiel www.example.com. und darf inklusive aller Punkte maximal 255 Zeichen lang sein.
 
Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (engl. root). Diese erste Ebene wird auch als Top-Level-Domain (TLD) bezeichnet. Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist. Anstelle von Zonendatei wird meist der etwas allgemeinere Ausdruck Zone verwendet.
Die meisten Nameserver sind Teil des Domain Name System, das auch im [[Internet]] benutzt wird.


===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 (von bspw. www.wikipedia.org in 145.97.39.155).
Die meisten Nameserver sind Teil des Domain Name System, das auch im Internet benutzt wird.
Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten, im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.
Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten, im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, 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 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]]-[[Computercluster|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 aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefern kann, wenn sich die Daten zwischenzeitlich geändert haben.
 
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 [[Halbleiterspeicher#Random Access Memory (RAM)|RAM]] ab, damit diese bei einer erneuten Anfrage schneller vorliegen. Diese Technik wird als [[DNS-Caching|Caching]] bezeichnet. Jeder dieser Einträge besitzt ein eigenes Verfallsdatum ([[Time to live|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 aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefern kann, 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:
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
;Zusammenarbeit der einzelnen Nameserver
Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien:
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-Server
Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Server 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.


;Delegierung
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.
:Teile des Namensraumes einer [[Domain]] werden oft an [[Domain|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 [[DNS Root Nameserver|Root-Server]]
:Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Server 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 [[Rekursive und iterative Namensauflösung|iterative]] Anfragen. Sie wären sonst mit der Anzahl der Anfragen schlicht überlastet.
 
Anders konzipierte Namensauflösungen durch Server, wie der [[NetWare|NetWare Name Service]] oder der [[Windows Internet Naming Service]], sind meistens auf [[Local Area Network]]s beschränkt und werden zunehmend von der [[Internetprotokollfamilie]] verdrängt.
 
=== Resolver ===
[[Datei:Dns-abfrage.svg|miniatur|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 [[Fully Qualified Domain Name|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 (Programmierung)|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 (Programm)|host]]'' und [[Dig (Programm)|dig]]. Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter [[rekursive und iterative Namensauflösung]].
===Resolver===
[[Datei:Dns-abfrage.svg.png|miniatur|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 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. Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive und iterative Namensauflösung.


=== Protokoll ===
===Protokoll===
DNS-Anfragen werden normalerweise per [[User Datagram Protocol|UDP]] [[Port (Protokoll)|Port]] 53 zum Namensserver gesendet. Der DNS-Standard erlaubt aber auch [[Transmission Control Protocol|TCP]]. Falls kein Extended DNS verwendet wird ([[EDNS]]), beträgt die maximal zulässige Länge des DNS-UDP-Pakets 512 [[Byte]]s. Ü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.


DNS-Anfragen werden normalerweise per UDP Port 53 zum Namensserver gesendet. Der DNS-Standard erlaubt aber auch TCP. 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.
Zonentransfers werden stets über Port 53 TCP durchgeführt. Die Auslösung von Zonentransfers erfolgt aber gewöhnlich per UDP.


== Aufbau der DNS-Datenbank ==
== Aufbau der DNS-Datenbank ==
Das Domain Name System kann als verteilte [[Datenbanksystem|Datenbank]] mit baumförmiger Struktur aufgefasst werden. Beim Internet-DNS liegen die Daten auf einer Vielzahl von weltweit verstreuten Servern, die untereinander über Verweise – in der DNS-Terminologie ''Delegierungen'' genannt – verknüpft sind.
Das Domain Name System kann als verteilte Datenbank mit baumförmiger Struktur aufgefasst werden. Beim Internet-DNS liegen die Daten auf einer Vielzahl von weltweit verstreuten Servern, die untereinander über Verweise – in der DNS-Terminologie ''Delegierungen'' genannt – verknüpft sind.


In jedem beteiligten Nameserver existieren eine oder mehrere Dateien – die so genannten [[Zone (DNS)|Zonendateien]] – die alle relevanten Daten enthalten. Bei diesen Dateien handelt es sich um Listen von ''[[Resource Record]]s''. Von großer Bedeutung sind sieben Record-Typen:
In jedem beteiligten Nameserver existieren eine oder mehrere Dateien – die so genannten (DNS)|Zonendateien – die alle relevanten Daten enthalten. Bei diesen Dateien handelt es sich um Listen von ''Resource Records''. Von großer Bedeutung sind sieben Record-Typen:


* Mit dem ''[[SOA Resource Record]]'' werden Parameter der [[Zone (DNS)|Zone]], wie z.&nbsp;B. Gültigkeitsdauer oder Seriennummer, festgelegt.
* Mit dem ''SOA Resource Record'' werden Parameter der (DNS)|Zone, wie z.&nbsp;B. Gültigkeitsdauer oder Seriennummer, festgelegt.
* Mit dem ''[[NS Resource Record]]'' werden die Verknüpfungen (''Delegierungen'') der Server untereinander realisiert.
* Mit dem ''NS Resource Record'' werden die Verknüpfungen (''Delegierungen'') der Server untereinander realisiert.
* Mit folgenden Record-Typen werden die eigentlichen Daten definiert:
* Mit folgenden Record-Typen werden die eigentlichen Daten definiert:
** Ein ''[[A Resource Record]]'' weist einem Namen eine [[IPv4]]-Adresse zu.
** Ein ''A Resource Record'' weist einem Namen eine IPv4-Adresse zu.
** Ein ''[[AAAA Resource Record]]'' weist einem Namen eine [[IPv6]]-Adresse zu.
** Ein ''AAAA Resource Record'' weist einem Namen eine IPv6-Adresse zu.
** Ein ''[[CNAME Resource Record]]'' verweist von einem Namen auf einen anderen Namen.
** Ein ''CNAME Resource Record'' verweist von einem Namen auf einen anderen Namen.
** Ein ''[[MX Resource Record]]'' weist einem Namen einen [[Mailserver]] zu. Er stellt eine Besonderheit dar, da er sich auf einen speziellen [[Internetdienste|Dienst]] im Internet, nämlich die E-Mailzustellung mittels [[Simple Mail Transfer Protocol|SMTP]] bezieht. Alle anderen Dienste nutzen ''CNAME'', ''A'' und ''AAAA Resource Records'' für die Namensauflösung.
** Ein ''MX Resource Record'' weist einem Namen einen Mailserver zu. Er stellt eine Besonderheit dar, da er sich auf einen speziellen Dienst im Internet, nämlich die E-Mailzustellung mittels SMTP bezieht. Alle anderen Dienste nutzen ''CNAME'', ''A'' und ''AAAA Resource Records'' für die Namensauflösung.
** Ein ''[[PTR Resource Record]]'' weist einer IP-Adresse einen Namen zu (''Reverse Lookup'') und wird für IPv4 und IPv6 gleichermaßen benutzt, nur für IPv4 unterhalb der Domain „''IN-ADDR.ARPA.''“ und für IPv6 unterhalb von „''IP6.ARPA.''“.
** Ein ''PTR Resource Record'' weist einer IP-Adresse einen Namen zu (''Reverse Lookup'') und wird für IPv4 und IPv6 gleichermaßen benutzt, nur für IPv4 unterhalb der Domain „''IN-ADDR.ARPA.''“ und für IPv6 unterhalb von „''IP6.ARPA.''“.


Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Dieser Prozess ist noch nicht abgeschlossen. Eine umfassende Liste findet sich unter ''[[Resource Record]]''.
Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Dieser Prozess ist noch nicht abgeschlossen. Eine umfassende Liste findet sich unter ''Resource Record''.


Beispiele:
Beispiele:


Folgender ''NS Resource Record'' ist in der Zonendatei der Domain „''org.''“ definiert: Die Zonendatei für die Domain „''wikipedia.org.''“ befindet sich auf dem Server „''ns0.wikimedia.org.''“. Der Punkt am Ende ist wichtig, da dieser klarstellt, dass kein relativer Name gemeint ist, also hinter „''org''“ nichts mehr zu ergänzen ist. „''IN''“ meint, dass der Eintrag die Klasse „Internet“ besitzt und die Zahl davor bedeutet die ''Time To Live (TTL)'' in Sekunden, sie besagt, wie lange diese Information in einem [[Cache]] zwischengespeichert werden könnte, bevor sie neu erfragt werden sollte. Bei dynamischen IP-Adressen liegt diese Zahl meistens zwischen 20 und 300 Sekunden.
Folgender ''NS Resource Record'' ist in der Zonendatei der Domain „''org.''“ definiert: Die Zonendatei für die Domain „''wikipedia.org.''“ befindet sich auf dem Server „''ns0.wikimedia.org.''“. Der Punkt am Ende ist wichtig, da dieser klarstellt, dass kein relativer Name gemeint ist, also hinter „''org''“ nichts mehr zu ergänzen ist. „''IN''“ meint, dass der Eintrag die Klasse „Internet“ besitzt und die Zahl davor bedeutet die ''Time To Live (TTL)'' in Sekunden, sie besagt, wie lange diese Information in einem Cache zwischengespeichert werden könnte, bevor sie neu erfragt werden sollte. Bei dynamischen IP-Adressen liegt diese Zahl meistens zwischen 20 und 300 Sekunden.
  wikipedia  86400  IN  NS  ns0.wikimedia.org.
  wikipedia  86400  IN  NS  ns0.wikimedia.org.


Zeile 125: Zeile 96:


== Auflösung eines DNS-Requests ==
== Auflösung eines DNS-Requests ==
[[Datei:DNS-query-to-wikipedia.svg|miniatur|Die Namensauflösung als [[Programmablaufplan|Flussdiagramm]]]]
[[Datei:DNS-query-to-wikipedia.svg.png|right| Flussdiagramm]]
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 3484 die Kommunikation zwischen ''X'' und ''Y'' über IPv6 bevorzugt<ref>
 
  {{cite web
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 3484 die Kommunikation zwischen ''X'' und ''Y'' über IPv6 bevorzugt, es sei denn im [[Betriebssystem]] oder in den benutzten Anwendungen, wie zum Beispiel dem Webbrowser, wurde dieses Verhalten anders eingestellt.
    | url = http://tools.ietf.org/html/rfc3484#page-6
 
    | title = RFC 3484 – Default Address Selection for Internet Protocol version 6 (IPv6)
 
    | publisher = Network Working Group of the IETF
 
    | author = R. Draves
 
    | page = 6
    | quote = Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available.
    | accessdate=2010-12-21
  }}
</ref>, 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 [[Dynamic Host Configuration Protocol|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 Record]]s'' und deren ''[[AAAA Resource Record|AAAA]]'' bzw. ''[[A Resource Record]]s'') zum DNS-Server von Rechner ''X''.
 
 
 
# 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.''“.
# 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.''“.
# 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.
# 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&nbsp;…
# Mit dieser Adresse wird an den DNS-Server von Rechner ''X'' geantwortet und der&nbsp;…
# … sendet sie an den Rechner ''X'', welcher nun zum Beispiel seine [[Hypertext Transfer Protocol|HTTP]]-Anfragen an die IP-Adresse von „''de.wikipedia.org.''“ senden kann.
# … 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 ===
=== Beispiel Namensauflösung ===
Im folgenden, kommentierten Beispiel wird zum Namen „''www.heise.de.''“ die IPv4-Adresse mit Hilfe des Resolver-Tools [[Dig (Programm)|dig]] bestimmt. „<tt>+trace</tt>“ bedeutet, dass die einzelnen Antworten auf iterative Anfragen an die Nameserver-Hierarchie angegeben werden, „<tt>+additional</tt>“ 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, „<tt>-t A</tt>“ 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:
Im folgenden, kommentierten Beispiel wird zum Namen „''www.heise.de.''“ die IPv4-Adresse mit Hilfe des Resolver-Tools dig bestimmt. „<tt>+trace</tt>“ bedeutet, dass die einzelnen Antworten auf iterative Anfragen an die Nameserver-Hierarchie angegeben werden, „<tt>+additional</tt>“ 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, „<tt>-t A</tt>“ 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 +trace +additional -t A www.heise.de.
Zeile 183: Zeile 154:
  ;; Received 500 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms
  ;; Received 500 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms


<tt>192.168.2.1</tt> (siehe letzte Zeile) ist der eingetragene Nameserver des abfragenden Rechners, welcher auf die [[Root-Nameserver]] verweist, die die TLD-Zone (Zone, die die Nameserver für .org, .de, .com, … enthält) verwalten und alle weiter via IPv4 befragt werden können, einige zusätzlich auch mittels IPv6. Die Root-Nameserver verwalten die Wurzel 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.)
<tt>192.168.2.1</tt> (siehe letzte Zeile) ist der eingetragene Nameserver des abfragenden Rechners, welcher auf die Root-Nameserver verweist, die die TLD-Zone (Zone, die die Nameserver für .org, .de, .com, … enthält) verwalten und alle weiter via IPv4 befragt werden können, einige zusätzlich auch mittels IPv6. Die Root-Nameserver verwalten die Wurzel 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      F.NIC.de.
Zeile 230: Zeile 201:


=== Beispiel Reverse Lookup ===
=== 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 <tt>193.99.144.85</tt> wird z.&nbsp;B. der Name „<tt>85.144.99.193.in-addr.arpa.</tt>“ sowie aus der IPv6-Adresse <tt>2a02:2e0:3fe:100::6</tt> der Name „<tt>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.</tt>“ erzeugt. (Dieser Name ist lang, da die implizit enthaltenen Nullen nun wieder explizit genannt werden müssen.)
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 <tt>193.99.144.85</tt> wird z.&nbsp;B. der Name „<tt>85.144.99.193.in-addr.arpa.</tt>“ sowie aus der IPv6-Adresse <tt>2a02:2e0:3fe:100::6</tt> der Name „<tt>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.</tt>“ 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:
Der ''PTR Resource Record'' für die so umgeformte IPv4-Adresse lässt sich analog zum vorigen Beispiel bestimmen:
Zeile 295: Zeile 266:
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.
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.


== Erweiterung des DNS ==
==DNS Serverliste==
Da sich das DNS als zuverlässig und flexibel erwiesen hat, wurden im Laufe der Jahre mehrere größere Erweiterungen eingeführt. Ein Ende dieses Trends ist nicht absehbar.
http://www.stanar.de/
 
=== Dynamisches DNS ===
Im klassischen DNS ist es aufwendig, einem Namen eine neue IP-Adresse zuzuordnen. Das zugehörige Zonenfile muss (meist manuell) geändert und der Nameserver neu geladen werden. Zeitliche Verzögerungen bis hin zu mehreren Tagen sind üblich. Mit [[DynDNS|Dynamischem DNS]] sind Änderungen durch Senden eines entsprechenden [[DNS UPDATE|DNS-Requests]] ohne Zeitverzug möglich.
 
Das Dynamische DNS gilt als Sicherheitsrisiko, da ohne spezielle Vorkehrungen jedermann DNS-Einträge löschen oder verändern kann. In Zusammenhang mit [[Dynamic Host Configuration Protocol|DHCP]] ist Dynamisches DNS nahezu zwingend erforderlich, da einem User häufig neue IP-Adressen zugewiesen werden. Der DHCP-Server sendet dazu bei jeder Adressänderung eine entsprechende Mitteilung an den Nameserver.
 
=== Internationalisierung ===
Bisher waren die Label –&nbsp;wie beschrieben&nbsp;– auf [[alphanumerische Zeichen]] und das Zeichen ‚-‘ eingeschränkt. Dies hängt vor allem damit zusammen, dass das DNS (wie auch das Internet ursprünglich) in den [[Vereinigte Staaten|USA]] entwickelt wurde.
Damit waren in vielen Ländern gebräuchliche [[Schriftzeichen]] (im deutschen Sprachraum zum Beispiel die [[Umlaut]]e ä, ö, ü und ß) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch) ursprünglich nicht DNS-fähig.
 
Ein mittlerweile etablierter Ansatz zur Vergrößerung des Zeichenvorrats ist die 2003 in RFC 3490 beschriebene Internationalisierung von Domain-Namen [[Internationalizing Domain Names in Applications|IDNA]]. Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit zulässigen Zeichen kodiert, also auf derzeit gültige Namen abgebildet. Die erweiterten Zeichensätze werden dabei zunächst gemäß dem [[Nameprep]]-Algorithmus (RFC 3491) normalisiert und anschließend per [[Punycode]] (RFC 3492) auf den für DNS verwendbaren Zeichensatz abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (z.&nbsp;B. Web-Browser), die Nameserver-Infrastruktur (Server, Resolver) braucht jedoch nicht verändert zu werden. Im deutschsprachigen Raum können seit März 2004 deutsche, liechtensteinische, österreichische und schweizerische Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Auch bei einigen anderen [[Top-Level-Domain]]s, insbesondere im asiatischen Raum, ist die Verwendung von IDNA möglich.
 
=== Extended DNS ===
1999 beschrieb [[Paul Vixie]] im RFC 2671 einige kleinere, abwärtskompatible Erweiterungen am Domain Name System, die als [[EDNS]] Version 0 bezeichnet werden. Durch Verwendung von bis dahin reservierten, aber ungenutzten Header-Codes, kann der Anfragende festlegen, dass er UDP-Antworten größer als 512 Bytes entgegennehmen kann. Außerdem wurde es möglich andere Label-Typen zu nutzen. [[DNSSEC]]-fähige Server und Resolver müssen EDNS beherrschen.
 
=== Verwaltung von Telefonnummern ===
Eine weitere aktuelle Erweiterung des DNS stellt [[Telephone Number Mapping|ENUM]] (RFC 2916) dar. Diese Anwendung ermöglicht die Adressierung von [[Internet]]-Diensten über Telefonnummern, also das „Anwählen“ von per Internet erreichbaren Geräten mit dem aus dem Telefonnetz bekannten Nummerierungsschema.
Aus dem breiten Spektrum der Einsatzmöglichkeiten bietet sich insbesondere die Verwendung für [[Voice over IP]] Services an.
 
=== RFID-Unterstützung ===
Mit der [[Radio Frequency Identification]] können auf speziellen RFID-Etiketten abgelegte [[Identifikator|IDs]] – so genannte [[Elektronischer Produktcode|elektronische Produktcodes]] oder EPCs – berührungslos gelesen werden. Das DNS kann dazu verwendet werden, zu einer ID den Server zu ermitteln, der Daten über das zugehörige Objekt enthält. Der [[Object Naming Service]] ONS wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer NAPTR.
 
=== Spam-Abwehr ===
Zur Filterung von [[Spam]]-Mails überprüfen viele [[Mailserver]] routinemäßig mit Hilfe des DNS die Absenderadressen eingehender Mails. Als erster Schritt wird dabei der [[MX Resource Record|MX Record]] ermittelt. Aus der so erhaltenen IP-Adresse wird per [[Reverse DNS|reverse Lookup]] ein Name erfragt. Dieser muss mit dem ursprünglichen Absendernamen identisch sein ([[Forward-confirmed reverse DNS]]), sonst wird die Mail verworfen. Ein Spammer ist dann nicht mehr in der Lage, beliebige Absenderadressen zu erfinden, sondern muss auf registrierte Domainnamen zurückgreifen.
 
Mittels [[Sender Policy Framework]] kann wesentlich wirkungsvoller verifiziert werden, dass ein Absendername gültig ist. Zu jeder Mail-Domain wird dabei über einen speziellen [[SPF Resource Record]] explizit aufgelistet, wer aus dieser Domain heraus Mails versenden darf (im Idealfall nur ein einziger Server).
 
=== Sonstiges ===
Neben den IP-Adressen können DNS-Namen auch [[Integrated Services Digital Network|ISDN]]-Nummern, [[X.25]]-Adressen, [[Asynchronous Transfer Mode|ATM]]-Adressen, [[Öffentlicher Schlüssel|öffentliche Schlüssel]], Text-Zeilen usw. zugeordnet werden. In der Praxis sind derartige Anwendungsfälle aber die Ausnahme.
 
== DNS im lokalen Netz ==
DNS ist nicht auf das Internet beschränkt. Es ist ohne weiteres möglich und mit der Definition verträglich, für die Auflösung lokaler Namen eigene Zonen im Nameserver einzurichten und dort die entsprechenden Adressen einzutragen. Der einmalige Aufwand zur Installation lohnt sich auch bei relativ kleinen Netzen, da dann alle Adressen im Netz zentral verwaltet werden können.
 
Bei größeren Firmen oder Organisationen ist häufig ein aus lokalem und Internet-DNS bestehendes Mischsystem (Split-DNS) anzutreffen. Die internen Nutzer greifen auf das lokale und die externen auf das Internet-DNS zu. In der Praxis können dadurch sehr komplizierte Konstellationen entstehen.
 
Der DNS-Server [[BIND]] kann auch mit [[Dynamic Host Configuration Protocol|DHCP]] zusammenarbeiten und damit für jeden Client im Netz eine Namensauflösung ermöglichen.
 
Unter Windows gibt es noch einen anderen Dienst zur Namensauflösung – [[Windows Internet Naming Service|WINS]], der eine ähnliche Funktion zur Verfügung stellt, allerdings ein anderes Protokoll verwendet.
 
== DNS-Serververbund ==
Es ist möglich, mehrere DNS-Server zu verbinden. Die als Master bezeichneten Server sind für eine oder mehrere Domains verantwortlich. Die Slaves aktualisieren nach einer Änderung selbst die Daten, der Master verteilt diese Daten nicht automatisiert. Die Abholung der Daten wird über einen [[Zonentransfer]] realisiert.
Z.B. kann eine Firma mit mehreren Standorten an einem Platz einen Master für ihr internes DNS betreiben, der die Server in den Außenstellen versorgt. Der Zonentransfer geht bei BIND über TCP (per Default Port 53) und erfordert empfohlenerweise Authentifizierung. Die Slaves aktualisieren sich, wenn sich die Seriennummer für eine Zonendatei ändert oder sie eine entsprechende Nachricht vom Master erhalten. Die Freigabe für den Transferport sollte man per Firewall an die IP-Adresse des Masters binden. Bei anderen Softwarepaketen werden die Daten unter Umständen auf anderen Wegen abgeglichen, beispielsweise durch LDAP-Replikation, rsync, oder noch andere Mechanismen.
 
== DNS-Sicherheit ==
Das DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur. Eine Störung kann erhebliche Kosten nach sich ziehen und eine Verfälschung von DNS-Daten Ausgangspunkt von Angriffen sein. Mehr als zehn Jahre nach der ursprünglichen Spezifikation wurde DNS um Security-Funktionen ergänzt. Folgende Verfahren sind verfügbar:
 
* Bei [[TSIG]] (Transaction Signatures) handelt es sich um ein einfaches, auf [[Symmetrisches Kryptosystem|symmetrischen Schlüsseln]] beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern und [[Aktualisierung|Updates]] von [[Client]]s gesichert werden kann.
* Bei [[DNSSEC]] (DNS Security) wird von einem [[Asymmetrisches Kryptosystem|asymmetrischen Kryptosystem]] Gebrauch gemacht, mit dem nahezu alle DNS-Sicherheitsanforderungen erfüllt werden können. Neben der Server-Server-Kommunikation kann auch die Client-Server-Kommunikation gesichert werden.
 
=== Angriffsformen ===
Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw. zu erhalten. In seltenen Fällen wird versucht, den Internet-DNS durch [[Denial of Service|Denial-of-Service]]-Attacken komplett auszuschalten und so das Internet lahmzulegen. Außerdem kann das DNS dazu verwendet werden, gezielte Angriffe auf Einzelpersonen oder Unternehmen zu intensivieren.
 
==== DDOS-Angriff auf Nameserver ====
Bei einer [[Distributed Denial of Service|Distributed-Denial-of-Service]]-Attacke werden Nameserver durch einen hohen Datenstrom von DNS-Anfragen überlastet, so dass legitime Anfragen nicht mehr beantwortet werden können. Gegen DDOS-Angriffe auf Nameserver gibt es zur Zeit keine Abwehrmöglichkeit. Als vorbeugende Maßnahme kann lediglich versucht werden, die Nameserver entsprechend zu dimensionieren bzw. ein verteiltes Netz mit möglichst vielen Servern zu installieren.
Solch eine Attacke ist jedoch aufwändig, denn man muss mindestens eine so leistungsschnelle Leitung besitzen wie der Server selbst, was also schwer realisierbar ist. [[Botnet]]ze und dergleichen werden bei solchen Attacken häufig eingesetzt.
 
==== DNS-Amplification-Angriff ====
Der [[DNS Amplification Attack]] ist ein [[Denial of Service|Denial-of-Service]]-Angriff, bei dem nicht der DNS selbst das eigentliche Angriffsziel ist, sondern ein unbeteiligter Dritter. Ausgenutzt wird, dass DNS-Server in manchen Fällen auf kurze Anfragen sehr lange Antworten zurücksenden. Diese werden auf die IP-Adresse des Opfers gelenkt. Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substantiell verstärken und so den Internet-Zugang seines Angriffziels stören.
 
==== DNS-Spoofing ====
Beim [[DNS-Spoofing]] wird einem anfragenden Client eine Antwort mit einer falschen Absender-IP-Adresse untergeschoben, so dass dieser auf eine falsche Web-Seite gelenkt wird.
 
==== Cache Poisoning ====
Beim [[Cache Poisoning]] werden einem anfragenden Client zusätzlich zur korrekten Antwort manipulierte Daten übermittelt, die dieser in seinen Cache übernimmt und später, möglicherweise ungeprüft, verwendet.
 
==== Offener DNS-Server ====
Wer einen autoritativen DNS-Server für seine eigenen Domains betreibt, muss natürlich für Anfragen von beliebigen IP-Adressen offen sein. Um zu verhindern, dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden (z.&nbsp;B. für Angriffe auf Root-Server), erlaubt BIND es, die Antworten auf die eigenen Domains einzuschränken. Z.&nbsp;B. bewirkt die Option <code>allow-recursion {127.0.0.1; 172.16.1.4;};</code> , dass rekursive Anfragen, d.&nbsp;h. Anfragen auf andere Domains, ausschließlich für den lokalen Host (localhost) sowie 172.16.1.4 beantwortet werden. Alle anderen IP-Adressen bekommen nur auf Anfragen auf eigene Domains eine Antwort.
 
Eine zusätzliche Sicherheitsmaßnahme ist es, für Input von außen nur UDP zuzulassen.
ICCP DP kann zusätzlich zugelassen werden. Dies variiert jedoch je nach Proxy-Eigenschaften.
 
Ein offener DNS-Server kann auch eine Falle sein, wenn er gefälschte IP-Adressen zurückgibt, siehe [[Pharming (Internet)|Pharming]].
 
=== Spamabwehr ===
Bei [[Realtime Blackhole List|Schwarzen Listen]] (auch 'RBL'; Abkürzung für engl. {{lang|en|Realtime Blackhole Lists}}) z.&nbsp;B. gegen [[Spam]]mer, wird DNS angewendet, um abzufragen, ob ein Domainname oder eine IP-Adresse gelistet ist: Der Client schickt eine DNS-Anfrage an den Rbl-Server. Dieser antwortet mit '127.0.0.1', wenn die Adresse nicht gelistet ist, sonst mit '127.0.0.x', x>1. Der Wert von 'x' kann noch zusätzliche Informationen über die gelistete Adresse enthalten. Da der Bereich 127.0.0.0/8 für [[Localhost]] reserviert ist, sind Missdeutungen nicht möglich.
 
== Domain-Registrierung ==
Um DNS-Namen im Internet bekannt machen zu können, muss der Besitzer die Domain, die diesen Namen enthält, registrieren. Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind. Domain-Registrierungen werden von Organisationen (Registrars) vorgenommen, die dazu von der [[Internet Assigned Numbers Authority|IANA]] bzw. [[Internet Corporation for Assigned Names and Numbers|ICANN]] autorisiert wurden. Registrierungen sind (von wenigen Ausnahmen abgesehen) gebührenpflichtig. Für Domains unter .de ist die [[DENIC]] zuständig.
 
Detaillierte Informationen finden sich unter [[Domain-Registrierung]].
 
== Bonjour bzw. Zeroconf ==
[[Apple]] hat bei der Entwicklung von [[Mac OS X]] mehrere Erweiterungen am DNS vorgenommen, welche die umfassende Selbstkonfiguration von Diensten in LANs ermöglichen soll. Zum einen wurde [[Multicast DNS]] („mDNS“) eingeführt, das die Namensauflösungen in einem [[Local Area Network|LAN]] ohne einen dedizierten Namensserver erlaubt. Zusätzlich wurde noch [[DNS-SD]] (für „DNS Service Discovery“) eingeführt, die die Suche („Browsing“) nach Netzwerkdiensten in das DNS beziehungsweise mDNS ermöglicht. mDNS und DNS-SD sind bisher keine offiziellen [[Request for Comments|RFCs]] des [[Internet Engineering Task Force|IETF]], sind aber trotzdem bereits in verschiedenen (auch freien) Implementationen verfügbar. Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen „[[Zeroconf]]“ zusammen, als Bestandteil von Mac OS X auch als „Rendezvous“ bzw. „[[Bonjour (Apple)|Bonjour]]“.
 
== Nameserversoftware ==
Auswahl bekannter Software für Namensauflösung.
 
* [[BIND]] (Berkeley Internet Name Domain) ist der Ur-Nameserver und heute noch die meistgebrauchte Nameserversoftware, nicht zuletzt da er die Referenzimplementation der meisten [[Request for Comments|RFCs]] zu DNS darstellt. BIND ist [[Open Source|quelloffene]] Software.
* [[djbdns]] gilt als sehr sicher und erfreut sich steigender Beliebtheit, wird aber von [[Daniel J. Bernstein]] nicht mehr weiterentwickelt, weil er es als fertig ansieht.
* [http://www.thekelleys.org.uk/dnsmasq/ Dnsmasq] ist ein einfacher DNS- und DHCP-Server für kleine Netze. Es werden die Namen aus dem lokalen Netz entsprechend /etc/hosts aufgelöst. Unbekannte Namensanfragen werden weitergeleitet und im Cache gespeichert.
* [http://www.maradns.org/ MaraDNS] ist ein Nameserver, bei dem die Entwickler besonderen Wert auf Sicherheit legen.
* Microsoft Windows DNS ist ein in Windows-Servern enthaltener DNS-Server, der dynamische Updates, Zonentransfer und Notification unterstützt. Zonendaten können in den aktuellen Versionen im [[Active Directory Service|Active Directory]] oder in Zonendateien gespeichert und repliziert werden.
* [[MyDNS]] ist eine weitere [[Open Source|quelloffene]] Software, die insbesondere auf [[MySQL]]- und [[PostgreSQL]]-Datenbanken spezialisiert ist.
* NSD ist optimiert für Server die ausschließlich autoritative Antworten besonders schnell liefern sollen.
* [[PowerDNS]] war eine kostenpflichtige [[Implementierung]], die inzwischen unter der [[GNU General Public License|GPL]] erhältlich ist und vor allem für das direkte Betreiben von Zonen aus [[SQL]]-Datenbanken und [[Lightweight Directory Access Protocol|LDAP]]-Verzeichnissen bekannt ist.
* [[UltraDNS]] ist ein kommerzieller managed DNS Service von [[NeuStar]] Ultra Services. Diese Firma bietet auch ein DNSshield an, das DNS in einer Alliance mit verschiedenen ISPs absichert und ist damit spezialisiert auf DNS großer Webseiten. Auch ein Teil der Root-Level-DNS ist hier gesichert. Das Internet Systems Consortium (ISC) sichert den F-Root Server hier ab.
* [[Xyria:DNSd]] ist ein performance-optimierter DNS-Server, der etwa doppelt so schnell ist wie BIND. Xyria:DNSd ist derzeit noch recht minimalistisch und unterstützt keine Zonetransfers (außer etwa via SSH), dafür ist er aber extrem sicher und stabil.
 
 


==DNS Check==
http://www.dnswatch.info/de


== Quellenangaben ==


===Was ist ein DNS Name?==
http://de.wikipedia.org


DNS steht für "Domain Name Service", und ist ein Dienst, der aus lesbaren und einprägsamen Namen wie z.B. geotek.de die zugehörige IP-Adresse 212.202.126.70 ermittelt, mit der Ihr PC und alle Router im Internet etwas anfangen können. Wenn Sie in Ihrem Browser also eine URL wie z.B. www.spiegel.de eingeben, fragt Ihr PC zunächst beim DNS Server Ihres Providers nach der zugeordneten IP-Adresse. Hat dieser DNS Server noch nie etwas von www.spiegel.de gehört, macht er sich seinerseits bei übergeordneten DNS Servern schlau, und sendet Ihrem Browser dann die Antwort. Das alles geht in der Regel so schnell, dass Sie nach der Eingabe einer URL im Browser lediglich eine kurze Verzögerung merken. Der umgekehrte Fall, dass man den einer IP-Adresse zugeordneten Namen sucht, wird Reverse-DNS-Lookup genannt. Wir benutzen diese Reverse-Anfrage, um den unter "DNS Name" aufgeführten Namen herauszufinden. Wenn Sie sich über einen Provider wie T-Online ins Internet einwählen, ist der DNS Name der T-Online-interne Name des Einwahlports mit dem Sie gerade verbunden sind. Gehen Sie von einem Firmennetzwerk aus ins Internet, erscheint in der Regel der Domänenname dieser Firma.
[[#top|<span style="color:#4876FF;">[ nach Oben ]</span>]]<br>
[[Local Area Network (LAN)|<span style="color:#4876FF;">[Zurück zu Netzwerk]</span>]]<br>
[[Hauptseite|<span style="color:#4876FF;">[Zurück zu Hauptseite]</span>]]</div> </div>
[[Category:Sitemap]] [[Category:Netzwerk]]

Aktuelle Version vom 26. Oktober 2011, 22:38 Uhr


Das Board mit Freiheiten




Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Netzwerk. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung. In Analogie zu einer Telefonauskunft soll das DNS bei Anfrage mit einem Hostnamen (dem für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel www.example.org – als Antwort die zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) – zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 – nennen.


Überblick

Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte 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 Zahlenkolonnen. 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 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:0:8002:203:47ff:fea5:3085 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 883 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 die 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.

Komponenten des DNS

Domain-Namensraum

schematische Darstellung der DNS-Hierarchie

Der Domain-Namensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels eines Pfades. Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind, mit einem Buchstaben oder einer Zahl beginnen müssen und nicht mit '-' enden dürfen (RFC 1035, Abschnitt „2.3.1. Preferred name syntax“). Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Somit lautet ein korrekter, vollständiger Domainname (auch Fully Qualified Domain-Name (FQDN) genannt) zum Beispiel www.example.com. und darf inklusive aller Punkte maximal 255 Zeichen lang sein. Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (engl. root). Diese erste Ebene wird auch als Top-Level-Domain (TLD) bezeichnet. Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist. Anstelle von Zonendatei wird meist der etwas allgemeinere Ausdruck Zone verwendet.

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 (von bspw. www.wikipedia.org in 145.97.39.155). Die meisten Nameserver sind Teil des Domain Name System, das auch im Internet benutzt wird. Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten, im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, 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 aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefern kann, 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-Server

Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Server 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

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 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. Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive und iterative Namensauflösung.

Protokoll

DNS-Anfragen werden normalerweise per UDP Port 53 zum Namensserver gesendet. Der DNS-Standard erlaubt aber auch TCP. 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.

Aufbau der DNS-Datenbank

Das Domain Name System kann als verteilte Datenbank mit baumförmiger Struktur aufgefasst werden. Beim Internet-DNS liegen die Daten auf einer Vielzahl von weltweit verstreuten Servern, die untereinander über Verweise – in der DNS-Terminologie Delegierungen genannt – verknüpft sind.

In jedem beteiligten Nameserver existieren eine oder mehrere Dateien – die so genannten (DNS)|Zonendateien – die alle relevanten Daten enthalten. Bei diesen Dateien handelt es sich um Listen von Resource Records. Von großer Bedeutung sind sieben Record-Typen:

  • Mit dem SOA Resource Record werden Parameter der (DNS)|Zone, wie z. B. Gültigkeitsdauer oder Seriennummer, festgelegt.
  • Mit dem NS Resource Record werden die Verknüpfungen (Delegierungen) der Server untereinander realisiert.
  • Mit folgenden Record-Typen werden die eigentlichen Daten definiert:
    • Ein A Resource Record weist einem Namen eine IPv4-Adresse zu.
    • Ein AAAA Resource Record weist einem Namen eine IPv6-Adresse zu.
    • Ein CNAME Resource Record verweist von einem Namen auf einen anderen Namen.
    • Ein MX Resource Record weist einem Namen einen Mailserver zu. Er stellt eine Besonderheit dar, da er sich auf einen speziellen Dienst im Internet, nämlich die E-Mailzustellung mittels SMTP bezieht. Alle anderen Dienste nutzen CNAME, A und AAAA Resource Records für die Namensauflösung.
    • Ein PTR Resource Record weist einer IP-Adresse einen Namen zu (Reverse Lookup) und wird für IPv4 und IPv6 gleichermaßen benutzt, nur für IPv4 unterhalb der Domain „IN-ADDR.ARPA.“ und für IPv6 unterhalb von „IP6.ARPA.“.

Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Dieser Prozess ist noch nicht abgeschlossen. Eine umfassende Liste findet sich unter Resource Record.

Beispiele:

Folgender NS Resource Record ist in der Zonendatei der Domain „org.“ definiert: Die Zonendatei für die Domain „wikipedia.org.“ befindet sich auf dem Server „ns0.wikimedia.org.“. Der Punkt am Ende ist wichtig, da dieser klarstellt, dass kein relativer Name gemeint ist, also hinter „org“ nichts mehr zu ergänzen ist. „IN“ meint, dass der Eintrag die Klasse „Internet“ besitzt und die Zahl davor bedeutet die Time To Live (TTL) in Sekunden, sie besagt, wie lange diese Information in einem Cache zwischengespeichert werden könnte, bevor sie neu erfragt werden sollte. Bei dynamischen IP-Adressen liegt diese Zahl meistens zwischen 20 und 300 Sekunden. 

wikipedia   86400  IN  NS   ns0.wikimedia.org.

Folgender CNAME Resource Record in der Zonendatei der Domain „wikipedia.org.“ definiert: Der Name „de.wikipedia.org.“ verweist auf den Namen „rr.wikimedia.org.“. 

de          3600   IN  CNAME   rr.wikimedia.org.

Folgende Resource Records in der Zonendatei der Domain „wikimedia.org.“ definieren: Der Name „rr.wikimedia.org.“ verweist auf den Namen „rr.esams.wikimedia.org.“ und diesem wiederum ist die IPv4-Adresse 91.198.174.2 zugewiesen. 

rr          600    IN  CNAME   rr.esams
rr.esams    3600   IN  A       91.198.174.2

Letztlich müssen also alle Rechner, die sich mit „de.wikipedia.org.“ verbinden möchten, IPv4-Pakete an die IP-Adresse 91.198.174.2 senden.

Auflösung eines DNS-Requests

Flussdiagramm
Flussdiagramm

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 3484 die Kommunikation zwischen X und Y über IPv6 bevorzugt, es sei denn im Betriebssystem oder in den benutzten Anwendungen, wie zum Beispiel dem Webbrowser, wurde dieses Verhalten anders eingestellt.






  1. 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.
  2. 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.“.
  3. 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.
  4. Nun fragt der DNS-Server von Rechner X einen der Nameserver für „org.“-Domains nach „de.wikipedia.org.“.
  5. 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.“.
  6. Anschließend fragt der DNS-Server von Rechner X einen „wikipedia.org.“-Nameserver wie die IP-Adresse des Namens "de.wikipedia.org." ist.
  7. Mit dieser Adresse wird an den DNS-Server von Rechner X geantwortet und der …
  8. … 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 die TLD-Zone (Zone, die die Nameserver für .org, .de, .com, … enthält) verwalten und alle weiter via IPv4 befragt werden können, einige zusätzlich auch mittels IPv6. Die Root-Nameserver verwalten die Wurzel 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 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.

DNS Serverliste

http://www.stanar.de/

DNS Check

http://www.dnswatch.info/de

Quellenangaben

http://de.wikipedia.org

[ nach Oben ]
[Zurück zu Netzwerk]

[Zurück zu Hauptseite]
Abgerufen von „https://wiki.zebradem.com/wiki/index.php?title=DNS&oldid=14991“