DNS – Domain Name System
Allgemein
Das DNS ist einer der wichtigsten Dienste im Internet, denn es ist eine weltweit auf tausende von Servern verteilte Datenbank. Der Namensraum ist in Zonen unterteilt, die für unabhängige Administratoren zuständig sind. Es wäre auch möglich, für lokale Anforderungen, ein vom Internet unabhängiges DNS zu betreiben.
Zur Umsetzung von Domainnamen in IP-Adressen wird DNS hauptsächlich benutzt. So ist das eine Vereinfachung, da Menschen sich Namen besser merken können, als Zahlen (z.B. wikipedi.org und die dazu gehörige IP-Adresse 66.230.200.100).
Auch können IP-Adressen, z.B. von Webservern, leicht geändert werden können. Dies bleibt für den Internetnutzer meist verborgen, da sie nur die unveränderten DNS-Namen ansprechen.
Es ist auch eine umgekehrte Auflösung von IP-Adressen mit dem DNS möglich (reverse lookup).
1983 wurde DNS von Paul Mockapetris entworfen und im RFC 882 und 883 beschrieben. Inzwischen wurden beide von RFC 1034 und RFC 1035 abgelöst, aber auch durch zahlreiche weitere Standards ergänzt.
Das DNS hatte die ursprüngliche Aufgabe die lokalen Hosts-Dateien abzulösen, die war bis dahin für die Namensauflösung zuständig, aber der zunehmenden Zahl von Neuanträgen nicht mehr gewachsen. Da das DNS eine hohe Zuverlässigkeit und Flexibilität hat, wurden nach und nach weitere Datenbestände in das DNS integriert und damit den Internetnutzern zur Verfügung gestellt.
DNS zeichnet sich aus durch:
- Dezentrale Verwaltung
- Hierarchische Strukturierung des Namensraumes in Bauform
- Eindeutigkeit der Namen
- Erweiterbarkeit
Komponenten des DNS
Ein DNS besteht aus drei Hauptkomponenten:
- Domain-Namensraum
- Namensserver
- Resolver
Domain-Namensraum
Schematische Darstellung einer DNS-Hierarchie
Hier ist eine baumförmige Struktur vorhanden. Die einzelnen „Blätter“ und „Kronen“ werden als Labels bezeichnet. So ist ein kompletter Domainname eine Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind, mit einem Buchstaben beginnen müssen und nicht mit '-' enden dürfen (RFC1035, Abschnitt „2.3.1. Preferred name syntax“). Durch Punkte werden einzelne Labels voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der hinterste Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu) und darf maximal 255 Zeichen lang sein. Ein korrekter, vollständiger Domainname (auch Fully Qualified Domain-Name (FQDN) genannt) lautet etwa www.wikipedia.de. (der letzte Punkt gehört zum Domainnamen).
Je weiter ein Label rechts steht, umso höher steht es im Baum, das heißt ein Domianname wird immer von rechts nach links delegiert. Durch den Punkt am Ende eines Domainnamens wird das Label von der Wurzel getrennt, also die erste Hierarchieebene festgelegt. Top-Level-Domain (TDL) wird auch die erste Ebene 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
Das sind Programme, die Anfragen zum Domain-Namensraum beantworten. Es wird zwischen autoritativen und nicht-autoritativen Nameservern.
Autoritative Nameserver sind verantwortlich für eine Zone. Informationen dieser Zone werden als gesichert angesehen. Jede Zone hat mindestens einen autoritativen Server, dem Primary Nameserver. Dieser Primary Nameserver wird im SOA Resource Record in einer Zonendatei aufgeführt. Fast immer werden autoritative Nameserver, aus Redundanz- und Lastverteilungsgründen, als Server-Cluster realisiert. Hierbei werden die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Per Zonentransfer erfolgt die Synchronisation zwischen dem Primary und Secondary Nameserver.
Nicht-autoritative Nameserver beziehen ihre Informationen über Zonen von anderen Nameservern, aus zweiter und dritter Hand sozusagen. Die Informationen werden als nicht gesichert angesehen. Nicht-autoritative Nameserver speichern DNS-Daten, da sie sich nur sehr selten ändern, im lokalen RAM, nach einer Anfrage vom Resolver, ab. Jetzt geht es bei einer erneuten Anfrage schneller. Diese Vorgehensweise bezeichnet man als so genanntes Caching. Jeder Eintrag hat auch ein Verfallsdatum (TTL – Time to live), ist das abgelaufen wird der Eintrag aus dem Cache gelöscht. Ein autoritativer Nameserver legt das TTL für diesen Eintrag, der nach der Änderungswahrscheinlichkeit des Eintrages bestimmt wird, fest. So haben sich häufig ändernde DNS-Daten eine niedrige TTL. Wenn sich Daten zwischenzeitlich ändern, kann es sein, dass der Nameserver falsche Informationen liefert.
Resolver
Das sind einfach aufgebaute Software-Module. Sie können Informationen von Nameservern abrufen und sind auf dem Rechner eines DNS-Teilnehmers installiert. Resolver sind die Schnittstelle zwischen Anwendung und Nameserver. Er übernimmt die Anfrage einer Anwendung, wenn es notwendig ist, werden sie zu einem FQDN ergänzt und dann an einen fest zugeordneten Nameserver übermittelt. Es gibt zwei Möglichkeiten, wie ein Resolver arbeitet, rekursiv oder iterativ.
Ist er im rekursiven Modus schickt er eine rekursive Anfrage an einem ihn zugeordneten Nameserver. Sind die von ihm angeforderten Informationen nicht in diesem Datenbestand, kontaktiert der Nameserver weitere Server. Das geschieht solange, bis er entweder eine positive Antwort bekommt oder er von einem autoritativen Server eine negative Antwort bekommt. Die Arbeit wird, bei einem rekursiv arbeitenden Resolver, bis zur vollständigen Auflösung dem Nameserver überlassen.
Ein Resolver bekommt bei einer interativen Anfrage den gewünschten Resource Record oder einen Verweis auf einen weiteren Nameserver. Hier hangelt sich der Resolver von Nameserver zu Nameserver, bis er eine verbindliche Antwort erhält.
Die gewonnene Antwort wird dem Programm übergeben, das die Daten angefordert hat.
Meist arbeiten die Resolver von Clients rekursiv und werden als Stub-Resolver bezeichnet. In der Regel besitzen Nameserver eigene Resolver, diese arbeiten interativ.
Strategien
Wenn ein nicht-autoritativer Nameserver Informationen, über andere Teile des Namensraumes, sucht, nimmt er folgende Strategien zur Hilfe:
Delegieren:
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.
Protokoll
Über UDP Port 53 werden DNS-Anfragen zum Nameserver gesendet, aber auch TCP wird erlaubt. Die maximal zulässige Länge des DNS-UDP-Pakets beträgt 512 Byte. Sind die Antworten zu lang, werden sie abgeschnitten übertragen. Der anfragende Client wird, durch das Setzen des Truncates-Flags, über diesen Sachverhalt informiert. Er entscheidet dann, ob ihm die Antwort reicht oder nicht, die Anfrage wird dann gegebenenfalls, per TCP Port 53, wiederholt.
Zonentransfers werden stets über Port 53 TCP durchgeführt. Die Auslösung von Zonentransfer erfolgt aber gewöhnlich per UDP.
Aufbau der DNS-Datenbank
Das DNS ist eine verteilte Datenbank mit baumförmiger Struktur. Die Daten beim Internet-DNS liegen auf einer Vielzahl von weltweit, verstreuten Servern. Diese sind untereinander über Verweise verknüpft.
Es existieren in jedem beteiligten Nameserver eine oder mehrer Dateien, die Zonendateien, die alle relevante Daten besitzen. Diese Dateien sind Listen von Resource Records.
Es gibt zwei relevante Record-Typen:
· A Resource Record definiert die eigentlichen Daten, einem Namen wird eine IP(v4)-Adresse zugewiesen.
· Das NS-Record realisiert die Verknüpfungen der Server untereinander.
Diese beiden Record-Typen sind ausreichend um das gesamte klassische DNS aufzubauen. Es sind aber für Verwaltungszwecke weitere Typen erforderlich, z.B. SOA Records. Es wurden immer mehr Typen im Laufe der Zeit definiert, die mit den Erweiterungen des DNS realisiert wurden.
Erweiterung des DNS
Es wurden im Laufe der Zeit mehrere größere Erweiterungen eingeführt, da sich das DNS sowohl als zuverlässig, als auch flexibel erwiesen hat.
Dynamischer DNS
Es ist notwendig, im klassischen DNS, einem Namen eine neue IP-Adresse zuzuordnen. Da das Zonenfile meist manuell geändert werden muss und der Nameserver dann neu geladen werden muss, kommt es zu zeitlichen Verzögerungen. Mit dem Dynamischen DNS sind Änderungen durch Senden eines entsprechenden DNS-Request ohne Zeitverzug möglich.
Hier gibt es allerdings ein Sicherheitsrisiko, da ohne spezielle Vorkehrungen jeder DNS-Einträge löschen oder verändern kann. Da einem User häufig neue IP-Adressen zugewiesen werden, ist im Zusammenhang mit DHCP ein Dynamisches DNS zwingend erforderlich. Der DHCP-Server sendet dazu bei jeder Adressänderung eine entsprechende Mitteilung an den Nameserver.
Internationalisierung
Die Labels waren bisher auf alphanumerische Zeichen und das Zeichen ‚-‚ beschränkt. Da es aber in vielen Ländern Zeichen gibt, die im Label nicht verwendet werden konnten oder Zeichen aus komplett anderen Schriftsystemen. Namen mit diesen Zeichen waren dann nicht DNS-fähig.
2003 kam es, in RFC 3490, zur Internationalisierung von Domain-Namen IDNA. Um das neue System mit dem bisherigen kompatibel zu halten, werden erweiterte Zeichensätze mit zulässigen Zeichen kodiert, also auf derzeit gültige Namen abgebildet.
Erweiterte Zeichensätze werden gemäß dem Nameprep-Algorithmus (RFC 3491) normalisiert und per Punycode (RFC 3492) für den DNS verwendbar abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (z.B. Web-Browser). Jedoch brauch die Nameserver-Infrastruktur nicht verändert werden.
Extendes DNS
Paul Vixie beschrieb 1999, im RFC 2671, das EDNS. Das ist eine abwärtskompatible, kleinere Erweiterung vom DNS.
Hier werden reservierte, aber ungenutzte Header-Codes verwendet. So kann der Anfragende festlegen, dass er UDP-Antworten größer als 512 Byte entgegen nehmen kann. Auch ist es möglich andere Label-Typen zu nutzen. Server und Resolver, die DNSSEC-fähig sind, müssen EDNS beherrschen.
Verwaltung von Telefonnummern
ENUM (RFC 2916) ist eine aktuelle Erweiterung. Hier wird die Adressierung von Internet-Diensten über Telefonnummern ermöglicht Also das Anwählen von Geräten, die übers Internet erreichbar sind, mit dem Nummerierungsschema aus dem Telefonnetz. Für Voice over IP Services bietet sich die Verwendung an.
RFID-Unterstützung
Radio Frequancy Identification
Hiermit können auf spezielle RFID-Etiketten abgelegte ID’s (Elektronische Produktcodes oder EPC’s) berührungslos gelesen werden. Das DNS wird dazu verwendet zu den ID’s den passenden Server zu ermitteln, der Daten über das zugehörige Objekt enthält. Der ONS (Object Naming Service) wandelt den EPC in einen DNS-Namen um und erfragt per Standard einen oder mehreren Naming Authotity Pointer NAPTR.
Spam-Abwehr
Viele Mailserver überprüfen routinemäßig, zur Filterung von Spam-Mails, mit Hilfe von DNS die Absenderadressen eingehender Mails.
Als erstes wird der MX Record ermittelt, aus der erhaltenen IP-Adresse wird per reverse Lookup ein Name erfragt. Der muss mit dem ursprünglichen Absendernamen identisch sein, sonst wird die Mail verworfen. Es ist nicht möglich, für den Spammer, beliebige Absenderadressen zu finden, sondern er muss auf registrierte DNS zurückgreifen. Es kann durch Sender Policy Framework wirkungsvoller verifiziert werden, ob ein Absendername gültig ist. Über SPF Resource Record wird aufgelistet, wer aus dieser Domain heraus Mails versenden darf.
DNS im lokalen Netz
Das DNS ist nicht auf das Internet beschränkt. Es ist für die Auflösung lokaler Namen eigene Zonen im Nameserver einzurichten und entsprechende Adressen einzutragen. Die Installation lohnt sich auch bei kleineren Firmen, da dann alle Adressen im Netz zentral verwaltet werden können.
Bei größeren Firmen ist ein Mischsystem, aus lokalem und Internet DNS, (Split-DNS) häufiger anzutreffen. Interne Nutzer greifen auf lokale und externe auf das Internet-DNS zu. Dadurch können in der Praxis komplizierte Konstellationen entstehen.
DNS-Security
DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur. Störungen können also erhebliche Kosten hervor bringen. So können Verfälschung von DNS-Daten Ausgangspunkt von Angriffen sein. Folgende Security-Funktionen 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.
