DNS - Domain Name System

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol DNS - Domain Name System Seminar: Kommunikationsprotokolle SS 2003 Fabian Emmes Matrikelnummer: Betreuung: Karl-Heinz Krempels Lehrstuhl für Informatik IV, RWTH Aachen

2 Inhaltsverzeichnis 1 Einleitung Geschichte und Motivation Aufbau des DNS Anforderungen und Ziele Die hierarchische Struktur des DNS Zuständigkeit Redundanz Ressource Records Daten- und Anfragetypen Beispiel einer Zonendefinition Anfragen Aufbau einer DNS Anfrage Iterative Anfrage Rekursive Anfrage Rückwärts-Auflösung (reverse Lookup) Inverse Anfragen Cache Negatives Caching Seriennummern Zonentransfer Andere Anwendungen des DNS RBL - Realtime Blocking Lists Loadbalancing Zusammenfassung 15 2

3 1 Einleitung Ziel dieser Seminararbeit ist es das Domain Name System (DNS) zu beschreiben. Das DNS ist ein Verzeichnissdienst im Internet und wird unter anderem zur Auflösung von Hostnamen in IP Adressen verwendet. Im folgenden wird die Entstehungsgeschichte von DNS erläutert. Kapitel 2 beschäftigt sich mit der Struktur und dem Aufbau des Nameserver Netzwerkes und des Namensraumes. In Kapitel 3 wird detailliert auf das Protokoll eingegangen. Zwei Beispiele wie DNS ebenfalls eingesetzt wird finden sich in Kapitel 4. Im Anschluss befindet sich ein Glossar, das einige zum Verständnis notwendige Begriffe erklärt. 1.1 Geschichte und Motivation In den Entstehungszeiten des Internet war das Problem der Namensauflösung noch recht einfach zu lösen. Da nur wenige IP Adressen vergeben waren, konnte man die Namen über eine zentrale Datei verwalten [HSF85, RFC952]. Diese Hosts Datei wurde von den einzelnen Teilnehmern des Netzwerkes über FTP aktualisiert. Mit einem wachsenden Internet war dieses Verfahren jedoch unpraktikabel, da der Transferaufwand zu der Zahl der Hosts quadratisch anstieg (ein nter Eintrag in die Hosts Tabelle sorgte dafür, das diese an n Computer neu verteilt werden musste). Das Datenaufkommen war nicht der einzige Kritikpunkt dieses Verfahrens. Auch der Aufwand für die Verwaltung des Namensraumes stieg mit der Zahl der Hosts zunehmend. Im Jahr 1983 wurde daher das Konzept einer Domain eingeführt, [Pos83, RFC881] um den Namensraum zu unterteilen. Somit wurde die Möglichkeit eröffnet die Verantwortlichkeiten für den Namensraum auf mehr Personen zu verteilen. Die bisherigen Hostnamen wurden unterhalb der Domain ARPA weitergeführt, sollten aber mit der Zeit auf andere Top Level Domains verteilt werden. In dieser RFC wurde auch angesprochen, dass an der Ablösung der bisherigen Verteilung der Hostinformationen durch ein System von Domain Servern gearbeitet werde. Diese Aufteilung wurde mit [PR84, RFC920] konkretisiert, in der neue Top Level Domains definiert wurden: GOV, EDU, COM, MIL, ORG sowie (temporär) ARPA und einer TLD, mit jeweils zwei Stellen, für jedes in [Int97] gelistete Land. Die Domains in der zweiten Hierarchieebene mussten damals mindestens 50 Hosts enthalten um zugelassen zu werden. Im Jahr 1987 erschien dann eine Serie von Internet RFCs ([Sta87, RFC1032], [Lot87, RFC1033], [Moc87a, RFC1034] und [Moc87b, RFC1035]) die das vorher angekündigte Domain Name System spezifizierten. 3

