Zum Inhalt springen

Domain Name System

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 2. Juni 2005 um 14:49 Uhr durch 62.112.129.197 (Diskussion) (Strategien). Sie kann sich erheblich von der aktuellen Version unterscheiden.
DNS im TCP/IP-Protokollstapel
Anwendung DNS
Transport UDP TCP
Netzwerk IP
Netzzugang Ethernet Token
Ring
FDDI ...

Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Das DNS ist eine verteilte Datenbank, die den Namensraum im Internet verwaltet.

Hauptsächlich wird das DNS zur Umsetzung von Namen in 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 den Domainnamen www.wikipedia.de sehr einfach merken, die dazugehörende IP-Adresse 207.142.131.236 dagegen nicht ganz so einfach.

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 (dies ist innerhalb der deutschen TK-Branche unter dem Namen Inverssuche bekannt).

Darüber hinaus ermöglicht das DNS eine Entkopplung vom darunterliegenden Aufbau, z.B. Änderung der IP-Adresse, ohne den Domainnamen ändern zu müssen, und sogar rudimentäre Lastverteilung (Load Balancing).

Das DNS (Domain Name System) wurde 1983 von Paul Mockapetris entworfen und im RFC 882 beschrieben. Der RFC 882 wurde inzwischen von den RFCs 1034 und 1035 abgelöst.

Das DNS löste die hosts-Dateien ab, die bis dahin für die Namensauflösung zuständig waren. Es zeichnet sich aus durch:

  • dezentrale Verwaltung
  • hierarchische Strukturierung des Namensraums in Baumform
  • Eindeutigkeit der Namen
  • Erweiterbarkeit

Komponenten des DNS

Das DNS besteht aus drei Hauptkomponenten:

  • Domänennamensraum
  • Nameservern
  • Resolver

Domänennamensraum

Der Domänennamensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels bezeichnet. Ein kompletter Domänenname eines Objektes besteht aus der Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind. Die einzelnen Label werden durch Punkte voneinander getrennt. Ein Domänenname wird mit einem Punkt abgeschlossen (Der hinterste Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domänennamen dazu). Ein korrekter, vollständiger Domänenname (auch FQDN) lautet z.B. www.wikipedia.de. (der letzte Punkt gehört zum Domänennamen).

Ein Domänenname darf inklusive aller Punkte maximal 255 Zeichen lang sein.

Ein Domänenname wird immer von rechts nach links delegiert und aufgelöst, d.h. je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt ganz rechts wird auch als root (Wurzel) im Namensraum bezeichnet.

Das erste Label (das, das links vom Punkt der root steht) wird im allgemeinen auch als Top Level Domain (TLD) bezeichnet.

Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records 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

Nameserver sind Programme, die Anfragen zum Domänennamensraum beantworten. 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-autoritativer 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 u.U. 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 auflösen.

Strategien

Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien.

  • Delegierung
    Teile des Namensraumes einer Domäne 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
    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. Derzeit gibt es 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.

DNS-Anfragen werden normalerweise auf Port 53 UDP beantwortet. Falls die Antwort sehr umfangreich ausfällt (größer 512 Bytes), wird diese auf Port 53 TCP übermittelt......... Zonentransfers werden stets auf Port 53 TCP durchgeführt.

Nameserversoftware

  • BIND (Berkeley Internet Name Domain) ist der Ur-Nameserver und heute noch die meistgenutzte Nameserversoftware. BIND ist Open Source Software.
  • djbdns (entwickelt von Dan Bernstein) gilt als sehr sicher und erfreut sich steigender Beliebtheit.
  • PowerDNS war eine kostenpflichtige Implementierung, die inzwischen auch unter der GPL erhältlich ist und vor allem für das direkte Betreiben von Zonen aus SQL-Datenbanken und LDAP-Verzeichnissen bekannt ist.
  • MyDNS ist eine weitere Open-Source-Software, die insbesondere auf MySQL- und PostgreSQL-Datenbanken spezialisiert ist.
  • NSD ist optimiert für Server die ausschließlich autoritative Antworten liefern sollen.

Resolver

Resolver sind Ansammlungen von Bibliotheken, die Informationen aus den 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 den fest konfigurierten Nameserver.

Ein Resolver arbeitet entweder iterativ oder rekursiv und informiert den Nameserver über die verwendete Arbeitsweise. Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie werden dann auch als Stub-Resolver bezeichnet.

Bei einer rekursiven Anfrage schickt der Resolver eine Anfrage an einen ihm bekannten Nameserver und erwartet von ihm eine eindeutige Antwort. Diese Antwort enthält entweder den gewünschten Resource Record oder „gibt es nicht“. Rekursiv arbeitende Resolver überlassen also die Arbeit zur vollständigen Auflösung anderen.

Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource Record oder die Adresse eines weiteren Nameserver, den er als nächsten fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver bis er bei einem autoritativen Nameserver landet.

Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten angefordert hat, beispielsweise an den Webbrowser.

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.

Beispiel

