Hintergrund: Microsoft, das Internet und die Namen

Die Router-Konfigurationsfehler von Microsoft-Technikern und die DoS-Attacken auf Microsofts Router, die das IP-Netz mit den DNS-Servern ans Internet bringen, rücken ein viel benutztes, aber oftmals wenig beachtetes System ins Blickfeld der Öffentlichkeit: Das Domain Name System (DNS). Anscheinend haben sich bei der Popularisierung des Internet selbst bei großen Firmen Schlampigkeiten eingeschlichen, die das Funktionieren des DNS zumindest in Teilbereichen in Frage stellen können. Dabei sind für viele Nutzer inzwischen die Web-Adressen, meist aussagekräftig selbst für den Inhalt der entsprechenden Seiten, inzwischen zum Internet selbst geworden – auch wenn das Netz aus vielen anderen Diensten neben dem Web besteht.

Das DNS ist dabei, ungeachtet aller Markenrechtstreitigkeiten um Domain-Namen in der letzten Zeit, ursprünglich als reines Hilfsmittel entstanden. Ob IP-Adressen nun statisch eingetragen oder dynamisch über DHCP vergeben werden, sie sind nicht gerade die bequemste Methode, andere Rechner im Netz anzusprechen. Glücklicherweise entwickelte sich schon früh ein Namenssystem, das die Erinnerung an bestimmte wichtige Rechner einfacher macht, oft sogar Hinweise ermöglicht, unter welcher Bezeichnung Rechner zu finden sind. Jedem Rechner im TCP/IP-Netz kann ein Name zugewiesen werden, der prinzipiell frei wählbar ist. Er hat zwar grundsätzlich nichts mit der IP-Adresse der Maschine, beziehungsweise ihres Netzwerk-Interface zu tun, wird aber durch bestimmte Mechanismen auf sie abgebildet, sodass die Anwendungsschicht anhand des Namens die IP-Adresse ermitteln kann. Nur diese wird dann auf der Protokollebene zur weiteren Kommunikation benutzt.

Rudimentär

Am einfachsten erscheint es, eine schlichte Textdatei zu erstellen, in der die Host-Namen und zugehörigen IP-Adressen der Rechner festgehalten sind, mit denen eine Kommunikation notwendig oder erwünscht ist. Diese Textdatei existiert auch heute noch. Steht kein Name-Server zur Verfügung, oder benötigt man für ein kleineres Netz nicht ein komplettes Name-Server-System, kann man die Verbindung zwischen Host-Namen und IP-Adressen auch über die Datei hosts herstellen, in der einfach Zeile für Zeile jeweils ein Host-Name und die zugehörige Adresse festgehalten werden. Selbst für das Internet wurde zu Beginn, als es noch etwas überschaubarer war, auf diese Weise vorgegangen – das Network Information Center hielt eine zentrale hosts-Datei vor, die auf alle Rechner im Internet kopiert wurde, und alle neuen Hosts mussten erst in diese Datei eingetragen werden.

Dies ist natürlich auf Dauer unpraktikabel. Zum einen muss durch die reine Tabellenform der Datei jeder Host einen eindeutigen Namen haben, doppelte Namen, wie sie in einer hierarchischen Struktur möglich sind, durften nicht auftauchen. Vor allem aber wurde die Verwaltung einer solchen Datei bei wachsender Zahl von Hosts im Internet unmöglich. Weder konnte die Konsistenz und Eindeutigkeit gewährleistet werden, noch die Aktualität der gespeicherten Informationen. Eine Lösung für die Zuordnung von Host-Namen zu IP-Adressen brachte erst das DNS (Domain Name System oder Domain Name Service), festgehalten im RFC 1035.

Grundlage ist eine hierarchisch organisierte, verteilte und replizierte Datenbank, in der der mögliche Namensraum in aufteilbaren Einheiten organisiert ist. Diese Domains können, von einem Root ausgehend, zum einen separat verwaltet werden. Zum anderen sind Sub-Domains erlaubt, die wiederum an untergeordnete Stellen zur Verwaltung weitergegeben werden können. Durch die Aufteilung in voneinander getrennte Namensräume lassen sich auch Host-Namen beliebig oft vergeben, solange sie jeweils in getrennten Domains oder Sub-Domains liegen.