4 2 Aufbau des DNS Das Hauptziel bei dem Entwurf des DNS war die Skalierbarkeit, d.h. es sollte auch bei sehr vielen Einträgen gut verwaltbar sein und schnell auf Anfragen reagieren. Hierzu musste man von der bisherigen zentralen Struktur wegkommen, da diese einen immensen Verwaltungsaufwand mit sich zog und zusätzlich in dem ständig wachsenden Netz zuviel Bandbreite beanspruchte. 2.1 Anforderungen und Ziele Um den Verwaltungsaufwand zu verringern musste man die Verantwortlichkeiten auf eine größere Menge an Personen verteilen, welche jeweils einen kleineren Zuständigkeitsbereich haben und möglichst direkt dort beschäftigt sind wo die Änderungen auftreten. D.h. eine Institution muss die Möglichkeit haben Adressänderungen die ihre eigene Infrastruktur betreffen selbst im DNS vorzunehmen. Gleichzeitig darf sie natürlich keinen Einfluss auf Adressen haben die ausserhalb dieses Bereichs liegen. Das DNS System sollte mehr Aufgaben erfüllen können als die zuvor verwendete Hosts Datei und z.b. auch in der Lage sein allgemeine Informationen über einen Host speichern zu können. 2.2 Die hierarchische Struktur des DNS Das DNS ist in einer Baumstruktur aufgebaut. Ein Eintrag im DNS besteht aus mehreren Teilen die durch. getrennt sind. Diese Teile sind der Pfad durch den DNS Baum. Diese hierarchische Struktur erlaubt zwei Dinge, zum einem kann kann nun die Verantwortlichkeit über die Datenbank aufgeteilt werden, indem einzelne Personen Teiläste des Baumes verwalten und zum anderen kann die Geschwindigkeit und Ausfallsicherheit verbessert werden. Aus der baumartigen Struktur folgt, dass Anfragen in logarithmischer Zeit im Verhältnis zur Zahl der Hosts beantwortet werden können, welches bei der heutigen Größe des Namensraumes auch unumgänglich ist. 2.3 Zuständigkeit Ein Nameserver kann Teile des Baumes, für den er verantwortlich ist, an weitere Nameserver delegieren. Z.B. sind zwar die Root-Server prinzipiell für den gesammten Namensraum verantwortlich, schicken aber einen Resolver bei Anfragen weiter an einen der Nameserver der entsprechenden TLD. Allerdings heißt ein Punkt in einem Hostnamen nicht zwangsläufig, dass der Bereich von einem anderen Nameserver verwaltet wird. Ein einzelner Server kann beliebig tiefe Unterbereiche verwalten. 4

5 "." Root Server.com.net.org....de Top Level rwth aachen Second Level.informatik www www Abbildung 1: Hierarchische Struktur des DNS 2.4 Redundanz Es gibt in DNS keinen Teil der nur ein einziges Mal existiert, also keinen single point of failure. Idealerweise sollten alle Daten an mehreren Stellen vorliegen. Hierzu wurden verschiedene Richtlinien veröffentlicht, die sich allerdings zwischen den Registrierungstellen unterscheiden können, also in verschiedenen Teilen des Baumes anders aussehen. Die Richtlinien der Denic (der Registrierungstelle für.de Domains) schreibt vor, dass jede Second Level Domain mindestens über 2 Nameserver verfügt und diese nach Möglichkeit noch an unabhängigen Standorten stehen. Am einfachsten ist es eine Redundanz in der zweiten Ebene über ein sogenanntes Master-Slave Prinzip zu erreichen. Dabei hat man einen Hauptrechner, auf dem, nachdem die Zoneninformationen aktualisiert wurden, ein Impuls ausgelöst wird, der die Slave Rechner darüber benachrichtigt das neue Informationen vorliegen. Diese dann von sich aus einen Zonentransfer (3.9) auslösen. Zusätzlich überprüfen die Slave Server noch in regelmässigen Abständen (nach Ablauf der Refresh -Zeiten) ob sich die Seriennummer (3.8) geändert hat. Am ausfallsichersten sind die Root Server ausgelegt, welche die Domain. verwalten. Von ihnen existieren momentan 13 Stück, die sich allerdings zum Großteil in den USA befinden. 2.5 Ressource Records Ressource Record (RR) sind die einheitlichen Datenstrukturen mit denen DNS umgeht. Ihr Aufbau, definiert in [Moc87b, RFC1035], ist immer gleich: Name: Der Schlüssel/Pfad im Suchbaum, entspricht in den meisten Fällen dem Hostnamen. 5

