DNS Root Nameserver

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten auf deiner Diskussionsseite.

Globale Anycast-Instanz des K-Root-Servers in Amsterdam

DNS Root Nameserver, oft auch nur Root-Server genannt, publizieren verlässlich die Root-Zone des Domain Name Systems (DNS) im Internet. Die ca. 2500 Zeilen grosse Datei ist die Wurzel des hierarchisch organisierten DNS. Sie enthält die Namen und IP-Adressen der für die Top Level Domains (TLD, wie zum Beispiel com, net, org, de) zuständigen Nameserver.

Praktisch jeder ans Internet angeschlossenen Rechner bekommt einen Nameserver zugewiesen, der einen Domainnamen wie „wikipedia.org“ zu der dazugehörenden IP-Adresse auflösen kann. Wenn der Nameserver keine Information zur angefragten TLD (in diesem Fall „org“) hat, verweist er stattdessen an die Root-Server. Dort werden die für „org“ zuständigen Nameserver abgefragt. Bei den org-Nameservern wiederum werden die für „wikipedia.org“ verantwortlichen Nameserver erfragt und dort schließlich die IP-Adresse von „wikipedia.org“. Damit der Nameserver diese Kette nicht jedes mal neu durchlaufen muss, cached er die Antworten.

Root-Server werden von verschiedenen Institutionen betrieben, die Internet Corporation for Assigned Names and Numbers koordiniert den Betrieb.

Inhaltsverzeichnis

1 Root Server sind über die ganze Welt verteilt
2 Aktualisierung des Inhalts
3 Ausfallsicherheit und Angriffe
4 Kritik
5 Quellennachweise
6 Weblinks

[Bearbeiten] Root Server sind über die ganze Welt verteilt

Es gibt 13 von der ICANN koordinierte Root-Server im Internet („A“ bis „M“). Dies stellt ein Maximum dar, da nur 13 Root-Server mit ihren Adressen in ein UDP-Antwort-Paket auf eine SOA-Anfrage passen. Das DNS erlaubt UDP-Pakete nur bis 512 Byte, darüber muss das ressourcenintensivere TCP verwendet werden.

Buchstabe	Alter Name	Betreiber	Ort
A	ns.internic.net	VeriSign	Dulles, Virginia, USA
B	ns1.isi.edu	ISI	Marina Del Rey, Kalifornien, USA
C	c.psi.net	Cogent Communications	verteilt (anycast)
D	terp.umd.edu	University of Maryland	College Park, Maryland, USA
E	ns.nasa.gov	NASA	Mountain View, Kalifornien, USA
F	ns.isc.org	ISC	verteilt (anycast)
G	ns.nic.ddn.mil	U.S. DoD NIC	Columbus, Ohio, USA
H	aos.arl.army.mil	U.S. Army Research Lab	Aberdeen Proving Ground, Maryland, USA
I	nic.nordu.net	Autonomica	verteilt (anycast)
J		VeriSign	verteilt (anycast)
K		RIPE NCC	verteilt (anycast)
L		ICANN	Los Angeles, Kalifornien, USA
M		WIDE Project	verteilt (anycast)

Einige Root-Server bestehen jedoch nicht aus einem, sondern mehreren Computern, die zu einem logischen Server zusammengeschlossen sind. Diese Computer (Nodes) befinden sich an verschiedenen Standorten um die ganze Welt und sind per Anycast über dieselbe IP-Adresse erreichbar. Anfang 2007 nutzen sechs Root-Server Anycast^[1].

Ende 2006 gab es zusammen mit allen Anycast-Instanzen 123 Root-Server

[Bearbeiten] Aktualisierung des Inhalts

Änderungsanträge an der Root-Zone werden zunächst von der ICANN im Rahmen der IANA-Aufgaben auf technische Korrektheit geprüft, anschließend an das U.S. Department of Commerce weitergeleitet. Dieses beauftragt VeriSign die Änderung der Zone zu publizieren.^[2] Alle Root-Server synchronisieren ihren Datenbestand von redundanten Verteilungs-Servern von VeriSign. In der Vergangenheit synchronisierten die Root-Server noch zwei mal täglich direkt vom A-Root, dies wurde jedoch aufgegeben, um diesen Single Point of Failure zu beseitigen.

[Bearbeiten] Ausfallsicherheit und Angriffe

Die Root-Server bearbeiten eine sehr große Anzahl von Anfragen, ein erheblicher Teil davon verursacht durch fehlerhafte Software oder Netzwerkkonfiguration. Eine Filterung auf DNS-Ebene findet nicht statt, da dies aufgrund der Einfachheit einer DNS-Anfrage mehr Ressourcen aufwenden würde, als alle Anfragen zu beantworten.

Gemäß RFC 2870 muss jeder Root-Server mit dem dreifachen Peak des am stärksten belasteten Root-Servers umgehen können. Das bedeutet, dass ein Root-Server im Normalbetrieb nur maximal ein Drittel seiner Kapazität ausnutzen darf. Fallen zwei Drittel der Root-Server aus, soll das noch betriebsfähige Drittel die Anfragen beantworten können.

Der Angriff mit der größten Wirkung auf die Root-Server fand am 21. Oktober 2002 statt. Ein DDoS erfolgte 75 Minuten lang mit zusammen 900 MBit/s (1,8 Mpkts/s) auf alle 13 Root-Server. Alle Root-Server blieben zwar lauffähig, da die vorgeschalteten Firewalls den Angriffsverkehr verwarfen, allerdings waren etwa neun Root-Server durch die überfluteten Leitungen schlecht bis gar nicht erreichbar. Root-Server-Lookups wurden dadurch deutlich verzögert, durch das Caching gab es jedoch kaum Störungen bei den Anwendern. Ausgelöst durch den DDoS-Angriff wurde die Umsetzung von Anycast beschleunigt.

Ein weiterer Angriff fand am 15. Februar 2006 statt, einige Tage, nachdem die Nameserver einer von der ICANN nicht genannten Top-Level-Domain angegriffen worden waren.^[3] Dieser DDoS-Angriff wurde als DNS Amplification Attack durchgeführt, wodurch sich das aufgekommene Datenvolumen vervielfachte. Zwei der lediglich drei angegriffenen Root-Server waren 15 Minuten lang nicht erreichbar.

Am 6. Februar 2007 fand ein weiterer DDoS-Angriff auf die Root-Server und gleichzeitig auf einige TLD-Nameserver statt. Zwei Root-Server waren nicht erreichbar.^[4]

[Bearbeiten] Kritik

Heute erachten es manche für problematisch, dass VeriSign und das US-Handelsministerium eine zentrale Rolle im Prozess der Root-Zonenänderung spielen.

Bevor Anycast eingesetzt wurde, befand sich der überwiegende Großteil der Root-Server aus historischen Gründen in den USA. Dies wurde kritisiert, da es das Domain Name System, welches einen wesentlichen Bestandteil des Internets darstellte, für physische Angriffe verwundbarer machte.