Im Beispiel wird www.example.net „per Hand“ aufgelöst. Die Adresse von A.root-servers.net (198.41.0.4) wird dabei als bekannt vorausgesetzt, die Ausgabe ist auf das Wesentliche gekürzt.

$ dig +norecurse @198.41.0.4 www.example.net
    net.                    172800  IN      NS      A.GTLD-SERVERS.net.
    A.GTLD-SERVERS.net.     172800  IN      A       192.5.6.30

$ dig +norecurse @192.5.6.30 www.example.net
    example.net.            172800  IN      NS      a.iana-servers.net.
    a.iana-servers.net.     172800  IN      A       192.0.34.43

$ dig +norecurse @192.0.34.43 www.example.net
    www.example.net.        172800  IN      A       192.0.34.166

Bei den von den nicht-zuständigen Nameservern zusätzlich ausgegebenen A-Records handelt es sich um Glue Records.

Erweiterung des DNS

Bisher waren die Label – wie beschrieben – 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 USA entwickelt wurde. Allerdings gibt es in vielen Ländern Zeichen, die nicht in einem Label verwendet werden durften (im deutschen Sprachraum zum Beispiel die Umlaute ä, ö und ü) oder Zeichen aus komplett anderen Schriftsystemen (z.B. Chinesisch). Namen mit diesen Zeichen waren bisher nicht möglich.

Dies hat sich durch die Einführung von IDNA (RFC 3490) geändert. Seit März 2004 können deutsche, lichtensteinische, österreichische und schweizer Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit erlaubten 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. Das Voransetzen des durch die IANA festgelegten IDNA-Prefix xn-- vor das Ergebnis der Kodierung ergibt das vollständige IDN-Label.

Eine weitere aktuelle Erweiterung des DNS stellt ENUM (RFC 2916) dar. Diese Anwendung ermöglicht die Addressierung von Internet-Diensten über Telefonnummern, also das „Anwählen“ von per Internet erreichbaren Geräten mit dem aus dem Telefonnetz bekannten Adressschema. Aus dem breiten Spektrum der Einsatzmöglichkeiten bietet sich insbesondere die Verwendung für Voice over IP Services an.

DynDNS

Es kann nur Rechnern mit fester, sich also nie ändernden IP-Adresse ein fester Rechnername zugeordnet werden. Da jedoch sehr viele Nutzer mit Heimrechnern eine variable IP-Adresse haben (mit jeder Einwahl in das Internet wird eine andere IP-Adresse aus einem Pool zugeteilt), gibt es inzwischen DynDNS-Betreiber, die dafür sorgen, dass man auch mit solch rasch ändernden Adressen möglichst immer über den selben Rechnernamen erreichbar ist.

Siehe auch: Liste der TCP/IP-basierten Netzwerkdienste

Weitere Verwendungszwecke

Im E-Mail-Verkehr wird das DNS verwendet, um abzufragen, ob ein Mailserver ein Open Relay darstellt. Da über offene Relays häufig Spam versandt wird, soll das Spam-Aufkommen durch Ablehnen einer Verbindung oder Verwerfen der E-Mail reduziert werden. Dazu fragt der Mailserver bei einer Realtime Blackhole List (RBL) bzw. DNS-based Blackhole List (DNSBL) an, ob die IP-Adresse der eingehenden SMTP-Verbindung als Open Relay eingetragen ist.

Mit dem Telephone Number Mapping werden Telefonnummern im Domain Name System abgelegt, um die IP-Telefonie zu erleichtern. Mobilfunkbetreiber benutzen DNS bei ihren Triple-A-Systemen, um zum Beispiel intern in ihrem System zu einer IP-Adresse eines Kunden die Mobile Subscriber ISDN Number abzufragen.

Es gibt auch Ansätze, das Domain Name System zum Tunneln von Nutzdaten zu verwenden und so eine Firewall zu umgehen.

DNS-Security

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 symmetrischen Schlüsseln beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern gesichert werden kann.
  • Bei DNSSEC (DNS Security) handelt es sich um ein komplexes Public Key Verfahren, mit dem nahezu alle DNS-Sicherheitsanforderungen erfüllt werden können. Neben der Server-Server-Kommunikation wird auch die Client-Server-Kommunikation gesichert.

Domain-Registrierung

Um DNS-Namen im Internet bekanntmachen zu können, muss der Besitzer die Domain, die diese 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 IANA bzw. ICANN autorisiert wurden. Registrierungen sind gebührenpflichtig.

Detaillierte Informationen finden sich unter Domain-Registrierung.

Apple hat mit Mac OS X mehrere Erweiterungen am DNS vorgenommen: Zum einen wurde MulticastDNS ("mDNS") eingeführt, das die Namensauflösungen in einem 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 bzw. mDNS ermöglicht. mDNS und DNS-SD sind bisher keine offiziellen RFCs des 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 Stichwort Zeroconf zusammen, welches die umfassende Selbstkonfiguration von Diensten in LANs ermöglichen soll.


Vorlage:WikiReader Internet