6 16 Bit Name Typ Klasse TTL Ressource Länge Ressource Daten Abbildung 2: Ressource Record (RR) Typ: Der Anfragetyp, siehe 2.6. Klasse: In [Moc87b, RFC1035] wurden 4 Klassen definiert: IN für das Internet, CS für das CSNET (wurde schon bei der Einführung als veraltetet gekennzeichnet), CH die Chaos Klasse und HS. Diese Ausarbeitung bezieht sich lediglich auf die Klasse IN, da es die einzige für das Internet relevante ist. TTL - Time to Live: 32 Bit Integer Wert. Zeit in Sekunden, die ein RR noch gültig ist. Danach darf die Information nicht mehr verwendet und muss von einem autorisierten Server neu bezogen werden. Ressource Länge: Da die Ressource Daten von Typ und Klasse abhängen und durch eventuelle Ergänzungen des DNS Standards nicht feststehen, kann Ihre Länge nicht an ihrem Inhalt bestimmt werden. Dieses 16 Bit Feld speichert die Länge der Ressource Daten, beschränkt sie dadurch aber auch auf = Bytes. Ressource Daten: In den Ressource Daten stecken die eigentlichen Informationen. Ihr Format ist allerdings von Typ und Klasse abhängig, so das es hier nicht näher beschrieben werden kann. 2.6 Daten- und Anfragetypen In [Moc87b, RFC1035] wurde eine ganze Reihe von Daten- und Anfragetypen definiert. Über die Jahre entwickelten einige Leute viele verschiedene Ideen, was man noch im DNS unterbringen könnte und definierten hierfür neue Typen. Die Liste ist mittlerweile recht lang geworden, jedoch gibt es nur wenige Typen die relevant sind und entsprechend oft verwendet werden. Zur Übersichtlichkeit wird für jeden Typ eine Bezeichnung eingeführt, obwohl er im Protokoll später nur als Nummer auftritt. Da diese Nummern für das Verständnis nicht notwendig sind werden sie hier nicht aufgeführt. Am Anfang jeder Zonendefinition steht ein SOA (Start of Authority) Eintrag. Dieser enthält in den Ressource Daten mehrere Felder: 6

7 Der Name des Servers von dem diese Zone ursprünglich kommt (wichtig für Zwischenspeicher) Die Adresse des für diese Zone zuständigen Administrators Eine Seriennummer der Zone, damit man effizient überprüfen kann ob die eigenen Daten noch aktuell sind (siehe 3.8). Verschiedene Timeout und Refresh Zeiten, in 3.6 näher erklärt. Der sicherlich wichtigste und am häufigsten verwendete Typ ist A (Address). Er löst einen Namen in eine IP-Adresse auf. Fast jedesmal, wenn ein Benutzer einen Hostnamen an ein Programm übergibt, findet eine Auflösung mit diesem Typ statt. Da in die Ressource Daten nur eine IP Adresse passen muss, sind diese auf 4 Bytes begrenzt. Ein sehr wichtiger Eintrag, der in jeder Zone mindestens einmal vorhanden sein muss ist der NS (Nameserver) Typ. Dieser speichert die Namen der zuständigen Nameserver für diese Zone. Ein CNAME (Canonical Name) ist ein Verweis. Er zeigt auf einen anderen Eintrag im DNS. Auch wenn eine Anfrage auf einen bestimmten Typ gestellt wurde, kann ein Nameserver mit einem CNAME Eintrag antworten, falls der gewünschte Typ keinen Eintrag hat. Bekommt ein Resolver eine Antwort mit diesem Typ so wird er in der Regel eine neue Anfrage mit dem Inhalt des Verweises starten und das Ergebnis als Antwort auf die erste Anfrage an den Benutzer zurückgeben. Ein PTR (Domain Name Pointer) ist, ähnlich dem CNAME, nur ein Verweis auf einen Eintrag im DNS. Der Resolver verfolgt die Antwort allerdings nicht wie beim CNAME weiter, sondern gibt sie direkt an seinen Benutzer zurück. Ein PTR Eintrag wird zum Beispiel verwendet um eine IP Adresse zurück in einen Hostname aufzulösen (siehe 3.4). Für s ist der MX (Mail Exchange) Typ wichtig. Er ist ein Verweis auf den Namen eines für diese Domain zuständigen Mailservers. Zusätzlich enthalten die Ressource Daten ein Prioritätsfeld. Mit diesem ist es möglich mehrere Mailserver für eine Zone zu definieren um höhere Ausfallsicherheit zu erreichen. Die Typen AFXR und IXFR sind reine Anfragetypen und werden für den Transfer von Zonen verwendet (siehe 3.9). 2.7 Beispiel einer Zonendefinition ; "Start of Authority" example.com. IN SOA ns hostmaster ( ; serial 24h ; refresh 2h ; retry 1000h ; expire 2d ; minimum ttl 7

8 ; erster Nameserver IN NS ns1.example.com. ; zweiter Nameserver IN NS ns2.example.com. ; die beiden Nameserver befinden sich hoffentlich ; in getrennten Netzen... ns1 IN A ns1 IN A ; primärer Mailserver IN MX 10 mail.example.com. ; falls erste Mailserver ausfällt IN MX 20 mail2.example.com. ; löst "example.com." auf diese Adresse auf IN A ; die IP Adresse des Mailservers mail IN A ; ein Alias des Mailservers smtp IN CNAME mail ) 3 Anfragen 3.1 Aufbau einer DNS Anfrage Möchte ein Programm (z.b. ein Webbrowser) nun einen Hostnamen auflösen um die entsprechende IP zu kontaktieren, so schickt er eine Anfrage an einen Resolver. Dies kann ein Teil des Betriebssystemkernels, eine Library oder auch ein ein extra Programm sein. Dieser Resolver schaut nun ggf. in seinem lokalen Cache nach, ob er die Anfrage noch beantworten kann. Falls dies fehlschlägt kontaktiert er einen externen Nameserver (Abb. 3). Die gesamte Kommunikation eines Nameservers kommt mit einer einzigen Datenstruktur (Abb. 4) aus. Diese kann genauso für Anfragen wie für Antworten verwendet werden. Der Kopf enthält allgemeine Informationen über die Nachricht. Wie zum Beispiel ob es eine Anfrage oder eine Antwort ist. 8