Ausgangspunkt für die DNS-Struktur im Internet sind die so genannten Top-Level-Domains. Dazu gehören unter anderem mil (für militärische Einrichtungen der amerikanischen Regierung), gov (für sonstige Einrichtungen der amerikanischen Regierung), edu (für Ausbildungsinstitutionen in den USA) oder com (für kommerzielle Unternehmen). Dazu kommt int (für internationale Organisationen. Erst Ende letzten Jahrs beschloss die ICANN die Einführung sieben zusätzlicher Top Level Domains: Im Laufe dieses Jahres sollen auch die TLDs biz, info, pro, name, aero, museum und coop verfügbar sein.

Zusätzlich wurden Länder-Domains eingerichtet, darunter auch de für Deutschland. Unterhalb dieser Top-Level-Domains können Unternehmen oder Institutionen ihre eigenen Sub-Domains erhalten. So hat der Heise-Verlag die Domain heise.de, die für bestimmte Zwecke nochmals unterteilt ist, etwa in ct.heise.de. Die Verwaltung der Sub-Domains muss nicht von einer zentralen Stelle aus erfolgen, sondern kann an die Sub-Domains selbst delegiert werden. Auf der anderen Seite muss bei einer Delegierung nicht automatisch jede Sub-Domain eine eigene Verwaltung erhalten. Sie können in so genannte Zonen zusammengefasst werden, sodass die Verwaltung mehrerer Sub-Domains einer Domain über diese Zone erfolgt. Die Sub-Domains sind nicht etwa zwangsweise mit einem bestimmten IP-Netz verbunden, eine Sub-Domain kann prinzipiell diverse IP-Netze unterschiedlicher Klassen enthalten. Die Umsetzung zwischen Namen und Adresse ist eine willkürliche Festlegung, die nur durch die Einträge in der Datenbank der Name-Server gültig wird.

Vermittlungsstelle

Nicht nur auf Grund einfacher Verwaltung ist es sinnvoll, die DNS-Datenbank zum einen auf mehrere Server zu verteilen, zum anderen nach logischen Gesichtspunkten zu segmentieren. Es ist nicht notwendig, dass der Root-DNS-Server die Umsetzung zwischen Host-Namen und IP-Adressen aller beteiligter Rechner erledigt. Root-Server für das DNS im Internet gibt es inzwischen 13 Stück (a bis m), die praktisch auf der ganzen Welt verteilt sind, auch wenn die Merhheit noch in den USA steht. Den a-Root-Server verwaltet Network Solutions, der ehemaligen Monopolisten für die TLD-Registrierung; er steht noch unter Oberaufsicht des US-amerikanischen Department of Commerce.

Ein DNS-Server in einer Sub-Domain kann alle Namen dieser Sub-Domain verwalten und Verweise auf andere Server enthalten, die bei Anfragen nach Hosts in anderen Namensräumen abgefragt werden. Zudem kann die Datenbank auf mehrere Maschinen verteilt werden, sodass nicht ein Server alle Anfragen beantworten muss, sondern je nach Netzwerklast der Server abgefragt werden kann, der die gewünschten Informationen am schnellsten liefert.

Um alle diese Aufgaben erfüllen zu können, sind in der DNS-Datenbank nicht nur Host-Namen und IP-Adressen festgehalten. Sie ist in Resource Records organisiert, die je nach Typ unterschiedliche Informationen liefern. Es gibt inzwischen unzähöige verschiedene Typen von Resource Records, die wichtigsten davon sind bis heute:

• Address Record (A): ein Datensatz, in dem der eigentliche Zusammenhang zwischen Host-Name und IP-Adresse festgehalten ist, sodass man vom Namen auf die Adresse kommt.
• Name Server Record (NS): der zuständige Name-Server für eine bestimmte Domain wird in diesem Datensatz angegeben.
• Pointer Record (PTR): die Umkehrung des Address Records ermöglicht die Auffindung eines Host-Namens anhand einer IP-Adresse.
• Mail Exchange Record (MX): über MX-Records können Hosts definiert werden, die für andere Hosts Mail entgegennehmen, etwa weil sie nicht ständig mit dem Netz verbunden sind (die Auslieferung von Mail über UUCP benötigt beispielsweise diese MX-Records).
• Canonical Name Record (CNAME): für einen Host im Netz kann ein Alias vereinbart werden, etwa um den eigentlichen Rechner unter einem für bestimmte Zwecke aussagekräftigeren Namen ansprechen zu können. Der Canonical Name ist der eigentliche Name des Hosts.
• Host Information Record (HINFO): in der DNS-Datenbank können über diesen Datensatz Informationen über Rechnertyp und Betriebssystem des Hosts festgehalten werden.

Prinzipiell sind beliebige Erweiterungen der Resource Records möglich, sie müssen allerdings von der jeweiligen DNS-Software auch unterstützt werden. Soll ein DNS-Server im Internet aktiv sein, kann er zwar über die offiziellen Standards hinausgehende Resource Records anbieten, sie werden aber nur genutzt, wenn andere DNS-Server diese Typen kennen. So wurde beispielsweise für IP Version 6 ein weiterer Record definiert, AAAA oder Quad-A, der dem Address Record für IP4 entspricht. Er wird wie der A-Record die zu einem Host-Namen gehörende IP6-Adresse eines Rechners enthalten – sobald IP6 größere Verbreitung findet und die DNS-Server aktualisiert wurden.

Darüber hinaus existieren vier verschiedene Typen von DNS-Servern:

• Ein Primary Server 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 so genannten Zonen-Dateien abgelegt, die der Verwalter des Servers erstellt.
• Ein Secondary Server 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 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 muss 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, dass er zur Beantwortung von Anfragen zu einer Domain nicht autorisiert ist.
• 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.

Es ist nicht zwingend notwendig, dass in jedem Netz, in dem mit Host-Namen gearbeitet wird, auch ein DNS-Server existiert. Ist dieses Netz mit dem Internet oder einem anderen Netz verbunden, können die DNS-Anfragen der Clients auch dorthin umgeleitet werden. Diese Umleitung der Anfragen ist schließlich auch notwendig, wenn die IP-Adresse, die zu einem bestimmten Host gehört, in den Tabellen des lokalen DNS-Servers nicht bekannt ist und auch nicht in seinem Cache steht. Anforderungen, die der DNS-Server nicht auf Grund seiner eigenen Informationen beantworten kann, leitet er an die Server weiter, die in seinen Tabellen im NS-Record als zuständig angegeben sind.

Teile und funktioniere...

Auf Grund der langen Geschichte des DNS gibt es natürlich bereits einige Erfahrungen, wie einzelne Server arbeiten sollten, beziehungsweise wie eine Netzwerkstruktur mit DNS-Servern aussehen sollte, um sie möglichst zuverlässig zu machen, ohne unnötigen Datenverkehr im Internet zu produzieren. Sie sind zum Beispiel im RFC 2182 Selection and Operation of Secondary DNS Servers zusammengefasst. Darin heißt etwa schon in der Einführung: "Eine Reihe von Problemen im DNS-Betrieb heutzutage sind auf die schlechte Auswahl von Secondary-Servern für DNS-Zonen zurückzuführen. Die geographische Platzierung ebenso wie die Mannigfaltigkeit der Netzwerk-Verbindungen, die durch den Satz an DNS-Servern einer Zone an den Tag gelegt werden, kann die Zuverlässigkeit dieser Zone erhöhen und zudem die allgemeine Netzwerk-Performance und die Zugriffscharakteristiken verbessern."

Weiter führen die Autoren aus: "Ein Hauptgrund für mehrere Server in jeder Zone ist die Möglichkeit, dass die Informationen für diese Zone breit und zuverlässig für Clients im ganzen Internet verfügbar sind – also in der ganzen Welt –, selbst wenn ein Server nicht verfügbar oder nicht erreichbar ist. [...] Server sollten so platziert werden, sodass aller Wahrscheinlichkeit nach wenigstens ein Server für alle relevanten Teile des Internet erreichbar ist, und zwar bei jedem möglichen Fehler. Konsequenterweise ist es keine gute Vorgehensweise, alle Server an einem Ort zu platzieren, auch wenn dies einfach einzurichten und zu verwalten ist. [..] Secondary Server sollten sowohl von der Topologie als auch von der Geographie her an verstreuten Positionen im Internet platziert werden, um die Wahrscheinlichkeit zu verringern, dass ein einzelner Fehler sie alle nicht mehr verfügbar macht."

Dies hat sich Microsoft offensichtlich nicht zu Herzen genommen – immerhin erklärte der zuständige IT-Manager des Konzerns, Rick Devenuti, inzwischen, man habe aus den Angriffen und Konfigurationsfehlern gelernt und werde die Netzwerk-Infrastruktur ändern.

Literatur

RFC 2182, Selection and Operation of Secondary DNS Servers, ftp://ftp.isi.edu/in-notes/rfc2182.txt

RFC 1912, Common DNS Implementation Errors and Suggested Fixes, ftp://ftp.isi.edu/in-notes/rfc1912.txt

RFC 1591, Domain Name System Structure and Delegation, ftp://ftp.isi.edu/in-notes/rfc1591.txt

RFC 2181, Clarifications to the DNS Specification, ftp://ftp.isi.edu/in-notes/rfc2181.txt

RFC 1123, Requirements for Internet Hosts – Application and Support, ftp://ftp.isi.edu/in-notes/rfc1123.txt

RFC 1035, Domain Names – Implementation and Specification, ftp://ftp.isi.edu/in-notes/rfc1035.txt

RFC 1034, Domain Names – Concepts and Facilities, ftp://ftp.isi.edu/in-notes/rfc1034.txt

Wenn der Postmann zweimal klingelt, Namen und Adressen im TCP/IP-Netzwerk und im Internet, c't 12/1996, S. 334

Filofax fürs Internet, Der Domain Name Service von TCP/IP, c't 10/1997, S. 346

Felix von Leitner, DNS, http://www.fefe.de/dns/dns.pdf (jk)