Thomas Weihrich

Filofax fürs Internet

Der Domain Name Service von TCP/IP

Glücklich, wer sich die Telefonnummern zumindest seines engeren Bekanntenkreises merken kann. Sich jedoch zusätzlich noch an die bis zu zwölfstelligen IP-Adressen aller möglicher Internet-Server zu erinnern, übersteigt auch die Fähigkeiten eines gut trainierten Gedächtnisses. Dankenswerterweise nimmt einem der Domain Name Service als automatisches Telefonbuch diese Aufgabe ab und stellt damit einen der wichtigsten Dienste im Internet dar.

Unterthema: Direktiven und Ressourcen - die Konfiguration eines Name-Servers
Unterthema: Das große Schweigen - wenn der Name-Server nicht antwortet

In den Anfangszeiten des Internet herrschte noch die Meinung vor, eine 32-Bit-Adresse würde auch auf lange Sicht zur Adressierung sämtlicher vernetzter Rechner ausreichen. Doch schon damals waren sich alle Verantwortlichen einig, daß eine rein numerische Adresse nicht handhabbar ist. Eine IP-Adresse [1] wie etwa `194.122.76.131´ kann sich ein normaler Mensch nun einmal weitaus schlechter merken als den dazugehörigen Host-Namen `www.heise.de´. Aus diesem Grunde wurden Domain- und Host-Namen eingeführt, die es erlauben, Rechnernetze und die darin angeschlossenen Hosts symbolisch anzusprechen. Die eigentliche Kommunikation über TCP/IP läuft aber immer mittels IP-Adressen ab, die Host-Namen sind lediglich eine Hilfestellung für die menschlichen Benutzer.

Ursprünglich wurden die für diese Namensgebungen notwendigen Informationen in einer zentralen Host-Tabelle gespeichert. Das Network Information Center des Defense Data Network, nic.ddn.mil, hatte die Aufgabe, diese Tabelle zu verwalten. Sie wuchs jedoch schon innerhalb sehr kurzer Zeit so stark an, daß sie nicht mehr wartbar war. Dieser Umstand führte zur Einführung des Domain Name System DNS - eines hierarchischen, verteilten Dienstes auf Basis einer Datenbank. Die zentrale Bedeutung wurde erst jüngst deutlich, als durch menschliches Versagen die zentralen DNS-Server in den USA mit falschen Informationen versorgt wurden: Die Web-Server vieler großer und kleiner Firmen waren plötzlich nicht mehr wie gewohnt erreichbar, und EMail an diese Bereiche konnte nicht zugestellt werden.

Telefonbuch