9 Programm Anfrage Antwort Resolver Anfrage Antwort Fremder Name server Cache Abbildung 3: Schematische Darstellung einer DNS Anfrage Kopf Frage Antwort Autorität Zusätzliches Die gestellte Frage RRs die die Antwort enthalten Informationen wer autorisiert ist Zusätzliche Informationen Abbildung 4: Jede Nachricht im DNS hat diese Grundstruktur Im Frage Abschnitt sind Datenstrukturen enthalten die ganz ähnlich wie Ressource Records aussehen (Abb. 5). Diese formulieren in einem Fragepacket was der Resolver wissen möchte, in einem Antwort Packet hingegen ist dieser Abschnitt leer. 16 Bit Name Frage Typ (QTYPE) Frage Klasse (QCLASS) Abbildung 5: Der Frageteil einer Nachricht (vgl. RR) In den Abschnitten Antwort, Autorität und Zusätzliches sind jeweils null oder mehr Ressource Records enthalten, die zusammen eine Antwort ergeben. Im Kopfteil einer Nachricht (Abb. 6) steht eine ID, die der Nameserver direkt vom Frage- in das Antwortpacket kopiert. Mit diesem Feld kann der Resolver die Antwort einfacher zuordnen, da z.b. in UDP ja keine Packetflusskontrolle existiert. In den letzten vier Feldern steht wie viele Datensätze jeweils in den Frage, Antwort, Autorität und zusätzliches Teilen der Nachricht stehen. Ausserdem ist 9

10 ein Flag vorhanden das eine sogenannte inverse Anfrage (3.5) kennzeichnet, mit der man von einer Antwort auf einen Hostnamen schliessen kann. 16 Bit QR OPCODE AA TC RARD Z RCODE ID QDCOUNT ANCOUNT NSCOUNT ARCOUNT Abbildung 6: Der Kopfteil einer Nachricht Da der Nameserver, den der Resolver kontaktiert, nur einen Teil des DNS enthält, kann er nicht jede Anfrage direkt beantworten. Hier gibt es nun zwei Verfahren, ([Moc87a, RFC1034]) von wem die Anfrage weiter bearbeitet wird, je nachdem wie der Resolver die Anfrage gestellt hat. 3.2 Iterative Anfrage Hat der Resolver an den Nameserver eine iterative Anfrage gestellt, so bedeutet dies, dass er sich selbst um die weitere Verfolgung der Anfrage kümmern will. Der Nameserver antwortet dann, wenn er die Frage nicht direkt beantworten kann, mit einer Adresse eines Nameservers, der eher für die Anfrage zuständig ist. Der Resolver kann diesen Vorgang dann so lange wiederholen, bis er eine Antwort bekommt. Aufgrund des Aufbaus von DNS wird der erste Nameserver wahrscheinlich an einen der Rootserver oder einen Hauptserver der entsprechenden TLD verweisen und der Resolver kann sich von dort aus herunterhangeln bis er an einem autoritiven Server ankommt der ihm Auskunft geben kann. Dieser Weg ist in Abb. 7 exemplarisch für die iterative Auflösung von www-i4.informatik.rwth-aachen.de. von dem DNS Server eines Internet Providers dargestellt. Der Nameserver des Providers kennt die Adresse nicht und verweist an einen der Root Server. Dieser gibt zurück das für.de Adressen der Nameserver dns.denic.de. zuständig ist und dieser kennt den verantwortlichen Server der RWTH. Von diesem bekommt der Resolver nun eine autorisierte Antwort. Autorisiert bedeutet, dass die Anfrage von dem Nameserver beantwortet wurde, der in der Hierarchie auch offiziell für die entsprechende Zone verantwortlich ist. 3.3 Rekursive Anfrage Bei einer rekursiven Anfrage gibt der Resolver dem ersten Nameserver die Anweisung, dass dieser die weitere Bearbeitung übernehmen und dem Resolver nur eine endgültige Antwort geben soll. Der 10

