Namen und DNS



entstanden im

Proseminar Technologien und Richtlinien im WWW-Umfeld

Sommersemester 2005

TU-Chemnitz



Martin Schulze



Wann und warum entstand das DNS, wie verlief seine Geschichte?
Wer kontrolliert das DNS, wer hat welchen Einfluß?
Welche Struktur haben DNS und Kontrollorgane, was ist die "ICANN"?
Wem gehört ein Domainname? Woher erhält man eine Domain?

1. Entstehungsgeschichte des DNS

Das Internet basiert auf dem TCP/IP Protokoll, somit wird jeder Rechner über eine IP-Addresse eindeutig addressiert (z.B.: 134.109.132.162). Diese IP Addressen sind für den menschlichen Gebrauch unpraktikabel, bzw. schlecht merkbar, somit wurde alsbald jede IP-Addresse mit einer Domain verknüpft. Diese Paarung IP-Addresse – Domain wurde anfangs mit einigen Zusatzinformationen in einer simplen Textdatei gespeichert (nach RFC-952). Diese host.txt wurde regelmäßig über das File Transfer Protocol (FTP) vom damaligen NIC (Network Information Center) an der Stanford University synchronisiert. Langsam sah man auch ein immer schnelleres Wachstum des Internets voraus, so hatte es 1984 über 1000 Teilnehmer, 1987 schon über 10000. Auch die Anzahl der Domains wuchs stetig. Somit wurde die zentrale Datei immer größer und auch durch die steigende Anzahl der teilnehmenden Rechner erhöhte die Netzwerkbelastung, vor allem auf dem zentralem Server. Es stellte sich sehr schnell heraus das dieses System ideal für kleinere Netzwerke ist, jedoch für das langsam boomende Internet unpraktikabel ist. Das Prinzip wird auch noch heute angewandt. Unter Linux kann man netzwerkinterne Domains in der Datei /etc/hosts einsehen bzw. ändern, unter Windows existiert äquivalent dazu die Datei lmhosts im /Windows/System – Verzeichnis. So wurde 1984 das Domain Name System (DNS), welches von Paul Mockapetris ein Jahr zuvor entwickelt wurde, eingeführt.

2. Aufbau des DNS

Das DNS wird in der RFC 882 beschrieben, 1987 kamen noch einige Erweiterungen dazu, so ist die heutige Form des DNS in den RFCs 1034 und 1035 definiert. Das DNS besteht aus 3 Bestandteilen:

2.1 Der Domänennamensraum

Im Domänennamensraum werden die Eigenschaften einer Domain definiert. So darf sie inklusive aller Punkte maximal 255 Zeichen lang sein. Die Labellänge, also die Zeichenketten zwischen den Punkten wurde auf maximal 63 Zeichen festgesetzt. Erlaubt sind nur alphanumerische Zeichen, als einziges Sonderzeichen wurde der Bindestrich ('-') eingeführt.

Im März 2004 trat der IDNA (Internationalizing Domain Names in Applications) - Standard in Kraft. Er definerte die Verwendung von länderspezififischen Zeichen in Domainnamen. Diese Nicht-ASCII-Domains werden mit Hilfe des Nameprep und des Punycode-Algorithmus in gültige Namen umgewandelt. Der Nameprep-Algorithmus normalisiert die Domain, so verwandelt er Großbuchstaben in Kleinbuchstaben und macht beispielsweise aus dem “ß” ein “ss”. Der Punycode Algorithmus entfernt alle unerlaubten Zeichen und codiert sie am Ende der Zeichenkette. Ein Punycode String beginnt immer mit "xn--". Eine Beispielimplementierung in C findet man in der  RFC 3492. Hier 2 Beispiele für IDNA Domains:

Die Umwandlung erfolgt also im Client (Webbrowser), nicht auf dem Server, so musste für die Einführung der länderspezifischen Domains keine Veränderungen an den DNS Servern bzw. deren Infrastruktur unternommen werden. IDNA wir zur Zeit von allen gängigen Browsern unterstützt, beim Internet Explorer aus dem Hause Microsoft soll es allerdings einige Probleme geben. In der angekündigten Version 7.0 wird dieser Standard aber unterstützt.

2.2 Die Nameserver

Das Netz der Nameserver ist hierarchisch aufgebaut. An oberster Stelle steht die Root-Zone. Ein Nameserver kann eine Anfrage wiefolgt beantworten:

Beispiel DNS-Abfrage

Ein Client ruft in seinem Webbrowser "www.tu-chemnitz.de" auf. Der Webbrowser versucht nun über den in Betriebssystem integriertem Resolver die zur Domain zugehörigen IP Addresse herauszubekommen. Dieser fragt nun den standardmäßigen DNS Server ab, wie die IP Addresse zu "www.tu-chemnitz.de" ist. Um die Addresse des DNS-Servers brauch sich der Nutzer nicht zu kümmern, da diese Daten meist mit den Zugangsparametern des Internet-Zugangs mitgeliefert werden. Hat der DNS-Server erst kürzlich diesselbe Domain aufgelöst, liefert er dei zugehörige IP-Addresse sofort aus dem eigenem Cache zurück.
Gehen wir nun davon aus, das diese Auflösung nicht vor kurzem aufgelöst wurde. So fragt der DNS-Server einen der 13 Root Server nach, wie die IP-Addresse von "www.tu-chemnitz.de" ist. Der Rootserver weiss natürlich nicht die genau IP Addresse (bzw. ist nicht autoritativ für "www.tu-chemnitz.de"), er weiss aber sehrwohl die IP Addresse eines DNS Servers, die für die ".de"-Zone zuständig ist. Dieser wird ebenso nach der IP von "www.tu-chemnitz.de" gefragt. Wiederum gibt dieser zurück, das er für diese Domain nicht autoritativ ist und zusätzlich die IP-Adresse des DNS-Servers zurück, welcher für die Domain "tu-chemnitz.de" zuständig. Wiederum wird er nach der IP von "www.tu-chemnitz.de" gefragt. Diesmal gibt der Nameserver zurück, das er autoritativ für "www.tu-chemnitz" ist und gibt die entsprechende IP-Addresse aus seiner lokalen Zonendatei zurück an den Nameserver, der vorhin vom Client kontaktiert wurde.
Nun liefert dieser Nameserver die IP-Addresse an den Client zurück und speichert diese Zuordnung im lokalen Speicher für eine gewisse Zeit (TTL).

Resource Records

Das DNS speichert nicht nur die Domain-IP-Beziehung, sondern auch viele weitere Informationen. Diese kann man mithilfe des kleinsten Informationseinheit des DNS, dem Resource Record, abgefragt werden. Er hat folgende Struktur:

<name> [<ttl>] [<class>] <type> <rdata>
 
Auswahl wichtiger Resource Records Typen (von insgesamt über 25)
Einige Beispielabfragen mit host:
host -t A www.heise.de
www.heise.de has address 193.99.144.85

Hier wird der "A"-Resource Record der Domain heise.de abgefragt, also die Domain in eine IP-Addresse aufgelöst.

host -t TXT gmx.de
gmx.de text "v=spf1 ip4:213.165.64.0/23 -all"

Hier wird der "TXT" Resource Record der Domain gmx.de abgefragt. Dieser wird hier zur Spamidentifizierung genutzt. GMX legt hier fest das alle Server mit deren IP-Addresse mit "213.165.64." beginnt, EMails von @gmx.de verschicken dürfen. Diese Art der Identifizierung nutzen alle gängigen Spamdetektoren. Erhält man also eine EMail von der Domain gmx.de und sie wurde nicht aus dem beschriebenem IP-Bereich versendet, ist diese Mail höchstwahrscheinlich Spam.

host -t PTR 193.99.144.85
85.144.99.193.in-addr.arpa domain name pointer www.heise.de.

