5KHLQLVFK:HVWIlOLVFKH7HFKQLVFKH+RFKVFKXOH$DFKHQ. Lehrstuhl für Informatik IV Dr. rer. nat. Otto Spaniol 'RPDLQ1DPH6\VWHP

Transkript

1 5KHLQLVFK:HVWIlOLVFKH7HFKQLVFKH+RFKVFKXOH$DFKHQ Lehrstuhl für Informatik IV Dr. rer. nat. Otto Spaniol 'RPDLQ1DPH6\VWHP Proseminar: Internetprotokolle für die Multimediakommunikation Wintersemester 02/03 Matthias Sondermann Matrikelnummer Betreuung: Ralf Wienzek Lehrstuhl für Informatik IV, RWTH Aachen 1

2 ,QKDOWVYHU]HLFKQLV Kapitel 1± Grundlagen 1.1 Die IP-Adresse Der Namensraum... 3 Kapitel 2 Motivation und Idee des DNS 2.1 Motivation Entwicklung und Geschichte Idee und Struktur des DNS... 7 Kapitel 3 Die Aufgaben des DNS 3.1 Name Resolution Load Balancing Reverse Lookup Alias Hostname Alias Hostname für Mail-Server... 9 Kapitel 4 Aufbau und Funktionsweise des DNS 4.1 Der Name-Server DNS-Requests DNS-Caching DNS-Records DNS-Nachrichten Kapitel 5 Beispiele zur Namensauflösung 5.1 Einfaches Beispiel Komplexes Beispiel Kapitel 6 Zusammenfassung und Ausblick Literaturverzeichnis