11 ns01.qsc.de. j.root servers.net. Befugt für "." 1 2 dns.denic.de. Befugt für.de. 3 zs1.rz.rwth aachen.de. Befugt für.rwth aachen.de. Resolver 4 Abbildung 7: Iteratives Auflösen einer DNS Anfrage Nameserver hat jetzt wiederum die Wahl, ob er iterativ die Antwort bestimmt oder dem nächsten Server wieder eine rekursive Frage stellt. Da es für einen Nameserver einen höheren Aufwand bedeutet eine Anfrage rekursiv zu beantworten, werden hier Restriktionen vorgenommen. So beantworten die Root Server z.b. grundsätzlich keine rekursiven Anfragen, bzw. geben die gleiche Antwort, wie bei einer iterativen. Nameserver von Providern hingegen erlauben rekursive Anfragen in der Regel, da dadurch die Antwortdaten auch für andere Kunden gespeichert werden können. 3.4 Rückwärts-Auflösung (reverse Lookup) In vielen Situationen möchte man nicht nur einen Hostnamen in eine IP auflösen, sondern hat auch eine unbekannte IP und möchte wissen wie der Host heisst. Da der Namensraum hierarchisch nach den Namen aufgebaut ist, kann man ihn nach einer bestimmten IP nicht effizient durchsuchen. Es wurde daher eine Zone ( in-addr.arpa. ) definiert, die nur für diesen Zweck verwendet wird. Ein weiteres Problem ist, dass die IP Adressen auch eine Hierarchie darstellen, deren Wurzel im Gegensatz zu den Hostnamen allerdings links liegt. D.h und sind Adressen des Netzes /24. Deshalb dreht man die Reihenfolge der Byte-Blöcke bei der Suche genau um. Will man jetzt z.b. den Hostnamen der Adresse bestimmen, so formt man sie in den Namen in-addr.arpa. um und stellt eine PTR Anfrage. Diese sollte, wenn sie eingetragen wurde, auf den korrekten Hostnamen verweisen. 11

12 Da diese Namen aber jeder verwalten kann, der einen eigenen Adressraum im Internet bekommen hat, kann diese Information leicht gefälscht werden. Daher akzeptieren viele Programme einen Rückwärts aufgelösten Namen nur, nachdem dieser Name wieder in eine IP aufgelöst und mit der ursprünglichen Adresse verglichen wurde. Diese Verfahren nennt man double Lookup. 3.5 Inverse Anfragen Nameserver bieten auch die Möglichkeit der inversen Anfrage an, bei der der Resolver selbst eigentlich ein Antwortpacket schickt, in dessen Kopf das inverse Query Flag gesetzt ist. Der Nameserver sollte daraufhin mit einem Packet antworten, welches eine gültige Frage für das ursprüngliche Packet gewesen wäre. Dies ist nicht zu verwechseln mit einem reverse Lookup (3.4), da bei der inversen Anfrage das DNS nicht systematisch durchsucht werden kann. Es scheint, als ob diese Möglichkeit nicht besonders häufig genutzt wird, da sie in späteren RFCs kaum auftaucht und sie oftmals nur in Zusammenhang mit Sicherheitslücken in Nameservern erwähnt wird. 3.6 Cache Einen entscheidenden Beitrag zu der Geschwindigkeit von DNS liefert das Caching (Zwischenspeichern) von Anfragen. Stellt ein Resolver eine Anfrage an einen Nameserver, so speichert dieser die Antwort, falls er sie nicht aus seinen eigenen Daten beantworten konnte und von einem fremden Nameserver bezogen hat. Kommt nun erneut eine Anfrage, kann er diese schnell aus seinem eigenen Wissen beantworten. Allerdings kann er die Information nicht beliebig lang verwenden, da er nicht weiß, ob sie noch gültig sind. Hierfür gibt es in jedem Antwortpacket, das ein Nameserver sendet, das TTL (Time to Live) Feld, das die Zeit in Sekunden angibt, die die Information noch verwendet werden darf, bevor die Anfrage erneut an einen autorisierten Server gesendet werden muss. Eine korrekte Implementation des DNS Protokolls sollte immer den jeweils aktuellen TTL Wert weitergeben und nicht den, den sie selber erhalten hat. Allerdings gibt es einige fehlerhafte Nameserver ([KPN + 93, RFC1535]), die das nicht tun, und nicht mehr aktuelle Daten zurückgeben. Für den Cache sind rekursive Anfragen besser als iterative, da bei ihnen die Information durch alle betroffenen Server wandert bevor sie verwendet wird, und diese alle ihren eigenen Zwischenspeicher auffrischen. Werden Zonen auf mehreren Servern nach dem Master/Slave Prinzip vorgehalten, so stellt der Slave prinzipiell auch nur einen Cache dar. Doch in dieser Situation ist das Aktualisierungsverhalten etwas komplizierter. In der SOA, die zu jeder Zone gehört, sind 4 Zeiten gespeichert. Die Refresh Zeit ist die Dauer der Abstände in denen ein Slave-Server bei seinem Master Server nachfragt ob die Zone aktualisiert wurde. 12