Hier wird mit Hilfe des "PTR" Resource Record die zur IP gehörige Domain abgefragt.

host -t MX www.tu-chemnitz.de
www.tu-chemnitz.de mail is handled by 1 john.hrz.tu-chemnitz.de.
www.tu-chemnitz.de mail is handled by 1 lana.hrz.tu-chemnitz.de.

In diesem Beispiel liefert der "MX"-Resource Record die zur Domain "www.tu-chemnitz.de" zugehörigen Mail-Server.

2.3 Die Resolver

Die Resolver sind der Teil des DNS, die die Domaininformationen abrufen. Der Resolver übernimmt die Anfrage einer Anwendung und übermittelt sie an einen fest konfigurierten Nameserver. Er bildet also die Schnittstelle zwischen der Anwendung, zum Beispiel ein Webbrowser, und dem Nameserver. Die Resolver-Funktionsbibliotheken sind in der Regel fest im Betriebssystem integriert.

3. Die Kontrollorgane des DNS

Die Internet Assigned Numbers Authority (IANA ) ist für Vergabe der IP-Addressen und TLDs verantwortlich. Sie verteilt die IP-Addressen an die  Regionale Internet-Registries (RIRs), welche sind:
Direkt für das DNS ist seit 1998 die ICANN verantwortlich. Die Internet Corporation for Assigned Names and Numbers ist der Zusammenschluss verschiedener Interessenverbände aus der Wirtschaft, der Technik, der Wissenschaft und den Nutzern. Sie besteht aus 18 Mitgliedern aus aller Welt, unter anderem war bis vor kurzem Andy Müller-Maghuhn eines der Mitglieder. Seit 1998 ist die IANA nur noch für die TLDs verantwortlich. Die ICANN wird auch als die "Weltregierung des Internets" bezeichnet und koordiniert insbesondere den Betrieb der Root-Server des DNS. Davon gibt es zur Zeit 13 Stück, jedoch nur 3 außerhalb der USA (London, Stockholm, Tokio). Dies zeigt das die USA versucht, halbwegs Kontrolle über das Internet zu besitzen.
Für jede Top-Level-Domain wird von der IANA ein Netzwerkdienstleister beauftragt diese zu verwalten. Für die Deutschen .de - Domains ist beispielsweise die DENIC verantwortlich. Jeder Domainverwalter legt dabei seine eigenen "Spielregeln" fest, so wird bei den .uk - Domains auch die Subdomain .co.uk zusätzlich vom Verwalter der regionalen TLD .uk gemanagt. In Deutschland sind Domainnamen verboten, die KFZ-Kennzeichen enthalten, d.h. die Abkürzung für die Deutschen KFZ-Zulassungsbezirke. Die Denic will sich damit eine eventuelle Verwaltung der Secondleveldomains offenhalten, so das z.B. Anwohner des Main-Taunus-Kreises sich unterhalb von .mtk.de Domains registrieren können. Ob und wann es tatsächlich zur Einführung derartiger Second Level Domains kommt, ist gegenwärtig laut Denic noch nicht entschieden. Die Registrierung einer Domain erfolgt meist nicht direkt bei einem Domainverwalter. Es ist üblich das ein Internetdienstleister diese übernimmt. Bei der Anmeldung einer Domain muss man neben technisch-notwendigen Dingen auch administrative Dinge angeben:

4. Anhang

Unter Linux gibt es einige Tools für die Kommandozeile die DNS Informationen abrufen:

5. Quellen

DENIC Domain-Richtlinien-KFZ-Kennzeichen: http://www.denic.de/de/faqs/detail_47.html
DNS Information und Unterpunkte: http://de.wikipedia.org/wiki/Kategorie:Domain_Name_System
DNS Informationen: http://www.tecchannel.de/netzwerk/grundlagen/401207/index10.html
allgemeine DNS Informationen: http://www.linuxfibel.de/dns_srv.htm