3 *UXQGODJHQ 'LH,3$GUHVVH Die,nternetSrotokolladresse IPv4 besteht aus 32 Bit und wird in der 'RWWHG 4XDG1RWDWLRQ w.x.y.z dargestellt, wobei w,x,y,z p^ `. Damit lassen sich theoretisch 2 32 = verschiedene Adressen bilden. Die Adresse ist hierarchisch aufgebaut, so dass man von links nach rechts gelesen immer genauere Informationen über den Ort des Hosts erfährt. Allgemeiner ausgedrückt besteht die IP-Adresse aus zwei Teilen - einer Netzwerkadresse und einer Hostadresse. Da die Netzwerkadresse Teil der IP-Adresse ist, kann zwischen externen und internen Adressen unterschieden werden. Die Adressbereiche sind gemäß ihrer Größe in 3 Klassen A,B,C unterteilt. Dazu kommt noch ein reservierter Bereich für Multicast und ein bisher nicht genutzter Bereich. So kann z.b. geregelt werden, dass auch nur große Netze (Universitäten oder Unternehmen) auch einen großen Adressbereich zugewiesen bekommen. Für eine detaillierte Betrachtung sei auf [RFC1466, CN] verwiesen. Die Vergabe von Adressbereichen an Organisationen geschah bis einschließlich 1998 durch die Internet Assigned Numbers Authority (IANA), die den gesamten IP- Adressraum verwaltete und z.b. auch dafür sorgte, dass es zu keiner doppelten Vergabe von IP-Adressen kommt. Durch eine Umstrukturierung und vor allem Neugründung der Internet Corporation for Assigned Names and Numbers (ICANN) ist diese Aufgabe weitergegeben worden. Da die Anzahl der IP-Adressen schon heute nicht mehr ausreicht und auch die Vergabe von so genannten dynamischen Adressen das Problem nur kurzfristig löst, wurde die Länge der Adressen im Internet Protokoll Version 6 auf 128 Bit erhöht. IPv6 soll in naher Zukunft IPv4 ablösen und ist im Moment in Planung und Testphase. 'HU1DPHQVUDXP Für den Menschen ist es einfacher Namen statt Zahlen zu merken. Aus diesem Grund wurde der Namensraum entwickelt. Dabei sind alle Hostnamen in einer Hierarchie von Domänen (engl. Domains) organisiert, die als Folge von alphanumerischen Segmenten durch Punkte getrennt notiert werden. Durch diese Schreibweise ist es möglich, falls der Name geeignet gewählt ist, sehr einfach, den Standort bzw. die Organisation des beschriebenen Rechners zu identifizieren, z.b. alpha.lehrstuhl1.informatik.rwth-aachen.de. Wird die Adresse von rechts nach links gelesen - man beachte die Leserichtung im Vergleich zur IP-Adressen - erhält man immer genauere Informationen über Standort bzw. Zugehörigkeit des Hosts z.b. Land - Universität - Fachbereich - Institut Rechner. Im obigen Beispiel wurde der Name des Hosts 'alpha' vor den Domänennamen gesetzt, so dass diese Adresse den Rechner weltweit eindeutig identifiziert. Man spricht deshalb auch von einem )XOO\4XDOLILHG'RPDLQ1DPH (FQDN). Eine Ausnahme hierbei besteht darin, dass besonders wichtige bzw. hochfrequentierte Rechner repliziert werden und somit mehrfach existieren (siehe Abschnitt 3.2). 3

4 Je nach Position in der Hierarchie bezeichnet man eine Domäne als top-level, second-level oder sogar third-level. Speziellere Unterteilungen sind denkbar aber unüblich. Top-Level-Domänen TLD sind standardisiert und werden von der ICANN und den einzelnen Staaten verwaltet. Sie bilden die gröbste Einteilung im Namensraum, wobei es geographische (country coded TLD - cctld) und sachliche (generic TLD - gtld) Unterteilungen gibt. Die ICANN ist für folgende Domänen zuständig: com edu gov int mil net org kommerzielle Organisationen - z.b.: Bildungseinrichtungen - z.b.: Amerikanische Regierungsbehörden - z.b.: internationale Organisationen - z.b.: militärische Einrichtungen (USA) - z.b.: Netzbetreiber- und anbieter - z.b.: nichtkommerzielle Organisationen - z.b.: Seit einiger Zeit wird wegen der großen Nachfrage nach Domänen darüber diskutiert, neue generic Top-Level-Domänen einzuführen. Die Inbetriebnahme folgender sieben Domänen ist seit Ende 2000 beschlossenen, weitere, wie z.b..web,.shop oder auch.firm, sollen in nächster Zeit folgen: aero biz coop info museum name pro Luftfahrtindustrie kommerzielle Organsiationen / Unternehmen Genossenschaftliche Einrichtungen keine gesetzliche Einschränkung Museen und Austellungen Privatpersonen, Privathomepages Ärzte, Anwälte und Steuerberater Zusätzlich zu den oben genannten Top-Level-Domänen besitzt jedes Land seine eigene Domäne (cctld), die ausschließlich aus zwei Buchstaben besteht. Dies wird durch den Standard ISO-3166geregelt [RFC1591, ISO3166]. So steht beispielsweise GH für Deutschland, IJ für Französisch-Guiana und PX für Mauritius, was aber nicht zwingend heißen muss, dass der Rechner mit einer landeseigenen TLD auch in diesem Land steht. Zuständig für Vergabe und Verwaltung ist das Network Information Center (NIC) sowie seine nationalen Ableger. Einige Staaten, wie z.b. Australien, benutzen zusätzlich Second-Level- Domänen, die sich sehr stark an den vom ICANN verwendeten Top-Level- Domänen orientieren. Folglich findet man dort Adressen wie oder Die für Deutschland zuständige DeNIC nimmt diese Möglichkeit jedoch nicht in Anspruch. Deshalb sind z.b. Bildungseinrichtungen nicht ohne weiteres am Domänennamen erkennbar. Dies erfordert eine verständliche und exakte Namensgebung, die sich unter Umständen in der Länge der Adresse widerspiegelt. 4

5 Bei den zuständigen Organisationen unbeliebt aber mit zunehmender Anzahl genutzt, ist der Missbrauch von country coded Top-Level-Domänen als kommerzielle gtlds. Ein bekanntes Beispiel dafür ist WY. Das Kürzel gehörte bis vor kurzem noch dem Südseestaat Tuvalu, wurde ihm aber für 50 Millionen Dollar abgekauft und wird nun von Fernsehsendern und sonstigen interessierten Firmen genutzt. Auch Moldaviens PG steht heute im englischsprachigen Raum eher für 'medical doctor', und unter DP und IP aus Armenien bzw. Mikronesien ist es sehr wahrscheinlich, eine Webseite eines Radiosenders zu finden. An der gerade beschriebenen Struktur ist zu erkennen, dass der Namensraum auch als Namensbaum bezeichnet werden kann. Ausgehend von einem Blatt beschreibt jeder Weg zur Wurzel des Baumes einen FQDN. Wie in Abbildung 1, die nur einen Ausschnitt des Namenraumes zeigt, ersichtlich, wird die Wurzel durch einen Punkt visualisiert und passenderweise auch Root Domäne genannt. Der Punkt existiert nur aus rein technischen Gründen und muss aus Vereinfachungsgründen in fast keinen Programmen mit eingegeben werden. Eine zweite, ebenso wichtige Einteilung des Namenraums ist die Einteilung in Zonen. Während eine Domäne all diejenigen Rechner beinhaltet, die vom Knoten dieser Domäne erreicht werden können, umfasst eine Zone die Rechner, deren Namen sofort durch den zuständigen Name-Server aufgelöst werden können (siehe Abschnitt 4.1). Abbildung 1 Ausschnitt aus dem Namensraum 5

6 0RWLYDWLRQXQG,GHHGHV'16 0RWLYDWLRQ Obwohl die hierarchisch aufgebaute Gliederung des Namenraums für den Menschen sehr logisch und praktisch erscheint, ist es für den Computer effizienter und einfacher mit IP-Adressen zu arbeiten. Allein die statische Länge von 4 Byte vereinfacht die Übertragung von Adressen gegenüber den längenvariablen FQDN. Der Mensch kann sich Zeichenketten besser merken, da sie semantisch zum Inhalt bzw. Zielort passen. Daher ist es naheliegend ein System zu benutzen, das sowohl dem Menschen als auch dem Computer entgegenkommt und die Übersetzung Name IP-Adresse übernimmt. Einem Computerbenutzer ist es kaum zuzumuten, zu jeder Webseite, die er besuchen möchte, eine bis zu zwölfstellige Zahl zu kennen und einzugeben. Dies gilt natürlich nicht nur im Internet. Es gibt viele Beispiele im alltäglichen Leben, in denen es von Vorteil war, einerseits einfach zu merkende aber andererseits elektronisch gut zu verarbeitende Bezeichnungen einzuführen. Es existieren die Personalausweis- und Sozialversicherungsnummer, die Mitgliedsnummer im Verein und die Matrikelnummer, obwohl es für den Menschen einfacher ist, die dahinterstehende Person mit ihrem Vor- und/oder Nachnamen anzureden. Doch auch hier gibt es wieder das Problem der variablen Wortlänge und vor allem der nicht gegebenen Eindeutigkeit des Namens, denn in Datenbanken mit mehreren Millionen Einträgen ist die Wahrscheinlichkeit, zwei Personen mit gleichem Namen zu finden, recht groß. (QWZLFNOXQJXQG*HVFKLFKWH In den Anfängen des Internets (damals noch Arpanet), in denen nur wenige Netzwerke (Universitäten und große Unternehmen) miteinander kommunizierten, konnte das Adressierungsproblem einfach gelöst werden. Es existierte eine vom NIC verwaltete Datei namens hosts.txt, die sich alle Benutzer bei der Einwahl ins Netz per FTP herunterladen mussten und in der alle nötigen Informationen zur Namensauflösung gegeben waren. Der große Vorteil war, dass jeder Benutzer über alle Adressen direkt auf seinem System verfügte, und die Namensauflösung somit fast verzögerungsfrei durchgeführt werden konnte. Da in die Datei fortlaufend neue oder geänderte Daten (=Tupel (Hostname, IP-Adresse,... )) manuell eingetragen werden mussten, die Anzahl der Hosts aber sehr schnell stieg, wäre es aufgrund beschränkter Kapazitäten schon bald nicht mehr möglich gewesen, die Datei auf dem neuesten Stand zu halten. Außerdem wäre irgendwann die hosts.txt so groß geworden, dass allein der durch den Download dieser einen Datei entstehende Datenverkehr und die damit verbundene Wartezeit nicht mehr im Verhältnis zum Nutzen stehen würden. Heutzutage existieren weltweit ca. 29 Millionen Webseiten, deren Adressen nicht in einer Datei gespeichert werden können. 6

7 Es musste daher eine zukunftssichere Alternative entwickelt werden, die folgende Kriterien erfüllen sollte: - Vermeidung von hohem Netzwerkverkehr durch Namensauflösungen - Möglichkeit, lokale Änderungen lokal einstellen zu können - Berücksichtigung der Dynamik und Komplexität des Internets Es kam kurzzeitig sogar der Gedanke auf, die Vereinfachung für den Menschen wegzulassen und nur noch IP-Adressen zuzulassen. Aber die Auseinandersetzungen über diese Themen, die auch in Abschnitt 2.3 nochmals aufgegriffen werden, brachten viele Ideen mit sich, die schließlich 1984 unter einen Hut gebracht wurden und zur Entwicklung des Domain-Name-System (DNS) führten [RFC799, RFC819]. Eine führende Rolle dabei spielte Paul Mockapetris, der im Rahmen der Abschlussarbeit seines Studiums an der Universität von Berkeley 1984 die BIND- Software (Berkeley Internet Name Domain) entwickelte, die auch heute noch auf fast allen Name-Servern (siehe Abschnitt 3.1) installiert ist.,ghhxqg6wuxnwxughv'16 Die naheliegenste Möglichkeit, den Download der hosts.txt zu verhindern, ist die Informationen zur Namensauflösung zentral im Internet zu verwalten. Durch einen Computer, Name-Server genannt, sollten sämtliche Anfragen der Hosts beantwortet werden. Dies löst jedoch nicht alle in Abschnitt 2.2 angesprochenen Probleme und bringt sogar neue mit sich. Die Stabilität des Internets ist nicht gegeben, wenn die komplette Last auf nur einem Rechner liegt, da er einen so genannten Single-Pointof-Failure darstellt. Ein Stromausfall zum Beispiel würde sofort das ganze Internet lahmlegen. Außerdem verbessern sich die Wartungsmöglichkeiten des Systems im Vergleich zur host.txt-lösung nicht. Die Menge an Daten war damals (1984) schon zu groß und ist heute erst recht nicht mehr von einem Team zu bewältigen. Dazu kommt noch das Problem, auf dem laufenden Server Änderungen vorzunehmen. Der Datenverkehr, der auf einen einzigen Name-Server zukommen würde, konnte und kann nicht bewältigt werden. Die Zeit, die es dauern würde, bis der Client die gewünschte IP-Adresse zur angeforderten Domäne zur Verfügung hat, wäre bei dieser Lösung relativ lang. Die gerade genannten Argumente gegen den Aufbau eines zentralen Name-Servers führten zu der Idee eines dezentralisierten Netzes aus mehreren Name-Servern. Eine welteit verteilte Datenbank musste her. Dies war die Schlussfolgerung der Experten, und auch noch heute gilt dieses System als mehr oder weniger optimal und zukunftssicher. 7

8 'LH$XIJDEHQGHV'16 Die Bestimmung der IP-Adresse eines Hostnamens ist sicherlich der wichtigste und am häufigsten genutzte Dienst des Domain-Name-Systems, aber lange nicht der einzige. In diesem Kapitel sollen auch die anderen, nicht zu vernachlässigenden Dienste beschrieben werden. 1DPH5HVROXWLRQ Wie schon in den vorherigen Kapiteln gezeigt, wird die Namensauflösung, also die Bestimmung der IP-Adresse eines gegebenen Hostnamens durch die verteilte Datenbank der Name-Server durchgeführt. Der Client ist beispielsweise ein Webbrowser oder programm. Die exakte Vorgehensweise wird in Kapitel 4 detailliert beschrieben und in Kapitel 5 anhand zweier Beispiele verdeutlicht. /RDG%DODQFLQJ Da es viele Homepages oder FTP-Server gibt, die mehrere Millionen mal pro Tag aufgerufen werden, ist es für die verantwortliche Organisation sinnvoll, die entstehende Netzwerklast zu verteilen, indem sie mehrere Server mit gleichem Inhalt an das Internet anbindet. Doch es tritt das Problem auf, dass nun diese Server verschiedene IP-Adressen zugewiesen bekommen. Ein gutes Beispiel dafür ist Unter dem Betriebssystem Windows ergibt die Eingabe des Befehls nslookup folgendes Resultat: Name: Adresses: , , , , , , , , , Aliases: Dies bedeutet, dass yahoo.com zwölf Webserver betreibt, um die Anfragen der Benutzer effizient bearbeiten zu können. Um eine möglichst optimale Verteilung der Last zu erreichen, wird die Reihenfolge der Ergebnisse bei jeder Anfrage verändert, indem die Ergebnisliste beispielsweise rotiert wird (DNS-Rotation). Da die meisten Anwendungen den ersten Eintrag der Ergebnisliste verwenden, wird dadurch eine gleichmäßige Verteilung der Anfragen auf die einzelnen Server erreicht. Es ist auch möglich, den IP-Adressen Prioritäten zuzuweisen, die bei der DNS- Rotation berücksichtigt werden. 8

9 5HYHUVH/RRNXS Für einige Anwendungen ist es notwendig, zu einer gegebenen IP-Adresse den dazugehörigen Hostrechner zu bestimmen. Um dies zu ermöglichen, wurde das Reverse Mapping eingeführt. Dies geschieht genau wie alle anderen Anfragen über DNS-Nachrichten. Wie in Abschnitt 4.4 ersichtlich, wird hier nicht im normalen Namensraum gesucht. Zu diesem speziellen Zweck ist eine eigene Domäne namens LQDGGUDUSD eingerichtet worden, die alle IP-Adressen in umgekehrter DQN enthält. Ein Beispiel um dies zu veranschaulichen ist ebenfalls in Abschnitt 4.4 gegeben. $OLDV+RVWQDPH Dass ein Rechner, auf dem mehrere Server laufen, mehrere so genannte Alias- Namen besitzen kann, wurde in Abschnitt 1.2 erklärt. Zum Beispiel könnte Alpha auf seinem eigenen Server server4all.alpha.de sowohl einen Webserver als auch einen FTP-Server ftp.alpha.de laufen lassen. Mithilfe des DNS besteht die Möglichkeit, die einfach zu merkenden Alias- Namen zuerst in den kanonischen Namen und danach diesen wiederum in eine IP- Adresse aufzulösen. $OLDV+RVWQDPHI U0DLO6HUYHU Zu einer -Adresse den zuständigen Mail-Server zu finden, stellt für das Domain-Name-System ein Problem dar. Beispielsweise existieren Adressen wie Dabei bezeichnet web.de keinen Mail-Server sondern lediglich eine Domäne, um lange und schlecht zu merkende Bezeichnungen zu vermeiden. Aus diesem Grund stellt das DNS einen Dienst zur Verfügung, der zu einer gegebenen Domäne eine Liste von Mail-Servern ermittelt, die für die Weiterleitung der -Adressen zuständig sind. Die nötigen Informationen hierzu stehen in so genannten Mail-Exchange-Einträgen (MX-Records, siehe Abschnitt 4.4). Die einzelnen Mail-Server sind mit Prioritäten (SUHIHUHQFH YDOXH) versehen, die bestimmen, in welcher Reihenfolge versucht werden soll, die Nachricht an die Hosts zu verschicken. 9

10 $XIEDXXQG)XQNWLRQVZHLVHGHV'16 'HU1DPH6HUYHU Durch die Dezentralisierung wird der Datenverkehr minimiert, da der am nächsten gelegene Name-Server zur Bearbeitung einer Abfrage gewählt werden kann. Dafür muss die Struktur des Systems so gewählt werden, dass die Daten möglichst optimal im Internet verteilt sind. Die Lösung, die sich schließlich durchsetzte, ist hierarchisch aufgebaut. Sie besteht aus mehreren Ebenen von Servern, die die Namensauflösung im Internet realisieren, von denen zwei Ebenen eine besondere Rolle spielen: die Ebene der lokalen Name-Server und der Root-Name-Server. /RNDOH1DPH6HUYHU Die unterste Ebene des Systems besteht aus so genannten lokalen Name-Servern, die sehr nah am Benutzer lokalisiert sind. Die meisten dieser Rechner sind bei den jeweiligen Internet Service Providern (ISP) untergebracht. Aber auch größere Firmen oder Universitäten besitzen solche Server, um eine gewisse Autonomie zu besitzen (siehe Authoritative-Name-Server). Mit 'sehr nah'ist gemeint, dass diese Server von den zugehörigen Rechnern bzw. vom internen Netzwerk schnell zu erreichen sind, also gar keine oder nur wenige Router dazwischenliegen. Hier ist, wie in Kapitel 1 beschrieben und in Abbildung 1 zu sehen, die Zone von Bedeutung. Jedem lokalen Name-Server ist eine Zone unterstellt, für die er zuständig ist. Das bedeutet, er hat alle nötigen Informationen zur Namensauflösung eines Rechners innerhalb dieses Bereichs gespeichert. Außerdem ist er in den meisten Fällen der zuständige Name-Server für Anfragen, die aus dieser Zone stammen. Beispiel (vergleiche auch Abbildung 1): Das Netzwerk der medizinischen Fakultät an der University of Michigan in Ann Arbor besteht aus so vielen Rechnern, dass sich der Betrieb eines eigenen DNS- Servers lohnt und gleichzeitig den Name-Server der ganzen Universität (dns.umich.edu) entlastet. Er wird hier als dns.medicine.umich.edu bezeichnet. Alle Hosts im internen Netzwerk der Fakultät liegen in der Zone dieses Name-Servers, welcher in der Lage ist, genau für diese eine Namensauflösung durchzuführen. Jede Anfrage nach einer Namensauflösung, die der Rechner alpha.medicine.umich.edu benötigt, wird an den Name-Server seiner Zone, also an dns.medicine.umich.edu gestellt. Da häufig Anfragen nach Hosts kommen, die im gleichen Netzwerk liegen, besitzt diese Art von Dezentralisierung eine Menge Vorteile. So kann zum Beispiel eine Anfrage von alpha.medicine.umich.edu nach der IP-Adresse von beta.medicine.umich.edu komplett in der eigenen Zone und daduch schnell beantwortet werden. Der zweite wichtige Punkt ist, dass das restliche Internet nicht von dieser Aktion betroffen ist und das Verkehrsaufkommen somit minimiert wird. 10

11 5RRW1DPH6HUYHU Falls eine Anfrage von einem lokalen Name-Server nicht beantwortet werden kann, kommt einer der 13 weltweit vorhandenen so genannten Root-Name-Server eine große Bedeutung zu. Die Anfrage kommt aber nicht immer, wie oben beschrieben, vom Endbenutzer beziehungsweise seiner Software, sondern auch vom lokalen Name-Server, der dann die Rolle des Clients übernimmt. Der angesprochene Root- Server ist nun für die Namensauflösung verantwortlich. Falls dieser aber auch keinen Eintrag in seiner eigenen Datenbank findet, so sind aber IP-Adressen der zuständigen Name-Server der Top-Level-Domänen gespeichert. In Abbildung 2 sind die Standorte der 13 Root-Server markiert. Leicht zu erkennen ist, dass sich alleine sechs Server an der Ostküste der USA befinden. Dies ist ein hohes und immer wieder kritisiertes Sicherheitsrisiko, denn einen Angriff auf diese Server könnte das Internet nicht ohne weiteres verkraften und würde zu großen Teilen ausfallen. Dies hätte sicherlich wirtschaftliche Konsequenzen in der ganzen Welt. Alle auf der nächsten Seite aufgelisteten Root-Server, sowie die meisten lokalen Server laufen unter dem Betriebssystem Unix. Als Software, die die Namensauflösung bzw. die Zugriffe auf die Datenbanken regelt, wird das auf näher beschriebene BIND-Paket benutzt (Berkley Internet Name Domain). $XWKRULWDWLYH1DPH6HUYHU Jeder Rechner, der an das Internet angeschlossen ist, muss bei einem so genannten Authoritative-Name-Server registriert sein. Dieser ist meist beim zugehörigen Internet Service Provider installiert. Genauer gesagt müssen dort sogar zwei Rechner vorhanden sein, um bei einem Ausfall trotzdem einen reibungslosen Ablauf der Namensauflösung zu garantieren. Wie der Name schon besagt, besitzen solche Server eine gewisse Autorität bzw. Zuständigkeit für ihre Zone und haben zwei wichtige Aufgaben im Domain-Name-System zu verrichten: 1. Sie besitzen die benötigten Einträge in ihrer Datenbank, um die Auflösungsanfragen an alle in ihren Zonen befindlichen Rechnern zu beantworten. 2. Bei einer verteilten Datenbank besteht das Problem, wer die Autorität besitzt, Neueintragungen, Änderungen und Löschungen vorzunehmen. Durch das im nächsten Kapitel beschriebene DNS-Caching kommt es zwar eventuell zu Konflikten, aber da der Authoritative-Name-Server die absolute Kontrolle über die Einträge seiner Rechner besitzt, sind Überschneidungen und unterschiedliche Daten zu einem Host mehr oder weniger ausgeschlossen. An diesen Aufgaben ist leicht zu erkennen, dass lokale Name-Server und Authoritative-Name-Server viel gemeinsam haben. Dies wird in der Praxis auch genutzt, indem viele Server bei den ISP beide Rollen einnehmen. 11

12 Abbildung 2 Die geographische Lage der Root-Name-Server A.ROOT-SERVERS.NET NSF-NSI, Herndon, Virginia, USA B.ROOT-SERVERS.NET DISA-University of Southern California, Marina del Rey, California, USA C.ROOT-SERVERS.NET PSI, Herndon, Virginia, USA D.ROOT-SERVERS.NET University of Maryland, College Park, Maryland, USA E.ROOT-SERVERS.NET NASA, Moffet Field, California, USA F.ROOT-SERVERS.NET ISC, Woodside, California, USA G.ROOT-SERVERS.NET DISA-Boeing, Vienna, Virginia, USA H.ROOT-SERVERS.NET US Army, Aberdeen, Maryland, USA I.ROOT-SERVERS.NET NORDU, Stockholm, Sweden J.ROOT-SERVERS.NET NSF-NSI, Herndon, Virginia, USA K.ROOT-SERVERS.NET LINX/RIPE, London, UK L.ROOT-SERVERS.NET DISA-University of Southern California, Marina del Rey, California, USA M.ROOT-SERVERS.NET WIDE, Keio, Japan 12

13 '165HTXHVWV Wie schon im vorangegangenen Abschnitt angesprochen, kann eine Namensauflösung in den meisten Fällen nicht direkt vom lokalen Name-Server beantwortet werden. Dies ist ein Nachteil dieses Systems. Dass die Vorteile einer Dezentralisierung bei weitem überwiegen, ist in Kapitel 2 ausführlich diskutiert worden. Die Anfrage von einem Rechner an den Name-Server geschieht meistens durch ein so genanntes Resolverprogramm, welches heutzutage in jedem gängigen Betriebssystem integriert ist und diesen Vorgang automatisch auslöst und bearbeitet. Manuelle Anfragen sind auch denkbar und möglich, vor allem dann, wenn direkt bestimmte Name-Server abweichend vom lokalen Server angesprochen werden sollen und die Korrektheit des Ergebnisses der Namensauflösung, also der IP-Adresse, sehr wichtig ist. Um Anfragen zu stellen, egal ob maschinell oder manuell, sieht das Domain-Name- System zwei Möglichkeiten vor, die im Folgenden kurz beschrieben werden sollen: 5HFXUVLYH4XHU\5HVROXWLRQ Fragt ein Rechner X einen Name-Server A rekursiv an und A besitzt einen gültigen Eintrag, so sendet er diesen umgehend zurück. Falls er aber die Anfrage nicht beantworten kann, leitet er egal ob Local oder Root-Name-Server diese an den für die entsprechende Domäne zuständigen Name-Server B weiter. Kennt B z.b. die benötigte IP-Adresse, so sendet er sie über A an X zurück, da inzwischen durch die Rekursion der Name-Server A gegenüber B in die Rolle des Clients gerückt war. Dieses Prinzip kann natürlich weit in die Tiefe gehen, so dass hier auf ein weiteres Beispiel verzichtet wird. Dieses Beispiel ist in Abbildung 3 nachzuvollziehen. Weitere und exaktere Beispiel werden in Kapitel 5 genannt. Abbildung 3 rekursive Anfrage von Rechner X an Name-Server A,WHUDWLYH4XHU\5HVROXWLRQ Die zweite Möglichkeit, eine Anfrage zu stellen, ist die iterative (siehe Abbildung 4). Im Falle der sofortigen Beantwortung von Seiten des kontaktierten Name- Servers A besteht kein Unterschied zur rekursiven Anfrage. Kann der Hostname jedoch nicht sofort in eine IP-Adresse umgewandelt werden, schickt A keine Nachricht an einen weiteren Server. Stattdessen wird eine Nachricht an X geschickt, in der eine IP-Adresse eines weiteren Name-Servers B enthalten ist, der für die angefragte Domäne zuständig ist. Damit ist dieser Vorgang für beide Parteien beendet und X muss nun eine neue Anfrage an B schicken, um die IP- Adresse des aufzulösenden Namens zu erhalten. Ob dies rekursiv oder iterativ geschieht ist egal, denn beide Anfragemöglichkeiten können theoretisch beliebig kombiniert werden, wobei in der Praxis aber folgendes Vorgehen angewendet wird: 13

14 Da die Root-Name-Server eine große Menge an Anfragen zu bewältigen haben, werden dorthin meist iterative Anfragen geschickt, um unnötigen Datenverkehr zu vermeiden. Außerdem ist der Server, der die rekursive Anfrage stellt, zustandsbehaftet, da er auf die Antwort warten und somit Daten zwischenspeichern muß. Anders ist es bei den lokalen Servern. Hier wird oft die rekursive Methode eingesetzt. Abbildung 4 iterative Anfrage von Rechner X an Name-Server A '16&DFKLQJ Ein wichtiges Mittel zur Datentransfer- und Wartezeitminimierung ist das DNS- Caching. Wenn eine rekursive Anfrage an einen Name-Server gestellt wird, der sie nicht direkt beantworten kann, wird die weitergeleitete Nachricht wie in Abschnitt 4.2 beschrieben wieder über diesen Rechner an den Resolver zurückgeschickt. Dabei speichert dieser Server die Daten, wie z.b. Name und IP- Adresse in einem Zwischenspeicher, in dem sie für eine bestimmte Zeit, die so genannte Time-to-Live (TTL, siehe Abschnitt 4.4), verbleiben. Dies kann viele unnötige Suchschritte ersparen, da bei einer erneuten Anfrage innerhalb der durch TTL vorgegebenen Zeit auf diesen Eintrag zurückgegriffen werden kann. Man kann sich leicht vorstellen, dass Seiten wie z.b. oder mehrere Tausend mal pro Tag aufgerufen werden und somit viele identische Namensauflösungen ingangsetzen. Dadurch, dass IP-Adressen zu diesen Seiten eigentlich immer von überall (im Beispiel auf Deutschland bezogen) zu erhalten sind, da sie von den Name-Servern zwischengespeichert worden sind, wird das DNS erheblich entlastet. Je nachdem, wie schnell der Cache auszulesen sein soll, befindet er sich im Hauptspeicher oder auf Festplatten. Die Größe variiert von Server zu Server. Root- Server haben einen größeren Cache als der Name-Server der RWTH-Aachen. Aber auch hier findet das DNS-Caching statt, was folgendes kleine Beispiel zeigen soll: alpha.theologie.rwth-aachen.de und beta.geologie.rwth-aachen.de liegen, da es sich um relativ kleine interne Netze handelt, in der gleichen Zone von dns.rwthaachen.de. Von alpha wurde gestern eine Auflösung des Namens angestoßen. Da die zugehörige IP-Adresse nicht in der Datenbank des DNS- Servers der Universität vorhanden war, hat der Name-Server die Adresse durch eine rekursive Abfrage ermittelt. Dies hat für elektronische Verhältnisse etwas gedauert, da die IP-Adresse nicht sofort verfügbar war und evtl. bis nach New York City, dem Stammsitz von Sony America, verfolgt werden musste. Heute wollte Beta die gleiche Seite aufrufen und erhielt direkt vom eigenen DNS-Server die IP- Adresse, da dieser sie im Cache gespeichert hatte. 14

15 Dies geschieht nur unter der Annahme, dass die TTL nicht abgelaufen ist. Diese beträgt aber meist 48 Stunden, so dass dieses Beispiel der Realität sehr nahe kommt. '165HFRUGV In diesem Abschnitt soll dargestellt werden, welche Daten und vor allem wie die Daten auf den Name-Servern gespeichert sind. Hierzu werden Einträge benutzt, die Resource Records (RR) genannt werden. Sie bestehen im Wesentlichen aus vier wichtigen Merkmalen, die zu einem Vierertupel zusammengefasst werden: 1DPH9DOXH7\SH7LPH7R/LYH Diese Informationen reichen aus, um einen reibungslosen Ablauf der Namensauflösung und Kommunikation zwischen den Name-Servern zu gewährleisten. 1DPHXQG9DOXH Diese beiden Werte hängen immer vom Type ab und werden deshalb auch dort beschrieben. 7\SH Das Feld Type kann viele verschiedene Werte annehmen. Hier werden nur die wichtigsten sechs beschrieben, die direkt in Nachrichten benutzt werden. Die restlichen (z.b. W[W für Strings oder PE für Mailbox Domain Name) werden in der Praxis nicht benutzt, sind nie richtig eingeführt worden oder werden ausschließlich Server-intern genutzt. Für detaillierte Informationen sei auf [RFC1035] verwiesen. 1. 7\SH $ Dieser Typ besagt, dass 1DPH ein Hostname ist und 9DOXH die dazugehörende IP-Adresse. Dieser Eintrag wird als Antwort auf eine IP-Adressen-Anfrage benutzt, da es hierfür alle nötigen Informationen bereit hält. Beispiel: ( heise.de, , A, ) 2. 7\SH 16 Dieser Eintrag kennzeichnet einen für eine Zone zuständigen Name-Server. Folglich ist der Wert des 1DPH-Feldes eine Domänenname und der des 9DOXH- Feldes der passende Authoritative-Name-Server. Er wird also dann verwendet, wenn ein Server einen Namen nicht auflösen kann und einen zuständigen anderen Server benennt. Beispiel: ( w3.uni-wuppertal.de, NS, ) 3. 7\SH &1$0( CNAME steht für Canonical Name und genau für diesen also den kanonischen Namen - ist dieser Eintrag gedacht. Der Alias-Hostname befindet sich im 1DPH- Feld, während 9DOXH den kanonischen Namen enthält. Beispiel:( CNAME, 3600) 4. 7\SH 0; ( = 0ail (xchange ) Da Mail-Server meist viele Alias-Namen besitzen, existiert für dieses Genre ein eigenes Record, welches sehr eng mit dem CNAME-Record verwandt ist. 15

16 Unter 1DPH ist der Alias-Hostname und unter 9DOXH der Hostname des Mail- Servers zu finden. Beispiel: ( relay.rwth-aachen.de, relay2.rwth-aachen.de, MX, 3600 ) Falls in der -Adresse kein Host- oder Aliasname steht, gibt es MX- Einträge, die zu einem gegebenen Domänennamen einen oder mehrere Hosts gespeichert haben (siehe Abschnitt 3.5). 7\SH 375(=Pointer) Dieser Eintrag ist das Gegenstück zum Type A. Hier ist die IP-Adresse (in umgekehrter Reihenfolge im 1DPH-Feld mit der Endung.LQDGGUDUSD) die Anfrage und der Hostname (9DOXH) die Antwort. Beispiel: ( in-addr.arpa, delta.uni-wuppertal.de, PTR, ), falls delta die IP-Adresse besitzt. 6. 7\SH 62$ ( = Start Of Authority ) Mit Hilfe dieses Eintrags können Parameter definiert bzw. geändert werden. Folgende Werte existieren im DNS: a) Refresh-Time: Zeit, nach der der Datenbestand eines Servers erneuert wird b) Retry-Time: Zeit für einen Neustart nach misslungener Erneuerung c) Expire-Time: Lebensdauer eines Datenbestandes d) Minimum TTL: Minimum Time-to-Live für alle Resource Records 7LPHWR/LYH Die so genannte Time-to-Live zeigt an, wie viele Sekunden ein Eintrag in der Datenbank gespeichert werden soll. Oft genutzte Werte hierfür sind z.b Sekunden (2 Tage) oder 3600 Sekunden (1 Stunde). '161DFKULFKWHQ Der Aufbau einer Nachricht, die zur Kommunikation zwischen den Rechnern benutzt wird, ist in Abbildung 5 dargestellt. Das Nachrichtenformat innerhalb des DNS ist sehr einfach gehalten. Antwort- und Anfragenachrichten besitzen dasselbe Format. Abbildung 5 Aufbau einer DNS-Nachricht 16

17 Gesendet werden sie in der Regel über das User Datagram Protocol (UDP), welches in [RFC768] näher beschrieben wird. Der Header einer Nachricht ist genau 12 Byte groß. Das Identification-Field (16Bit) wird vom Client mit einer von ihm generierten Kennungsnummer belegt, die benutzt wird, um die Antworten den entsprechenden Anfragen zuzuordnen. Das Flag-Field (16 Bit) enthält unter anderem folgende Flags:, Query/Reply-Flag : Anfrage oder Antwort, Authoritative-Flag : antwortende Server ist zuständig für Hostnamen, Recursion-Desired-Flag : rekursive Anfrage soll gestellt werden, falls Hostname nicht aufgelöst werden kann, Recursion-Available-Flag : Unterstützung rekursiver Anfragen In jedem Number-of-Feld steht die Anzahl der Blöcke des jeweiligen Typs, die im darauffolgenden Body der Nachricht übertragen werden. Hierdurch wird eine flexible Gestaltung der DNS-Nachrichten ermöglicht [RFC1035]. %HLVSLHOH]XU1DPHQVDXIO VXQJ Da die Namensauflösung der wichtigste Bestandteil des Domain-Name-Systems ist und durch lange Ketten leicht unübersichtlich werden kann, soll sie hier anhand einer Abbildung und zwei Beispielen erklärt werden. Abbildung 6 liefert ein unkonkretes Flussdiagramm, das die Wege, die die DNS- Nachrichten bei einer Anfrage gehen, veranschaulichen soll. Dabei ist Start- und Endpunkt immer der Rechner, der die Namensauflösung anfordert. Um das Schaubild übersichtlich zu halten, sind hier nur rekursive Anfragen visualisiert. Das erste Beispiel ist sehr einfach gehalten, während das zweite Exempel über mehr Zwischenstationen verfügt. In beiden werden fiktive Domänennamen benutzt. (LQIDFKHV%HLVSLHO Der wissenschaftliche Mitarbeiter Meier an einem Lehrstuhl Informatik an der Universität Wuppertal will auf den Rechner von Herrn Schmidt am gleichen Lehrstuhl für zugreifen. Der FQDN des Rechners ist meier.informatik.uniwuppertal.de und der des Kollegens schmidt.informatik.uni-wuppertal.de. Der Resolver auf Meiers Computer stellt nun eine Anfrage an den zuständigen DNS-Server. In diesem Fall ist dies der fakultätseigene Server mit der Bezeichnung dns.informatik.uni-wuppertal.de. Da dieser DNS-Server der Authoritative-Name-Server (Abschnitt 4.1) von schmidt.informatik.uni-wuppertal.de ist, besitzt er einen passenden Eintrag, in dem die angefragte IP-Adresse gespeichert ist. Daraufhin sendet er die Antwort als DNS-Nachricht an meier.informatik.uni-wuppertal.de zurück. Der in Abschnitt 4.4 erklärte DNS-Eintrag würde hier folgendermaßen aussehen: (schmidt.informatik.uni-wuppertal.de, , A, 86400) 17

18 Abbildung 6 Der Weg einer Anfrage für eine Namensauflösung.RPSOH[HV%HLVSLHO Der Resolver auf Meiers Computer stellt eine Anfrage auf mueller.elektrotechnik.uni-muenchen.de an dns.informatik.uni-wuppertal.de (Schritt 1 in Abbildung 7). Er stellt die Anfrage rekursiv. Das bedeutet, da dieser lokale Name-Server keinen Eintrag für Müllers Rechner in seiner Datenbank findet, dass nun der Server dns.informatik.uni-wuppertal in die Rolle des Clients wechselt und selbst eine Anfrage an den Name-Server dns.uni-wuppertal.de stellt, ebenfalls eine rekursive (2). Auch der Uni-DNS-Server besitzt keinen Eintrag und sendet nun, ebenfalls als Client, eine Anfrage an einen Root Server, diesmal jedoch iterativ (3). Der Root-Name-Server, der für die Top-Level-Domäne GH zuständig ist, hat selbst auch keinen Eintrag über die IP-Adresse des Münchner Rechners, besitzt aber eine IP-Adresse des Name-Servers der Universität München, die er in einer DNS- Nachricht mit einem NS-Record (siehe Abschnitt 4.4) an dns.uni-wuppertal.de zurücksendet (4). Dies ist der Authoritative-Name-Server, der für mueller.elektrotechnik.uni-muenchen.de zuständig ist. dns.uni-wuppertal.de, wieder in der Rolle des Clients, sendet nun eine rekursive Anfrage an den Münchner DNS-Server (5) und erhält eine Antwort, die ein A- Resource-Record enthält, also die angefragte IP-Adresse (6). Jetzt wird diese Nachricht über dns.informatik.uni-wuppertal.de an den Resolver von 18

19 meier.informatik.uni-wuppertal.de weitergeleitet (7), der die Informationen nun an das Programm übergibt, das die IP-Adresse benötigte (8). In diesem Beispiel wurde vorausgesetzt, dass kein beteiligter Name-Server durch DNS-Caching den Eintrag zwischengespeichert hatte, und dass die Fakultät für Elektrotechnik an der Universität München keinen eigenen Name-Server besitzt, sondern in der Zone des Name-Servers der gesamten Universität liegt. Wie aus diesem Beispiel ersichtlich ist, kann eine Anfrage an einen DNS-Server eine lange Anfragenkette ingangsetzen. Um diese noch einmal zu veranschaulichen, beinhaltet Abbildung 7 alle beteiligten Rechner und verschickten Nachrichten. Abbildung 7 Darstellung der Nachrichtenkette aus Beispiel

20 =XVDPPHQIDVVXQJXQG$XVEOLFN Das Domain-Name-System ist ein essentieller Bestandteil des Internets, ohne das Dienste, wie z.b. WWW, , Dateitransfer und viele andere Nutzungsmöglichkeiten nicht möglich wären. Die Hauptaufgabe, das Auflösen eines Hostnamens in eine IP-Adresse, vereinfacht die Bedienung des Internets für den Menschen. Aber auch Dienste, wie z.b. das Load Balancing, besitzen eine bedeutende Aufgabe in Bezug auf Datentransferminimierung und vor allem Datenverteilung. Die hierarchische Struktur des DNS und dessen verteilte Datenbank ermöglichen eine bedienungsfreundliche und vor allem sichere Funktionsweise. Entgegen allen Forderungen nach neuen Top-Level-Domänen, muss es die Hauptaufgabe der zuständigen Organisationen sein, die Stabilität des Internets langfristig zu gewährleisten. Die Schnelllebigkeit des Netzes stellt hierbei ein großes Problem dar. Auch Angriffe auf das DNS sind denkbar und können unter Umständen das komplette Internet für eine bestimmte Zeit lahmlegen. So geschehen am Montag, dem 14. Oktober Gegen 17:00 Uhr fand der bisher größte Distributed-Denial-of-Service-Angriff (DDoS) gegen alle 13 Root Server statt. Sieben Root Server fielen für sechs Stunden aus, was aber keine Auswirkungen auf die Bedien- und Benutzbarkeit des Internets hatte. Als Rückschluss daraus lässt sich ziehen, dass das DNS sehr stabil konzipiert worden ist und auch größeren Angriffe standhalten kann. Dies ist auch auf das DNS-Caching zurückzuführen. Die IP-Adressen von hochfrequentierten Rechnern im Internet sind meist bei allen Name-Servern zwischengespeichert, so dass ein Ausfall einiger Root-Name-Server über eine bestimmte Zeit die Funktionalität nicht beeinflusst. Das Domain-Name-System ist eine komplexe verteilte Datenbank, die nicht nur die Aufgabe besitzt, Hostnamen in IP-Adressen umzuwandeln. Es ist eines der wichtigsten Systeme, das eine stabile und sichere Benutzung des Internets ermöglicht. 20