13 Schlägt die Aktualisierung einer Zone fehl, so wartet der Slave Server die Zeit im Feld Retry bevor er einen neuen Versuch unternimmt. Dies soll verhindern das unnötig viel Verkehr entsteht wenn ein Master Server nicht erreichbar ist. Der Slave Server antwortet auch bei einer fehlgeschlagenen Aktualisierung noch mit den alten Daten. Diese dürfen aber nicht mehr verwendet werden, wenn die im Expire Feld angegebenen Sekunden seit der letzten erfolgreichen Aktualisierung überschritten sind. Das letzte Feld (Minimum) ist der Standard TTL Wert, der für alle Einträge der Zone verwendet wird, die keinen eigenen Wert definiert haben. Diese Zeiten sorgen für einen sehr geringen Datentransfer zwischen den verschiedenen autorisierten Nameservern einer Zone. 3.7 Negatives Caching Eine weitere Idee um den Datentransfer zu verringern ist das in [And98, RFC2308] definierte negative Caching. Es wurde beobachtet, dass es in bestimmten Situationen zu vielen gleichen Anfragen kommen kann, die alle fehlschlagen. Vorstellbar ist dies zum Beispiel wenn auf einer populären Internet Seite ein Link gepostet wird, der auf einen nicht existierenden Hostnamen verweist. In einer solchen Situation wurde das DNS Netzwerk besonders belastet, da jede Anfrage einzeln abgearbeitet werden musste und unter Umständen viele Unteranfragen gestellt wurden um rauszufinden das der Host nicht existierte. Der Vorschlag ist also, dass die Nameserver auch Anfragen, die negativ beantwortet wurden, mit einer TTL von unter 5 Minuten speichern sollten. Damit kann dann ein Ansturm von falschen Anfragen von näheren Servern gut abgefangen werden ohne weitere Nameserver in Mitleidenschaft zu ziehen. 3.8 Seriennummern Die Seriennummer einer Zone ist ein 32 Bit Integer Wert, der in der SOA definiert wird. Er wird benutzt, damit Slaveserver feststellen können ob ihre Zonendaten noch aktuell sind. Wenn ein Administrator Zonendaten ändert, so muss er diesen Wert verändern. Er darf ihn allerdings nur erhöhen. Ein gebräuchliches Verfahren ist z.b. den Wert auf die Zahl YYYYMMDDn zu setzen, wobei Y für das aktuelle Jahr, M für den Monat und D für den Tag des Monats stehen. Bei mehreren Änderungen an einem Tag verändert man zusätzlich die Ziffer n. 3.9 Zonentransfer Wenn ein Slaveserver bemerkt hat, dass seine Daten nicht mehr aktuell sind, so stellt er eine AXFR Anfrage an seinen zuständigen Master Nameserver. Als Antwort auf diese bekommt er dann eine Liste mit den RRs aller Einträge dieser Zone. 13

