Domain Name System
| DNS (Domain Name System) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Familie: | Internetprotokollfamilie | ||||||||||||||||||||||||
| Einsatzgebiet: |
Finden der IP-Adresse(n) einer Domain oder | ||||||||||||||||||||||||
| Ports: | 53/UDP, 53/TCP | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
| Standards: | |||||||||||||||||||||||||
Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Das DNS ist eine verteilte Datenbank, die den Namensraum im Internet verwaltet. DNS läuft standardmäßig auf Port 53.
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 den Domainnamen www.wikipedia.org einfacher merken, als die dazugehörende IP-Adresse 145.97.39.155.
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.
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 wurde 1983 von Paul Mockapetris entworfen und im RFC 882 beschrieben. Der RFC 882 wurde inzwischen von RFC 1034 und RFC 1035 abgelöst.
Das DNS löste die hosts-Dateien ab, die bis dahin für die Namensauflösung zuständig waren. Aufgrund ihrer Einfachheit werden hosts-Dateien teilweise weiter parallel zum DNS genutzt. DNS 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:
- Domain-Namensraum
- Nameservern
- Resolver
Domain-Namensraum
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. 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 Domain Name wird mit einem Punkt abgeschlossen (der hinterste Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domain Namen dazu). Ein korrekter, vollständiger Domain Name (auch Fully Qualified Domain Name (FQDN) genannt) lautet etwa www.wikipedia.de. (der letzte Punkt gehört zum Domain Name).
Ein Domain Name darf inklusive aller Punkte maximal 255 Zeichen lang sein.
Ein Domain Name 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 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
Nameserver sind Programme, die Anfragen zum Domain-Namensraum 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-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 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 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
- 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.
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, nicht zuletzt da er die Referenzimplementation der meisten RFCs zu DNS darstellt. BIND ist Open Source Software.
- djbdns gilt als sehr sicher und erfreut sich steigender Beliebtheit, wird aber von Dan Bernstein nicht mehr weiterentwickelt, weil er es als fertig ansieht.
- 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.
- 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 aber extrem sicher und stabil.
- 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.
Einträge in die Datenbank
DNS erlaubt keine freie Definition von Eintragstypen.
Die wichtisten Anfragen beziehen sich zweifellos auf IP-Adressen für einen Namen. Hierzu werden in der Regel A-Einträge (address) für IPv4 und AAAA-Einträge für IPv6 verwendet. Der Name a.iana-servers.net. wird über einen A-Record auf die Adresse 192.0.34.43 abgebildet.
Dabei dürfen durchaus auch mehrere IP-Adressen für einen Namen eingetragen sein. Der Resolver sucht sich entweder alle oder einen, etwa den ersten aus. Einige Nameserver mischen die IP-Adressen, so dass jeweils eine andere Adresse als erste erscheint. Damit ist eine einfache Lastverteilung möglich.
CNAME-Einträge (canonical name) ermöglichen die Definition von Aliasen für Namen. Man kann etwa www.example.net. auf host1.dmz.example.net. abbilden. Der neue Name kann wieder ein Alias oder eine Adresse sein.
PTR-Einträge (pointer) bilden eine eigene Namenshierarchie, die IP-Adressen auf Namen abbildet. Hierzu wird eine Pseudo-Domain in-addr.arpa. verwendet. Unterhalb dieser Domain wird die Dezimaldarstellung der Adresse in umgekehrter Reihenfolge als Name interpretiert. Für die Adresse 192.0.34.43 wird der PTR-Eintrag des "Namens" 43.34.0.192.in-addr.arpa. gesucht. Das Ergebnis ist dann a.iana-servers.net.
MX-Einträge (mail exchanger) enthalten den nächsten Postverteiler für eine Domain. Diese sind mit einer Prioriät versehen. Ein zentraler Postverteiler mit hoher Priorität einer größeren Organisation nimmt die Mail aus dem Internet entgegen und verteilt sie gegebenenfalls an interne kleinere Postverteiler niederer Priorität innerhalb der Organisation, die sie an die Empfangsrechner weiterverteilen.
Wird eine Mail etwa an user@domain.org versendet, ermittelt ein Rechner zunächst die MX-Einträge für domain.org. Aus diesen wählt er denjenigen mit der höchsten Priorität als Postverteiler. Wird kein Postverteiler gefunden, werden CNAME-Einträge oder Adresseinträge verwendet. Ein Postverteiler ermittelt die eigene Priorität über seinen MX-Eintrag und verteilt nur an Postverteiler niedrigerer Prioritäten.
Der NS-Eintrag (name server) dient zur Identifikation eines Nameservers. Es ist eine begrenzte Anzahl weitere Einträge wie Hostinformation, Mailrelay vorgesehen, die jedoch nur selten verwendet werden.
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 (zum Beispiel Chinesisch). Namen mit diesen Zeichen waren ursprünglich nicht möglich.
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. RFC 2673 beschreibt das Binary Label, mit welchem der volle Zeichensatz einer aus Bytes bestehenden Zeichenfolge genutzt werden kann. Da sowohl Resolver als auch Nameserver die Erweiterungen implementieren müssten, erlang EDNS keine weltweit flächendeckende Nutzung.
Ein anderer Ansatz zur Vergrößerung des Zeichenvorrats ist das 2003 in RFC 3490 beschriebene IDNA. 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. IDNA benötigt eine Anpassung des Resolvers und unter Umständen auch der Netzwerkanwendungen, die Nameserver-Infrastruktur braucht jedoch nicht verändert zu werden. Im deutschsprachigen Raum können seit März 2004 deutsche, liechtensteinische, österreichische und schweizer Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Auch bei einigen anderen Top-Level-Domains, insbesondere im asiatischen Raum, ist die Nutzung von IDNA möglich.
Eine weitere aktuelle Erweiterung des DNS stellt 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 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 (zum Beispiel DynDNS.org oder MyDyn.de oder pdns.de), die dafür sorgen, dass man auch mit solch rasch ändernden Adressen möglichst immer über denselben Rechnernamen erreichbar ist. Das freie Programm GnuDip stellt einen Server und Client zur Verfügung, mit denen sich Anwender ein eigenes DynDNS aufbauen können.
Siehe auch: Liste der TCP/IP-basierten Netzwerkdienste
Weitere Verwendungszwecke
Im E-Mail-Verkehr kann das DNS verwendet werden, 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) wird von einem asymmetrischen Kryptosystem Gebrauch gemacht, 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 bekannt machen 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.
Alternative Root-DNS
Im Laufe der Zeit wurden Alternativen zur IANA bzw. ICANN geschaffen. Näheres können Sie unter Top Level Domain nachlesen.
Bonjour/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 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 beziehungsweise 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 Namen „Zeroconf“ zusammen, als Bestandteil von Mac OS X auch als „Rendezvous“ bzw. „Bonjour“.
Analyse des DNS
Fehler im DNS können weit reichende Wirkungen haben. Zur Untersuchung werden in der Regel zwei Quellen heran gezogen:
(1) DNS Server Logs/Configs
Erste Quelle: Die Konfigurations- und Log-Dateien des jeweiligen DNS-Servers. Dieser Schritt setzt voraus, dass Zugang zum DNS-Server gegeben ist. Vorteil: Es wird direkt die Quelle „angezapft“, die das Verhalten bestimmt. Nachteil: Es wird vom gesamten DNS-Verbund nur 1 DNS-Server betrachtet.
(2) DNS Client/Server Kommunikation
Zweite Quelle: Der Daten-Verkehr der DNS-Server und DNS-Clients. Dies geschieht über Aufzeichnung und Auswertung des Datenverkehrs über das Mittel der LAN-Analyse durch sog. Sniffer. Vorteil: Es werden (je nach Messpunkt) alle DNS-Vorgänge aller DNS-Teilnehmer erfasst und ausgewertet. Nachteil: Es werden nur die Wirkungen, nicht aber unbedingt die Ursachen sichtbar.
Es zeigt sich also, dass am Ende beide Erkenntnis-Quellen heran zu ziehen sind. Hierzu müssen DNS-Server-Admins und LAN-Switch-Admins zusammen arbeiten, da jeder nur Zugriff auf jeweils eine der zwei Daten-Quellen hat.