Die strenge Hierarchie des DNS ermöglicht erst die Verteilung der Informationen auf verschiedene, unter Umständen weit voneinander entfernte Rechner. Am einfachsten läßt sich diese Hierarchie als Baum darstellen, wobei jede Verzweigung ihren eigenen Name-Server hat. An der Spitze (oder der Wurzel des Baumes) steht die Domain root, die durch einen Punkt gekennzeichnet wird. Es folgen die sogenannten Top-Level-Domains, zu denen momentan neben den einzelnen Länder-Domains wie .DE (Deutschland), .UK (Großbritannien) oder .US (USA) die administrativen Domains wie .COM (kommerzielle Nutzung), .GOV (US-Regierung), .MIL (US-Militär), .EDU (Bildungseinrichtungen, .NET (Netzwerk-Dienstanbieter) und .ORG (Non-Profit-Gesellschaften) gehören.

Das Domain Name System ist dabei ein typischer Client/Server-Dienst: Ein Client, der sogenannte Resolver, formuliert eine Anfrage nach einer zu einem Namen gehörigen Adresse und schickt diese Anfrage an einen Server, der in der Konfiguration von TCP/IP angegeben ist. Dieser schlägt den Namen in seiner Datenbank nach und schickt - so seine Suche erfolgreich ist - die Adresse an den Client zurück. Bei Mißerfolg übergibt er die Anfrage an den übergeordneten Server zur weiteren Bearbeitung. Dieser Prozeß setzt sich solange von Name-Server zu Name-Server von der untersten Domain über die Sub-Domains und Domains bis zu den Top-Level-Domains fort, bis die IP-Adresse gefunden wurde - oder bis der Name-Server der Top-Level-Domain meldet, daß dieser Host-Name nicht existiert.

Um eine TCP/IP-Verbindung über den Host-Namen zu etablieren, fragt der Resolver genannte DNS-Client auf dem lokalen Host den DNS-Server ab. Erst wenn als Antwort eine IP-Adresse zurückkommt, kann die eigentliche Sitzung aufgebaut werden.

Dieses System ist recht effizient. Zum einen überträgt es bei den Anfragen und Antworten immer nur die benötigten Informationen (zuzüglich eines erträglichen Protokoll-Overhead). Zum anderen speichern die einzelnen Server die Suchergebnisse für einen gewissen Zeitraum zwischen, um bei erneuter Anfrage die Antworten direkt, ohne den Umweg über einen weiteren Server liefern zu können. Das DNS stellt zum heutigen Zeitpunkt einen der wichtigsten Internet-Dienste überhaupt dar: Ohne ihn wären Internet-Anwendungen wie das World Wide Web nicht realisierbar.

Domain-Querelen

In letzter Zeit hat allerdings die begrenzte Zahl verfügbarer Top-Level-Domains für einige Unruhe gesorgt. So bekam nicht mehr jeder den Namen auch wirklich zugewiesen, den er sich eigentlich für seine Web-Präsenz wünschte. Zwielichtige Gestalten operierten als moderne Raubritter und versuchten, aus der Namensknappheit Geld zu machen, während die Verwaltungsgremien des Internet lange nichts unternahmen. Nachdem vor kurzem eine Vereinbarung zwischen einigen großen Firmen, Internet-Providern, Internet-Gremien und UN-Organisationen über neue Top-Level-Domains und ihre Verwaltung unterzeichnet wurde, schien wieder Bewegung in die verfahrene Situation zu kommen. Ein Einspruch der US-Regierung verhindert aber bislang die Umsetzung des Abkommens - so werden wir wohl noch einige Zeit darauf warten müssen, daß endlich wieder genügend Namen für Domains zur Verfügung stehen.

Auskunft

Unter den Top-Level-Domains sind die Domains einzelner Institutionen angesiedelt. Sie unterliegen voll und ganz der Kontrolle der Institution, von der sie beantragt und der sie zugeteilt wurde. Ein Beispiel für eine solche Domain ist `heise.de´. Eine solche Domain läßt sich bei Bedarf weiter unterteilen; auf diese Weise entstehen Sub-Domains wie `ct.heise.de´ oder `ix.heise.de´. Die Art der Unterteilung kann die Institution, der die Domain gehört, frei wählen. Der Rechner innerhalb einer Sub-Domain dient als letztes Element, sozusagen als Blatt des Domain-Baums. Sein Name ergibt in Verbindung mit dem Domain-Suffix den vollständigen, absoluten Domain-Namen, der als Fully Qualified Domain Name FQDN bezeichnet wird.

Aus der Hierarchie der Host- und Domain-Namen im DNS ergibt sich der Fully Qualified Domain Name FQDN, hier beispielsweise WWW.DEV.WWWA.ORG.

Oftmals wird nicht der vollständige Domain-Name eines Systems verwandt, sondern nur mit einem Teil gearbeitet - also beispielsweise `golem.ct´ anstelle von `golem.ct.heise.de´. In diesem Fall ist der Domainname relativ zu seinem Bezugspunkt in der Domain-Hierarchie zu interpretieren.

Hierfür läßt sich in der TCP/ IP-Konfiguration eine Reihe von möglichen Ergänzungen definieren. Allerdings sollten, wann immer mit Teilen des Domain Name Systems gearbeitet wird - so zum Beispiel in der Konfiguration der Datenbank - ausschließlich absolute Domain-Namen (FQDNs) verwendet werden, da sich andernfalls sehr schnell kostspielige Fehler einschleichen.

Doch das DNS liefert nicht nur die IP-Adressen zu vorgegebenen Namen, sondern auch umgekehrt. Viele Internet-Anwendungen versuchen beispielsweise aus Sicherheitsgründen zu ermitteln, von wo aus sie aufgerufen wurden. Hierzu steht ihnen ausschließlich die IP-Adresse des Kommunikationspartners zur Verfügung. Um diese auf einen Rechnernamen abbilden zu können, wurde eine spezielle Domain geschaffen: IN-ADDR.ARPA. Ein Eintrag in der IN-ADDR.ARPA-Domain besteht aus der IP-Adresse, rückwärts gelesen, und dem Suffix in-addr.arpa. Beispielsweise hat der Rechner `www.heise.de´ die IP-Adresse `194.122.76.131´, der IN-ADDR.ARPA-Eintrag lautet also `131.76.122.194.IN-ADDR.ARPA´.

Wählhilfe

Sämtliche Netzwerk-Betriebssysteme mit TCP/IP-Unterstützung bieten inzwischen die Möglichkeit, einen sogenannten Name-Server zu konfigurieren, um DNS-Dienste lokal bereitstellen zu können. Name-Server ist jedoch nicht gleich Name-Server: Sie können verschiedene Aufgaben wahrnehmen. Die Nomenklatur orientiert sich dabei an den Einsatzbereichen eines Servers:

Ein Primary-Server (Primary) ist der Hauptserver einer Domain. Er ist autorisiert, Anfragen zu seiner Domain verbindlich zu beantworten und verfügt über sämtliche Daten dieser Domain. Die Daten sind in den sogenannten Zonen-Dateien abgelegt, die der Verwalter des Servers (Hostmaster) erstellt.

Ein Primary-Domain-Server stellt den Haupt-Server einer Domain dar. Er kann alle Anfragen nach Host-Namen und den zugehörigen IP-Adressen verbindlich beantworten.

Ein Secondary-Server (Secondary) ist ebenfalls autorisiert, verbindliche Antworten zu seiner Domain zu liefern. Er lädt die Domain-Datenbank von einem Primary-Server und aktualisiert sie bei Bedarf.

Ein Secondary-Name-Server gibt wie ein Primary-Name-Server verbindlich über Host-Namen und IP-Adressen Auskunft, lädt aber die Datenbank eines Primary-Name-Servers und aktualisiert sie bei Bedarf. Der Secondary-Name-Server kann sowohl im eigenen Netz wie beim Service-Provider stehen.

Ein Caching-only-Server verfügt über keine eigenen Domain-Informationen, sondern fragt bei dem für die entsprechende Domain zuständigen Primary oder Secondary nach. Die Antwort speichert er dann zwischen. Ein Caching-only-Server muß nach der ersten Konfiguration nicht mehr gewartet werden. Da er jedoch nur über Daten aus zweiter Hand verfügt, kann er die Genauigkeit und Aktualität der Domain-Informationen, die er gespeichert hat, nicht gewährleisten. Im allgemeinen Sprachgebrauch heißt es, daß er zur Beantwortung von Anfragen zu einer Domain nicht autorisiert ist.

Ein Caching-Only-Name-Server verfügt über keine eigene Domain-Datenbank. Er fragt den zuständigen Primary- oder Secondary-Name-Server ab und speichert die Antworten zwischen, um sie bei erneuten Anfragen schneller zurückliefern zu können.

Ein Slave-Server reicht all diejenigen Anfragen, die er aus seinem eigenen Cache nicht direkt beantworten kann, an eine vorher festgelegte Liste von anderen Servern, den Forwarders, weiter. Diese kontaktieren dann ihrerseits den zuständigen Server und liefern dessen Antwort an den Slave zurück. Der Vorteil: die verantwortlichen Forwarder speichern die Ergebnisse auf sämtliche Anfragen aller Slaves zwischen. Auf diese Weise bauen sie einen ziemlich großen Cache auf. Spätere Anfragen anderer Clients (oder Slaves) nach den gleichen Daten können sie auf diese Weise meist direkt aus dem Cache heraus beantworten.

Für einen Slave Name-Server existiert ebenfalls keine eigene Domain-Datenbank. Er leitet alle Anfragen an Forwarder weiter, die dann die zugehörigen Primary oder Secondary Name-Server abfragen. Die Forwarder speichern die Ergebnisse für die Anfragen aller Slaves zwischen, so daß die Informationen in ihren Caches meist sehr umfangreich sind.

Nummernsalat

In seiner ursprünglichen Version ist das Domain Name System auf die Adressen der IP-Version 4 (IPv4) abgestimmt. Daher entsprechen die Datenformate, die zur Speicherung der momentan gebräuchlichen Einträge dienen (den Records), nicht den Anforderungen, die das neue IPv6 [2] an das DNS stellt. Da zudem sämtliche Applikationen davon ausgehen, daß es sich bei den Adressen, die eine DNS-Anfrage liefert, um 32 Bit große IPv4-Adressen handelt, ist eine direkte Erweiterung der DNS-Server auf die 128 Bit großen Adressen von IPv6 nicht möglich.

Nun ist es andererseits nicht praktikabel, IPv6-Adressen von Hand einzugeben; kein Mensch ist imstande, sich diese zu merken. Außerdem würde die Tipparbeit jeden Anwender in den Wahnsinn treiben. Auch ist die Einführung eines neuen Name Service nicht sinnvoll, da ein solcher Dienst auf der Server-Seite weitere Ressourcen wie Hauptspeicher, Rechenleistung und Netzwerkbandbreite bindet. Der zusätzliche administrative Aufwand sowohl bei seiner Einführung als auch bei der Wartung der entsprechenden Server wäre zudem nicht unerheblich.

Aber schließlich muß jedes an das Internet angeschlossene Netzwerk einen primären DNS-Server betreiben und über mindestens einen sekundären Server verfügen. Mit der dadurch gegebenen hohen Verbreitung und Verfügbarkeit von DNS-Servern bietet es sich an, diesen Dienst auch für IPv6 heranzuziehen. Er muß dafür allerdings um bestimmte Features erweitert werden. Im wesentlichen ergeben sich vier Ergänzungen am Domain Name System, um die Kompatibilität zu IPv6 zu sichern:

ein Resource Record für IPv6-Adressen,

eine inverse Domain für IPv6

die Modifikation bestehender Query-Typen,

Anpassung der Clients (Resolver-Bibliothek).

Zur Speicherung der IPv6-Adresse eines Rechners wurde ein neuer Resource Record, AAAA, eingeführt. Der Record-Typ wird numerisch durch den dezimalen Wert 28 repräsentiert. Jeder AAAA-Record speichert genau eine IPv6-Adresse. Verfügt ein Host über mehrere IPv6-Adressen, so müssen auch mehrere AAAA-Records angelegt werden. Kodiert wird die IPv6-Adresse im Datenfeld eines AAAA-Records in Network Byte Order - das höherwertige Byte zuerst. Die Text-Repräsentation des Datenfeldes eines AAAA-Records in einer Zonendatei eines DNS-Servers entspricht der Repräsentation einer IPv6-Adresse gemäß RFC 1884 (Request for Comment) [6]. Prinzipiell ähnelt der Eintrag für einen AAAA-Record in einer Zonendatei dem eines A-Records. Die wesentlichen Unterschiede bestehen im unterschiedlichen Record-Typ und einer IPv6- statt einer IPv4-Adresse:

test.WWWA.ORG.	IN\
A	192.107.123.192 
ipv6a.WWWA.ORG.	IN\
AAAA	4321:0:1:2:3:4:567:89ab

Wird ein DNS-Server nach einer IPv6-Adresse eines Rechners gefragt, so muß der Server mit sämtlichen AAAA-Records antworten, die zu diesem Namen existieren. Da eine Anfrage nach einem AAAA-Record ausschließlich nach der IPv6-Adresse eines Rechners fragt, muß ein Name-Server auf eine AAAA-Anfrage hin keine zusätzlichen Schritte ausführen.

Breite Auflösung

Analog zu IN-ADDR.ARPA für IPv4 gibt es auch für IPv6 eine inverse Domain: IP6.INT. Die Funktionsweise entspricht der der IN-ADDR.ARPA-Domain, allerdings mit einer Ausnahme: die Adressen werden in Nibbles, also 4-Bit-Stücken kodiert.

Es gibt DNS-Anfragen, in denen neben der Anfrage nach dem Namen eines Rechners, der einen bestimmten Dienst zur Verfügung stellt, zusätzlich nach der IP-Adresse dieses Rechners gefragt wird. Es handelt sich hierbei um die Anfragen nach einem Name-Server (Query-Typ NS), einem Mail Exchanger (Mail Relay, Query-Type MX) oder einer Mailbox (Query-Typ MB). Momentan sucht ein Name-Server nur nach den A-Records der entsprechenden Rechner und liefert somit nur die IPv4-Adressen zurück. Für IPv6-Netze ist ein solches Verhalten verständlicherweise nicht akzeptabel; der Name-Server muß neben den A-Records auch die AAAA-Records durchsuchen und dem Client gegebenenfalls die IPv6-Adressen der gesuchten Rechner übermitteln.

Benötigt das Betriebssystem eines Rechners die IP-Adresse zu einem Rechnernamen, so greift es auf den DNS-Client zurück, die Resolver-Bibliothek. Diese generiert die eigentliche DNS-Anfrage, schickt sie an einen Name-Server und liefert bei Erfolg die IP-Adresse oder andere Informationen (wie das Mail Relay einer Domain) zurück. Die Resolver-Bibliothek ist somit ein wichtiger Bestandteil des Domain Name System. Rechner, die sowohl über IPv4- als auch IPv6-Protokollstacks verfügen, müssen per Definition direkt mit IPv4- und IPv6-Rechnern kommunizieren können. Ihre Resolver-Bibliothek muß daher in der Lage sein, sowohl mit A-Records, die IPv4-Adressen enthalten, als auch mit AAAA-Records, in denen IPv6-Adressen kodiert sind, umzugehen.

Die nächste Stufe

Wird eine IPv4-kompatible IPv6-Adresse einem Rechner zugewiesen, der automatisches Tunneling unterstützt - also ohne Intervention des Bedieners oder Systemverwalters IPv6-Traffic in IPv4-Paketen kodiert -, so sind sowohl die IPv4- als auch die IPv6-Adresse dieses Rechners im DNS kodiert. Die IPv6-Adresse findet sich im AAAA-Record, die IPv4-Adresse, die aus den unteren 32 Bits der IPv6-Adresse besteht, ist im korrespondierenden A-Record gespeichert. Der AAAA-Record dient dazu, DNS-Anfragen von IPv6-Hosts zu befriedigen. Der A-Record ist für IPv4-Rechner vorgesehen, deren Resolver-Bibliothek ausschließlich mit IPv4-Adressen umgehen kann. Die Resolver-Bibliotheken dieser Rechner müssen sowohl A- als auch AAAA-Records auswerten können.

Neben dem eigenen Netz und dem Service-Provider läßt sich der Secondary Name-Server auch in einem völlig fremden Netz unterbringen.

Findet der Name-Server auf eine Anfrage hin einen AAAA-Record mit einer IPv4-kompatiblen Adresse und einen korrespondierenden A-Record, so kann der Resolver dem Anwendungsprogramm beide Adressen übergeben. Er kann jedoch auch entweder nur die IPv4-Adresse oder die IPv6-Adresse zurückliefern. Die Art der Adressen oder die Reihenfolge, in der sie übergeben werden, hat gegebenenfalls Auswirkungen auf die IP-Pakete, die generiert werden. Liefert der Resolver eine IPv6-Adresse zurück, so wird der Kommunikationspartner aller Wahrscheinlichkeit nach IPv6-Pakete, die in diesem Fall in IPv4-Paketen verpackt werden, verwenden. Handelt es sich um eine IPv4-Adresse, so wird der Verkehr über IPv4-Pakete abgewickelt.

Allerdings ist die Art und Weise, in der Resolver-Bibliotheken diese redundanten Records für IPv4-Adressen handhaben, davon abhängig, ob der Host automatisches Tunneling unterstützt und dieses aktiviert ist. So würde zum Beispiel eine DNS-Resolver-Implementation, die kein automatisches Tunneling bietet, keine IPv4-kompatiblen IPv6-Adressen zurückliefern. Ein solcher (IPv6-) Zielrechner ist schließlich generell nur über IPv6-Tunneling erreichbar. Eine Implementation, die automatisches Tunneling unterstützt, kann hingegen so konfiguriert sein, daß sie ausschließlich die IPv4-kompatible IPv6-Adresse zurückgibt.

Momentan gibt es keine frei verfügbare Name-Server-Software, in der IPv6 offiziell und vollständig unterstützt wird. Allerdings bietet die in der Unix-Gemeinde allseits beliebte, weil als De-facto-Standard angesehene BIND-Software, die kostenlos und im Quellcode verfügbar ist (http://www.isc.org/bind.html), einen latenten Support für IPv6. Latent deshalb, da die IPv6-Funktionen nicht dokumentiert sind, und die Funktionsparameter in den Zugriffen auf die API sich unter Umständen noch ändern. Der vorhandene Support für IPv6 ist daher mit Vorsicht zu genießen.

Geheimnummern

Obwohl das Domain Name System einer der für den täglichen Betrieb des Internet unentbehrlichen Bestandteile ist, bot es bis vor kurzem keinerlei Möglichkeiten, Transaktionen zu authentisieren und Domain- und Host-Daten vor Manipulationen zu schützen. Inzwischen haben die Verantwortlichen der Internet Engineering Task Force (IETF) die Notwendigkeit erkannt, das DNS um Sicherheitsmechanismen zu erweitern. Sie sollen die Integrität und Authentizität der Daten und Transaktionen sicherstellen [4].

RFC 2065 [5] beschreibt die Verfahren, mittels derer sich digitale Unterschriften in Form von Resource Records in das DNS integrieren lassen. Er beschreibt gleichzeitig die Voraussetzungen, die für ihre Nutzung auf DNS-Server- als auch Client-Seite gegeben sein müssen. Die Verwendung digitaler Unterschriften stellt sicher, daß der Ursprung einer Nachricht nachprüfbar ist. Auf diese Weise ist es möglich, die Sicherheitsmechanismen, die für das DNS vorgeschlagen wurden, auch für andere Protokolle zu nutzen.

Für Tippfaule: Die Suchreihenfolge für Domains erlaubt es, die Namen häufig besuchter Internet-Server abzukürzen.

Prinzipiell erfolgt die Erweiterung des DNS über die Einführung dreier zusätzlicher Resource Records:

SIG (Signature, Digitale Unterschrift) wird für Authentisierungszwecke benötigt,

KEY (Schlüssel) enthält öffentliche Schlüssel,

NXT (Non-existant) bestätigt, daß ein Name innerhalb einer Zone oder ein bestimmter Typ zu einem Namen nicht existiert.

Neben der Sicherung des eigentlichen DNS bieten die Records eine wichtige zusätzliche Dienstleistung. Sie ermöglichen den authentisierten Austausch öffentlicher Schlüssel, die sich zur Übermittlung von Session Keys im Rahmen der allgemeinen IP-Sicherheitsmechanismen einsetzen lassen. Damit wäre ein größeres Problem gelöst, nämlich das des authentisierten und abgesicherten Austausches initialer Schlüssel. Allerdings gilt auch für die Sicherheitsmechanismen des DNS, daß die Wahl des Verschlüsselungsalgorithmus, des Schlüssels, der Schlüssellänge et cetera entscheidenden Einfluß auf die Sicherheit des gesamten Systems hat [3]. Und nicht zuletzt kommt auch der Aufbewahrung der privaten Schlüssel eine besondere Bedeutung zu: Liegen sie offen, so kann jeder jede Nachricht lesen oder verfälschen.

Solange dies aber nicht passiert, wäre mit den neuen Möglichkeiten, das DNS abzusichern, auch Vorfälle ausgeschlossen, bei denen Unberechtigte einfach Domain-Registrierungen löschen. Die amerikanischen und deutschen Verwalter des Namens-Systems im Internet sind aber erst vor kurzem dazu übergegangen, solche Mechanismen zu implementieren - und alte Einträge in den Top-Level-Servern werden bislang nicht umgestellt.

Zu Sicherheitsproblemen im Rahmen von DNS lesen Sie bitte den Artikel auf S. 286. Den politischen und rechtlichen Problemen, die sich um das DNS im Internet ranken, wird sich ein Artikel in einer der kommenden Ausgaben widmen.(jk)

Literatur

[1] Jürgen Kuri, Wenn der Postmann zweimal klingelt, Namen und Adressen im TCP/IP-Netzwerk und im Internet, c't 12/96, S. 334

[2] Friedhelm Hosenfeld, Next Generation, Internet-Protokoll Version 6: ein neues Kommunikationszeitalter?, c't 11/96, S. 380

[3] Norbert Luckhardt, Qnf jne rvasnpu, tryy?, Kryptologische Begriffe und Verfahren, c't 12/96, S. 110

[4] Norbert Luckhardt, Schlüsselpositionen, Freiheiten, Risiken und Aussichten im Internet, c't 4/97, S. 234

[5] D. Eastlake 3rd, C. Kaufman, Domain Name System Security Extensions, RFC 2065, CyberCash, Iris, Januar 1997

[6] R. Hinden, S. Deering, IP Version 6 Addressing Architecture, RFC 1884, Ipsilon Networks, Xerox PARC, Dezember 1995

[7] P. Mockapetris, Domain Names - Concepts and Facilities, STD 13, RFC 1034, USC/Information Sciences Institute, November 1987

[8] P. Mockapetris, Domain Names - Implementation and Specification, STD 13, RFC 1035, USC/Information Sciences Institute, November 1987

[9]S. Thomson, Chr. Huitema, DNS Extensions to support IP version 6, RFC 1886, Bellcore, INRIA, Dezember 1995

[10] P. Vixie, Name Server Operations Guide for BIND, Release 4.9.5, Internet Software Consortium, 1996, http://www.isc.org/bind.html

Kasten 1

Direktiven und Ressourcen - die Konfiguration eines Name-Servers

Name-Server auf Unix-Maschinen (und alle davon abgeleitete oder portierte Software, etwa für OS/2) entnehmen ihre Daten der Startdatei named.boot sowie den Zonen-Dateien. Andere Systeme wie Windows NT können die Informationen mit anderen Methoden festhalten - die Software des Name-Servers ist dafür zuständig, trotzdem alle Angaben korrekt an die anfragenden Maschinen zurückzuliefern. Die Angaben über Zonen und die einzelnen Resource Records dürfen sich also nicht unterscheiden.

In der Konfiguration sind sämtliche für die Netzwerkanbindung relevanten Informationen über die Systeme innerhalb einer Domain gespeichert. Eine Zone bezeichnet in diesem Sprachgebrauch dann eine Verzweigung des DNS-Baums, die unabhängig administriert wird. Normalerweise sind das Domains unterhalb der Top-Level-Domains, diese können dann aber wiederum in kleinere Zonen (also Sub-Domains) unterteilt werden. Zonen-Dateien bestehen aus Direktiven, die dem Name-Server Anweisungen zur Interpretation der einzelnen Einträge geben, sowie aus Resource Records (den eigentlichen Informationsträgern).

Zwei Direktiven kommen in den Zonen-Dateien vor: $INCLUDE und $ORIGIN.

$INCLUDE [Dateiname] ermöglicht, Daten zur aktuellen Zone aus einer Datei zu laden und in die aktuelle Zone mit einzubinden. Es ist allerdings nicht möglich, mittels $INCLUDE in eine andere Zone zu wechseln.

$ORIGIN [Zonenbeginn] setzt explizit den Start einer Zone. Allerdings sollte diese Direktive mit Vorsicht eingesetzt werden, da es nicht möglich ist, mittels $ORIGIN in eine völlig andere Zone zu wechseln. Vielmehr dient sie dazu, am Anfang einer Zonen-Datei die Zone explizit zu setzen. Es ist damit auch möglich, in eine untergeordnete Zone überzuwechseln, also beispielsweise von wwwa.org. in test.wwwa. org., niemals aber in eine Zone auf der gleichen Ebene (etwa von wwwa.org. nach foobar.com.).

Endet ein Name in einem Resource Record übrigens nicht mit dem abschließenden Punkt, so wird der aktuelle Wert von $ORIGIN angehängt. Dieses Verhalten führt häufig zu unangenehmen Überraschungen, da der abschließende Punkt, der die root-Domain symbolisiert, nur allzu gerne vergessen wird.

Die Resource Records enthalten die eigentlichen Informationen für das DNS . Einige dieser Einträge müssen in einer Zonen-Datei enthalten sein, andere sind optional.

SOA-Records kennzeichnen den Beginn einer Zone, SOA steht dabei für Start of Authority. Für jede Zone gibt es daher auch nur einen SOA-Record. Er setzt einige Parameter, die für die gesamte Zone gültig sind:

Domain	IN	SOA	origin	contact 
	( 
	serial 
	refresh 
	retry 
	expire 
	minimum 
	)

Für die Domain `Uni-Augsburg.DE´ würde der SOA-Record also etwa folgendermaßen aussehen:

Uni-Augsburg.DE.	IN  SOA Kei.CC.Uni-Augsburg.DE. 
	root.Kei.CC.Uni-Augsburg.DE.	( 
	1996061201 ; Serial 
	10800 ; Refresh 3 Stunden 
	3600 ; Retry 1 Stunde 
	3600000 ; Expire 1000 Stunden 
	86400 ; Minimum 24 Stunden 
	)

Im ersten Feld des SOA-Records ist die Domain aufgeführt. Meist findet sich an dieser Stelle ein @, das für die aktuelle (vorher durch eine Direktive wie $ORIGIN gesetzte) Domain steht. Es folgt das IN für Internet, danach der Kenner für die Art des Records (SOA, Start of Authority). Im Feld origin steht der volle Domain-Name des verantwortlichen Name-Servers einer Domain. Es folgt die Adresse der Kontaktperson, die bei Problemen mit dem Name-Server zu benachrichtigen ist (dem Hostmaster). Um daraus die EMail-Adresse zu ermitteln, muß man den ersten Punkt durch ein @ ersetzen und den letzten Punkt streichen. Die EMail-Adresse von root.Kei.CC.Uni-Augsburg.DE. ist also root@Kei.CC.Uni-Augsburg.DE.

Im Feld serial steht die Seriennummer. Diese müssen bei jeder Modifikation erhöht werden, da andere Name-Server daran überprüfen, ob die zwischengespeicherten Daten noch korrekt und aktuell sind. Um Fehlkonfigurationen zu vermeiden, sollte man das Format [jahrmonattagversion] zu wählen. Version 01 vom 12.6.1996 würde also die Seriennummer 1996061201 ergeben. Bei Änderungen an einer Zonen-Datei ist grundsätzlich die Seriennummer zu erhöhen. Das Jahr soll übrigens vierstellig angegeben werden, um Probleme infolge des Jahrtausendwechsels zu umgehen.

Refresh gibt die Zeitdauer in Sekunden an, die der Secondary wartet, bevor er beim Primary anfragt, ob sich irgendwelche Zonendaten geändert haben. Es kommt vor, daß der Primary nicht erreichbar ist. In diesem Fall versucht der Secondary es zu einem späteren Zeitpunkt noch einmal. Diese Zeitdauer läßt sich im Feld retry einstellen. Kommt es während einer Zeitdauer, die den Expire-Wert überschreitet, zu keinem Refresh, so verwirft der Secondary die von ihm gespeicherten Zonendaten. Der Wert im Minimum-Feld des SOA-Records gibt die sogenannte Time-to-Live an, die ein Record im Cache eines nicht lokalen Servers gehalten werden soll. Der Minimum-Wert ist nur von Interesse, wenn keine explizite Time-to-Live im entsprechenden Resource Record angegeben ist. Die Werte aus den Beispielen sind für schnelle Netzwerkanbindungen (zum Beispiel Ethernet, T1, E1 oder schneller) gedacht. Existiert nur eine langsame Anbindung an das Internet, so lassen sich die Intervalle vergrößern.

NS-Records definieren einen Name-Server für eine Domain oder Sub-Domain, und zwar im Format:

Domain	IN	NS 	Name-Server

Dabei müssen Domain und Name-Server als Fully Qualified Domain Names angegeben werden, also beispielsweise:

WWWA.ORG.	IN	NS	Kei.CC.Uni-Augsburg.DE.

Kei.CC.Uni-Augsburg.DE. ist also der Name-Server für die Domain WWWA. ORG. Jede Domain (und Sub-Domain) benötigt übrigens mindestens zwei Name-Server.

A-Records übernehmen die Abbildung von Hostnamen auf IP-Adressen, und zwar im Format:

Name	IN	A	IP-Adresse

Für Name lassen sich FQDNs einsetzen und auf diese Weise Konfigurationsfehler ausschließen. Außerdem sind relative Hostnamen zulässig. Dafür muß allerdings die Default-Domain korrekt gesetzt sein. Findet sich keine entsprechende $ORIGIN-Direktive, so entnimmt der Server den Domain-Namen der Datei `/etc/ named.boot´ (er steht dort in der primary-Direktive):

Kei.CC.Uni-Augsburg.DE.	IN	A	137.250.1.1 
$ORIGIN WWWA.ORG. 
Deirdre	IN	A	192.107.123.3

Der erste A-Record benutzt einen FQDN, der zweite einen relativen Hostnamen.

PTR-Records bilden IP-Adressen auf Hostnamen ab. Sie finden sich in den Zonendateien, die die IN-ADDR.ARPA-Zonen einer Domain implementieren. Die Wichtigkeit der PTR-Records ist nicht zu unterschätzen - viele Dienste, zum Beispiel FTP, verlangen die Eingabe einer EMail-Adresse und bedienen sich dann eines Systemaufrufes, um den zur IP-Adresse gehörigen Hostnamen in Erfahrung zu bringen. Liefert der Systemaufruf keinen akzeptablen Wert zurück, so verweigern diese Dienste den Zugriff. Ein PTR-Record hat die Form:

$origin	107.123.192.IN-ADDR.ARPA. 
3.	IN	PTR	Deirdre.WWWA.ORG. 
oder alternativ: 
3.107.123.192.IN-ADDR.ARPA.	IN	PTR\
Deirdre.WWWA.ORG.

Ein PTR-Record enthält also die 4 Bytes der IP-Adresse in umgekehrter Reihenfolge, gefolgt von dem Anhängsel .IN-ADDR. ARPA, sowie den FQDN des Host. Auch hier ist unbedingt auf den abschließenden Punkt zu achten. Um Tipparbeit zu sparen und die Datei übersichtlicher zu gestalten, bietet es sich bei PTR-Records an, den Zonenbeginn mittels $origin explizit zu setzen. Auch ist dann das Einrichten einer Sub-Domain weniger mühsam.

MX-Records definieren einen Mail Exchanger für einen bestimmten Rechner oder eine Domain. Dabei handelt es sich um einen Rechner, der EMail entgegennimmt:

Name (ttl) 	IN	MX	 Präferenz 	Mail-Exchanger 
deirdre.WWWA.ORG.	IN	MX	25\	deirdre.WWWA.ORG. 
*.WWWA.ORG.	IN	MX	50\
Kei.CC.Uni-Augsburg.DE.

Für jeden Rechner, der EMail entgegennehmen kann, sollte ein MX-Record angelegt werden, da ansonsten bei der Auslieferung von EMail implizit ein MX-Record mit der Präferenz 0 angelegt wird. Meines Erachtens ist es besser, den MX explizit zu setzen, als ihn durch einen nicht-lokalen Mailer implizit setzen zu lassen. Mail Exchanger mit niedriger Präferenz werden gegenüber denen mit höherer Präferenz bevorzugt. Bei gleicher Präferenz entscheidet der Zufall, über welchen Mail Exchanger die Mail ausgeliefert wird. Näheres hierzu findet sich in RFC 974. In Verbindung mit MX-Records ist die Benutzung von Wild Cards zulässig. Ein Klammeraffe (@) in einem MX-Record steht für die aktuelle Domain oder Sub-Domain, die mittels $origin gesetzt werden kann. Ein Sternchen (*) bezeichnet alle Hosts innerhalb einer Domain. Der MX-Record

$origin WWWA.ORG.

(hier stände dann ein SOA-Record)

@	IN	MX	50	Kei.CC.Uni-Augsburg.DE.

definiert einen Mail Exchanger für die Domain WWWA.ORG. In diesem Beispiel übernimmt Kei.CC.Uni-Augsburg.DE. die Rolle des Mail Relay für die WWWA-Domain. Deirdre.WWWA.ORG. soll die Mail jedoch direkt annehmen. Hierzu dient der MX-Record

Deirdre.WWWA.ORG.	IN	MX	10
Deirdre.WWWA.ORG.

CNAME-Records (Canonical Name Resource Record) definieren einen Alias zu einem offiziellen, kanonischen Hostnamen. Der CNAME-Record sollte der einzige Resource-Record sein, in dem der Alias erwähnt wird. Resource-Records, die einen Domainnamen enthalten (wie zum Beispiel NS- oder MX-Records) dürfen sich nicht des Alias bedienen, sondern müssen auf den offiziellen Hostnamen zurückgreifen. CNAME-Records lassen sich vor allem dann einsetzen, wenn der Hostname eines Rechners geändert werden soll. Der Alias kann dann auf den alten Namen verweisen und den Benutzern so die Umstellung erleichtern:

ftp.CC.Uni-Augsburg.DE	IN	CNAME\
	Kei.CC.Uni-Augsburg.DE.

WKS-Records geben Auskunft über die Dienste, die ein Rechner im Netz für ein bestimmtes Protokoll (UDP oder TCP) anbietet. Die Liste der Dienste entstammt der Datei /etc/services. Pro Host und Protokoll sollte es nur einen WKS-Record geben:

deirdre.WWWA.ORG.	IN	WKS\ 
192.107.123.3	UDP	route timed

	IN	WKS\
192.107.123.3	TCP	ftp smtp

Da WKS-Records nicht allzu häufig verwendet werden, sollte man sich nicht darauf verlassen, daß ein Rechner, zu dem kein WKS-Record existiert, einen Dienst nicht anbietet. Statt dessen sollte man lieber ausprobieren, ob der gewünschte Dienst verfügbar ist (s. hierzu RFC 1123).

HINFO-Records (Host Information Records) enthalten hostspezifische Daten wie etwa die Hardware des Rechners und sein Betriebssystem. Sind Leerzeichen in der Typbezeichnung erwünscht, so sind Anführungszeichen notwendig:

Kei.WWWA.ORG.	IN	HINFO	`Sun 4/280´\
`SunOS 4.1.1´

Aus Sicherheitsgründen verzichten viele Organisationen auf HINFO-Records in ihren Name-Servern. Sie sind zum ordnungsgemäßen Betrieb einer Domain auch nicht erforderlich.

TXT-Records enthalten frei wählbaren Text. Auf einigen Systemen dient ihr Inhalt dazu, Verwaltungsdaten zu kodieren.

Alle Name-Server unterstützen die bislang erwähnten Resource Records. Für die folgenden gilt dies nicht, nur einzelne Implementationen stellen sie zur Verfügung.

RP-Records (Responsible Person Records) benennen Eine Person oder eine Gruppe von Personen, die für einen Rechner und seinen ordnungsgemäßen Betrieb verantwortlich sind. Sie ermöglichen damit, bei einem Rechnerausfall Kontakt mit den Verantwortlichen aufzunehmen und die Ausfallzeiten zu minimieren:

jones	IN	RP	jones.kei.cc.uni-augsburg.de.\	
admins.cc.uni-augsburg.de.

Das erste Feld (jones.kei.cc.uni-augsburg.de.) verweist auf die Mailbox, an die Nachrichten zu schicken sind. Das Feld ist analog dem contact-Feld des SOA-Records aufgebaut, die zugehörige EMail-Adresse lautet also jones@kei.cc.uni-augsburg.de. Steht in diesem Feld ein einfacher Punkt (.), so bedeutet dies, daß keine Mailbox verfügbar ist. Das zweite Feld, admins.cc.uni-augsburg.de., ist ein Domain-Name, für den TXT-Records verfügbar sind. Diese lassen sich in einer nachfolgenden Anfrage anzeigen und können Telefonnummern und ähnliches der Verantwortlichen enthalten. Steht in diesem Feld ein Punkt (.), so sind ebenfalls keine Informationen verfügbar. Sinn dieses Records ist, einen indirekten Verweis auf einen Verantwortlichen zu schaffen, da im Falle eines Rechnerausfalls der direkte Weg häufig versperrt ist - ein abgestürzter Rechner empfängt keine EMail.

AFSDB-Records verweisen auf Rechner, die Dienste für das AFS (Andrew File System) oder DCE (Distributed Computing Environment) bereitstellen:

wwwa.org.	IN	AFSDB	1	afs.wwwa.org.

wwwa.org.	IN	AFSDB	2	dce.wwwa.org.

Die Ziffer gibt an, welche Art von Dienstleistung der entsprechende Host bereitstellt. Eine `1´ steht für den AFS-Datenbank-Server einer AFS-Zelle innerhalb des angegebenen Domain-Namens. Eine `2´ gibt an, daß der Server für die angegebene DCE-Zelle einen internen Namensdienst bereitstellt. Der AFSDB-Resource Record ist in RFC1183 näher beschrieben; er befindet sich immer noch im Experimentalstadium und wird längst nicht von allen Name-Servern implementiert.

PX-Records dienen dazu, X.400-Adressen auf RFC822-konforme Adressen abzubilden. Auch dieser Record ist im Experimentalstadium und wird nur von wenigen Name-Servern unterstützt. Eine umfassende Beschreibung dieser Records steht in den RFCs 1327 und 1664.

Kasten 2

Das große Schweigen - wenn der Name-Server nicht antwortet

Es ist ja eine feine Sache, daß niemand sich IP-Adressen merken muß, um einen Rechner im Internet anzusprechen. Der Name www.heise.de läßt sich schließlich viel einfacher merken als die Ziffernfolge 194.54.43.34. Was aber tun, wenn kein Name-Server zur Verfügung steht?

Am einfachsten ist es sicher noch, wenn man sich irgendwo die IP-Nummern zu den wichtigsten Servern notiert hat, mit denen man regelmäßig Kontakt aufnimmt. Selbst wenn ein vorhandener Name-Server nicht erreichbar ist oder, wie vor kurzem in den USA passiert, durch einen Fehler des Betreibers ausfällt, läßt sich jeder Rechner im Internet über seine IP-Adresse direkt ansprechen. Dies funktioniert auch dann, wenn etwa die Name-Server der Top-Level-Domains ausgefallen sind. Erst wenn die Router nicht funktionieren, die den Datenverkehr weiterleiten, geht gar nichts mehr.

Die beste Möglichkeit, die zu den Host-Namen passenden IP-Adressen festzuhalten, ist die Datei hosts auf dem lokalen Rechner. Unter Unix steht sie im Verzeichnis /etc, unter Windows 95 im Verzeichnis \windows des Bootlaufwerks, unter Windows NT im Verzeichnis \WINNT\system32\drivers\etc des Bootlaufwerks. Unter OS/2 findet sie ihren Platz seit OS/2 Warp Connect im Verzeichnis \MPTN\ETC des Bootlaufwerks. Das Format der Einträge ist recht einfach:

IP-Adresse		Host-Name

Mehr ist im Normalfall nicht notwendig. Unter OS/2 muß allerdings in der TCP/IP-Konfiguration zusätzlich ausgewählt werden, daß die Hosts-Datei zuerst durchsucht werden soll.

Man sollte aber nicht jeden beliebigen Server in diese Datei eintragen - wird sie zu groß, kann der Zugriff auf die Server langsamer erfolgen als bei einer Name-Server-Abfrage.

Es ist auch recht einfach, die IP-Adresse für einen Host herauszubekommen. Solange ein Name-Server verfügbar ist, reicht ein einfaches ping auf den Host-Namen, da bei der Antwort die IP-Adresse angegeben wird:

G:\>ping www.heise.de 
PING wird ausgeführt für www.heise.de [194.122.76.131] mit 32 Bytes Daten: 
Antwort von 194.122.76.131: Bytes=32 Zeit=151ms TTL=247

Im Zweifelsfall kann man unter NT, OS/2 und Unix den Name-Server mit nslookup auch direkt abfragen:

G:\>nslookup www.heise.de 
Server:  idgie.heise.de 
Address:  192.54.43.34 
    www.heise.de 
Address:  194.122.76.131

Beides funktioniert natürlich nur solange, wie ein Name-Server zur Verfügung steht. Aber selbst, wenn der Server einer Top-Level-Domain ausgefallen ist, hat man noch einige Zeit (meist einige Stunden) die Chance, den Name-Server einer Sub-Domain oder der lokalen Domain abzufragen, da die Daten ja zwischengespeichert werden.

Für die Konfiguration von TCP/IP ist es, unabhängig von den Einträgen in der Hosts-Datei, übrigens sinnvoll, die Suchreihenfolge für Domainsuffix in der Netzwerkkonfiguration anzugeben (unter OS/2 heißt der entsprechende Eintrag Domänen-Suchliste in der TCP/IP-Konfiguration). Hier trägt man nicht komplette Host-Namen ein, sondern nur den Teil, der eine Domain, bezeichnet, also etwa heise.de. Danach kann man einen Host in der entsprechenden Domain über seinen Host-Namen, ohne Angabe der Domain, ansprechen. Die Einträge sind nach Priorität sortiert, der erste Eintrag wird also auch als erster probiert.