14 Dies bedeutet aber für Zonen, bei denen häufig kleine Änderungen auftreten, ein hohes Datenaufkommen, da jedesmal die gesamte Zonte übertragen werden musste. Deshalb wurde im August 1996 die [Oht96][rfc1995] freigegeben, die die Implementation eines IXFR (Incremental Zone Transfer) vorschlägt. Hierbei überträgt der Master Nameserver nur die Daten die sich geändert haben. Dafür muss er sich allerdings merken, wie welche Einträge der Zone mit den letzten Änderungen angepasst wurden. In der IXFR Anfrage schickt der Slave nun seine aktuelle Seriennummer mit und bekommt, wenn der Master diese zuordnen kann, nur Datensätze die sich geändert haben seit diese Seriennummer aktuell war. Kann der Master die Änderungen nicht feststellen, so überträgt er die gesamte Liste. Um den Zonentransfer noch weiter zu optimieren, wurde in der sich anschließenden [Vix96, RFC1996] ein Verfahren definiert, mit dem ein Master Server seinen Slave Servern mitteilen kann, dass er neue Zoneninformationen hat. Hierfür sendet er ein NOTIFY Packet an den Slave, der sich daraufhin genauso verhält als wenn seine Refresh Zeit abgelaufen wäre. 4 Andere Anwendungen des DNS Da sich das DNS System über so lange Zeit bewährt hat, eine sehr hohe Stabilität zeigt und die Server für Nameserver oft frei verfügbar ist, wird das System auch gerne für andere Aufgaben verwendet. 4.1 RBL - Realtime Blocking Lists Mit der Verbreitung von als Kommunikationsmittel, stieg auch das Interesse von unseriösen Personen, Werbung über dieses Medium zu verbreiten. Dies geschieht häufig über sogenannte offene Relays. Das sind Mailserver die jedem erlauben eine Mail an beliebig viele andere Personen zu verschicken und die Mail selber nur einmal übertragen zu müssen. Die so entstandenen Kosten müssen dann die Betreiber des offenen Relays und die Benutzer, an die täglich Millionen von Spam-Mails verschickt werden, tragen. Offene Relays sind prinzipiell nur falsch konfigurierte Mailserver, deren Administratoren aus verschiedenen Gründen kein Interesse daran haben den Fehler zu beheben. Wird ein solcher Server bekannt, so kommt seine Adresse auf eine schwarze Liste, eine sogenannte Realtime Blocking List, die man in Mailservern benutzen kann um Verbindungen von geblockten Hosts zu untersagen und so den Spam zu reduzieren. Da diese Listen ständig gewachsen sind, ergaben sich hier die gleichen Probleme wie mit der Adressauflösung in den Anfangszeiten des Internets. Doch konnte man sie auch auf die gleiche Weise lösen: mit DNS. Man erstellte ähnlich wie für den Reverse Lookup (3.4) eine spezielle Zone in der die IP Adressen der zu blockenden Hosts gelistet sind. Durch normales sowie negatives Caching sind dann sehr effektive Anfragen möglich, mit Hilfe derer ein Mailserver entscheidet, ob er eine Verbindung von diesem Host annimmt oder ablehnt. Es kann so zwar nicht aller Spam vermieden werden, aber es grenzt die Möglichkeiten der Spam Versender ein Stück ein. 14

15 4.2 Loadbalancing Eine weitere Möglichkeit DNS einzusetzen, ist die der Lastverteilung. Wenn ein Hostname aufgelöst wird, dann ist die Antwort nicht auf einen Eintrag beschränkt. Es ist möglich mit mehreren Adressen zu antworten, deren Reihenfolge zufällig vom Nameserver bestimmt wird. Da ein Resolver im Allgemeinen nur den ersten Eintrag weitergibt, bekommen unterschiedliche Anfragen verschiedene Ergebnisse. Man kann diesen Effekt nutzen, um eine Lastverteilung zu erreichen, d.h. man hat mehrere Server (z.b. Webserver), die die gleiche Aufgabe erfüllen und lässt einen Namen auf alle Adressen dieser Server auflösen. Stellen nun viele Benutzer eine Verbindung auf diesen Namen her, so werden sie etwa gleichmäßig auf die verschiedenen Server verteilt. 5 Zusammenfassung Das DNS hat sich über die Jahre als sehr stabil erwiesen. Auch gezielte Angriffe auf die Root-Server konnten es nicht aus dem Gleichgewicht bringen. Attacken waren bisher nur für einzelne Teiläste erfolgreich. So gab es im Januar 2001 ein Vorkommnis, bei dem viele der Microsoft Server nicht erreichbar waren, da ihre Namen nicht aufgelöst werden konnten. Das Problem bestand darin, dass Microsoft ihren primären und sekundären Nameserver in einem physischen Netz hatten. Dessen Router wurde mit einem DDoS Angriff blockiert, und so konnte 23 Stunden lang keine Adresse des Microsoft Netzwerkes aufgelöst werden. Ein wesentlich aufwändiger Angriff, der 9 der 13 Root Server im Oktober 2002 für ca. eine Stunde blockierte, blieb hingegen für die meisten Anwender unbemerkt. Abschliessend kann man sagen das sich das DNS sehr bewährt hat, da es nicht nur die Aufgabe für die es konzipiert wurde gut erfüllt sondern auch mit dem ungeheurem Wachstum des Namensraums mithalten konnte. Glossar IP Adresse: Über die IP Adresse kann jeder Computer im Internet identifiziert werden. Sie besteht aus 32 Bit die üblicherweise in 4 mit. getrennten Blöcken zu je ein Byte dargestellt werden. Beispiel: UDP - User Datagram Protocol: Verbindungsloses Protokoll. D.h. eine Implementierung sorgt nicht dafür, dass die Packete in der richtigen Reihenfolge oder überhaupt ankommen. Vorteile: Kaum Overhead, keine Packete um die Verbindung aufzubauen oder zu steuern. Nachteile: Keine Kontrolle über den Datenfluss. Der Benutzer muss sich selber vergewissern, das die Packete 15

