DNS - Domain Name System - Seminar: Kommunikationsprotokolle SS 2003
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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: 235164
Betreuung: Karl-Heinz Krempels
Lehrstuhl für Informatik IV, RWTH AachenInhaltsverzeichnis
1 Einleitung 3
1.1 Geschichte und Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Aufbau des DNS 4
2.1 Anforderungen und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Die hierarchische Struktur des DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Zuständigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Redundanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Ressource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 Daten- und Anfragetypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7 Beispiel einer Zonendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Anfragen 8
3.1 Aufbau einer DNS Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Iterative Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Rekursive Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Rückwärts-Auflösung (reverse Lookup) . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Inverse Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Negatives Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8 Seriennummern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9 Zonentransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Andere Anwendungen des DNS 14
4.1 RBL - Realtime Blocking Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Loadbalancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Zusammenfassung 15
21 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 angespro-
chen, 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.
32 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 bis-
herigen 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ög-
lichst direkt dort beschäftigt sind wo die Änderungen auftreten. D.h. eine Institution muss die Mög-
lichkeit 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 unum-
gänglich ist.
2.3 Zuständigkeit
Ein Nameserver kann Teile des Baumes, für den er verantwortlich ist, an weitere Nameserver dele-
gieren. 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 an-
deren Nameserver verwaltet wird. Ein einzelner Server kann beliebig tiefe Unterbereiche verwalten.
4"." 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 Richtlini-
en veröffentlicht, die sich allerdings zwischen den Registrierungstellen unterscheiden können, also in
verschiedenen Teilen des Baumes anders aussehen. Die Richtlinien der Denic (der Registrierungstel-
le 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 Prin-
zip zu erreichen. Dabei hat man einen Hauptrechner, auf dem, nachdem die Zoneninformationen ak-
tualisiert 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.
516 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 Er-
gä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 216 − 1 = 65535 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• Der Name des Servers von dem diese Zone ursprünglich kommt (wichtig für Zwischenspeicher)
• Die Email 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 E-Mails 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 (
2003040358 ; serial
24h ; refresh
2h ; retry
1000h ; expire
2d ; minimum ttl
7)
; 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 192.168.1.23
ns1 IN A 192.168.2.23
; 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 192.168.1.27
; die IP Adresse des Mailservers
mail IN A 192.168.1.26
; 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 Betriebssys-
temkernels, 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 kontak-
tiert 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.
8Anfrage Anfrage
Fremder
Programm Resolver Name−
server
Antwort Antwort
Cache
Abbildung 3: Schematische Darstellung einer DNS Anfrage
Kopf
Frage Die gestellte Frage
Antwort RRs die die Antwort enthalten
Autorität Informationen wer autorisiert ist
Zusätzliches 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 Ressour-
ce 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
9ein Flag vorhanden das eine sogenannte „inverse Anfrage“ (3.5) kennzeichnet, mit der man von einer
Antwort auf einen Hostnamen schliessen kann.
16 Bit
ID
QR OPCODE AA TC RA RD Z RCODE
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 ei-
ne 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 Re-
solver 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 autori-
sierte 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
10ns01.qsc.de. j.root−servers.net. Befugt für "."
dns.denic.de. Befugt für .de.
1
2
3
zs1.rz.rwth−aachen.de. Befugt für .rwth−aachen.de.
4
Resolver
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 Pro-
vidern 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. 192.168.6.1 und 192.168.6.2 sind
Adressen des Netzes 192.168.6.0/24. Deshalb dreht man die Reihenfolge der Byte-Blöcke bei
der Suche genau um.
Will man jetzt z.B. den Hostnamen der Adresse 192.168.6.1 bestimmen, so formt man sie in den
Namen „1.6.168.192.in-addr.arpa.“ um und stellt eine PTR Anfrage. Diese sollte, wenn
sie eingetragen wurde, auf den korrekten Hostnamen verweisen.
11Da 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 eigent-
lich 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 (Zwischenspei-
chern) 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 be-
troffenen 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• Schlägt die Aktualisierung einer Zone fehl, so wartet der Slave Server die Zeit im Feld Re-
try 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 kom-
men 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 ab-
gearbeitet 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 Admi-
nistrator 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.
13Dies bedeutet aber für Zonen, bei denen häufig kleine Änderungen auftreten, ein hohes Datenauf-
kommen, 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 Seriennum-
mer 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 E-Mail 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 ver-
schiedenen Gründen kein Interesse daran haben den Fehler zu beheben. Wird ein solcher Server be-
kannt, 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.
144.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 Adres-
sen 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: 137.226.12.59.
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
15auch 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 richti-
gen 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 absolu-
ten, 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 An-
fragen darüber beantworten kann. Aus der Sicht des Nameservers besteht das DNS aus einzel-
nen 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 Gesam-
tinformation enthalten [Moc87a, RFC1034].
Zone: Eine Zone ist die Menge von Domainnamen mit dem gleichen Postfix.
Z.B. sind „www.example.com“, „ftp.example.com“ und „mail.example.com“ al-
les Domainnamen der Zone „example.com“.
16Literatur
[And98] M. Andrews. Negative Caching of DNS Queries (DNS NCACHE), RFC2308. March
1998.
[HSF85] K. Harrenstien, M.K. Stahl, and E.J. Feinler. DoD Internet host table specification,
RFC952. October 1985.
[Int97] International Organization for Standardization. ISO 3166-1:1997: Codes for the represen-
tation of names of countries and their subdivisions — Part 1: Country codes. International
Organization for Standardization, Geneva, Switzerland, 1997.
[KPN+ 93] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation
Errors and Suggested Fixes, RFC1536. October 1993.
[Lot87] M. Lottor. Domain administrators operations guide, RFC1033. November 1987.
[Moc87a] P.V. Mockapetris. Domain names - concepts and facilities, RFC1034. November 1987.
[Moc87b] P.V. Mockapetris. Domain names - implementation and specification, RFC1035. Novem-
ber 1987.
[Oht96] M. Ohta. Incremental Zone Transfer in DNS, RFC1995. August 1996.
[Pos83] J. Postel. Domain names plan and schedule, RFC881. November 1983.
[PR84] J. Postel and J.K. Reynolds. Domain requirements, RFC920. October 1984.
[Sta87] M.K. Stahl. Domain administrators guide, RFC1032. November 1987.
[Vix96] P. Vixie. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY),
RFC1996. August 1996.
17Sie können auch lesen