16 auch angekommen sind. Es ist ebenfalls nicht gewährleistet, dass die Daten in der richtigen Reihenfolge ankommen. TCP - Transmission Control Protocol: Protokoll mit Verbindungskontrolle. Eine Implementierung dieses Protokolls stellt Datenströme zur Verfügung und stellt sicher das die Daten in der richtigen Reihenfolge beim Partner ankommen. Hierfür ist jedoch eine Kontrollschicht im Protokoll nötig. Nachteile: Die für die Verbindungskontrolle zusätzlichen Packete sorgen nicht nur für einen leicht erhöhten Datentransfer, sondern verzögern zusätzlich die Zeit bis eine Anfrage beantwortet werden kann, da erst einmal zwei Packete zum Verbindungsaufbau ausgetauscht werden müssen. Hostname/Domainname: Domain- und Hostname sind Schlüssel im DNS System und werden in diesem Dokument synonym verwendet. FQDN - Fully Qualified Domain Name: Jede benutzte IP Adresse im Internet sollte einen absoluten, eindeutigen Namen besitzen, für den auch der sogenannte reverse Lookup definiert ist. Dieser eindeutige Name ist der FQDN. TLD - Top Level Domain: Die gröbste Einteilung in der Domainhierarchie. Beispiele: COM, NET, ORG, INFO, TV, EDU und alle ISO Ländercodes (DE, UK, FR... ). Nameserver: Programm, welches einen Teil der Baumstruktur des DNS enthält und Resolvern Anfragen darüber beantworten kann. Aus der Sicht des Nameservers besteht das DNS aus einzelnen Zonen, von denen er teilweise lokale Kopien hat. Resolver: Programm, welches Anfragen an das DNS ausführen kann. Aus der Sicht der Resolvers besteht das DNS aus einer unbekannten Anzahl von Servern, die jeweils einen Teil der Gesamtinformation enthalten [Moc87a, RFC1034]. Zone: Eine Zone ist die Menge von Domainnamen mit dem gleichen Postfix. Z.B. sind ftp.example.com und mail.example.com alles Domainnamen der Zone example.com. 16

17 Literatur [And98] M. Andrews. Negative Caching of DNS Queries (DNS NCACHE), RFC2308. March [HSF85] K. Harrenstien, M.K. Stahl, and E.J. Feinler. DoD Internet host table specification, RFC952. October [Int97] International Organization for Standardization. ISO :1997: Codes for the representation of names of countries and their subdivisions Part 1: Country codes. International Organization for Standardization, Geneva, Switzerland, [KPN + 93] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation Errors and Suggested Fixes, RFC1536. October [Lot87] M. Lottor. Domain administrators operations guide, RFC1033. November [Moc87a] P.V. Mockapetris. Domain names - concepts and facilities, RFC1034. November [Moc87b] P.V. Mockapetris. Domain names - implementation and specification, RFC1035. November [Oht96] M. Ohta. Incremental Zone Transfer in DNS, RFC1995. August [Pos83] J. Postel. Domain names plan and schedule, RFC881. November [PR84] J. Postel and J.K. Reynolds. Domain requirements, RFC920. October [Sta87] M.K. Stahl. Domain administrators guide, RFC1032. November [Vix96] P. Vixie. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), RFC1996. August