Root-Nameserver
]]
Root-Nameserver, kurz Root-Server, sind Server zur Namensauflösung an der Wurzel (Root) vom Domain Name System im Internet. Die Zone der Root-Server umfasst Namen und IP-Adressen aller Nameserver aller Top-Level-Domains.
Praktisch jeder ans Internet angeschlossene Rechner bekommt einen Nameserver zugewiesen, der Namen wie „de.wikipedia.org“ auf technische Nummern (IP-Adressen) übersetzen kann. Hat der Nameserver keine Information zur angefragten TLD (in diesem Fall „org“), wendet er sich 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 „de.wikipedia.org“. Damit der Nameserver diese Kette nicht jedes Mal neu durchlaufen muss, speichert er die Antworten für eine gewisse Zeit.
Root-Server werden von verschiedenen Institutionen betrieben. Die Internet Corporation for Assigned Names and Numbers (ICANN) koordiniert den Betrieb.
Root-Server
Es gibt hunderte Root-Nameserver, die unter 13 Namen von a.root-servers.net bis m.root-servers.net ansprechbar sind.{{cite web
|url = http://www.iana.org/domains/root/servers
|title = Root Servers
|publisher = Internet Assigned Numbers Authority
|accessdate = 2012-03-12
}}
{{Belege fehlen|Ort? 84.157.196.116 01:41, 12. Mär. 2012 (CET)|Der folgende Abschnitt}}
{| class="wikitable"|-
! Buchstabe
! Alter Name
! IPv4-Adresse
! IPv6-Adresse
! Betreiber
! Ort
|-
! A
| ns.internic.net
| 198.41.0.4
| 2001:503:ba3e::2:30
| VeriSign
| verteilt (Anycast)
|-
! B
| ns1.isi.edu
| 192.228.79.201
| | USC-ISI
| Marina Del Rey, Kalifornien, USA
|-
! C
| c.psi.net
| 192.33.4.12
| | Cogent Communications
| verteilt (Anycast)
|-
! D
| terp.umd.edu
| 128.8.10.90
| 2001:500:2d::d
| University of Maryland
| College Park, Maryland, USA
|-
! E
| ns.nasa.gov
| 192.203.230.10
| | NASA
| Mountain View, Kalifornien, USA
|-
! F
| ns.isc.org
| 192.5.5.241
| 2001:500:2f::f
| ISC
| verteilt (Anycast)
|-
! G
| ns.nic.ddn.mil
| 192.112.36.4
| | U.S. DoD NIC
| verteilt (Anycast)
|-
! H
| aos.arl.army.mil
| 128.63.2.53
| 2001:500:1::803f:235
| U.S. Army Research Lab
| Aberdeen Proving Ground, Maryland, USA
|-
! I
| nic.nordu.net
| 192.36.148.17
| 2001:7FE::53
| Autonomica
| verteilt (Anycast)
|-
! J
| | 192.58.128.30
| 2001:503:c27::2:30
| VeriSign
| verteilt (Anycast)
|-
! K
| | 193.0.14.129
| 2001:7fd::1
| RIPE NCC
| verteilt (Anycast)
|-
! L
| | 199.7.83.42
| 2001:500:3::42
| ICANN
| verteilt (Anycast)
|-
! M
| | 202.12.27.33
| 2001:dc3::35
| WIDE Project
| verteilt (Anycast)
|}
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.[http://iana.org/procedures/process-flow.html IANA Root Zone Management High Level Process Flow] Alle Root-Server synchronisieren ihren Datenbestand von redundanten Verteilungs-Servern von VeriSign. In der Vergangenheit synchronisierten die Root-Server noch zweimal täglich direkt vom A-Root, dies wurde jedoch aufgegeben, um diesen Single Point of Failure zu beseitigen.
Ausfallsicherheit und Angriffe
Die Root-Server bearbeiten eine sehr große Anzahl von Anfragen, ein erheblicher Teil davon verursacht durch fehlerhafte Software oder Netzwerkkonfiguration.[http://ucsdnews.ucsd.edu/newsrel/science/sdscRoot.htm University of California, San Diego: External Relations: News & Information: News Releases : Template] 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.http://icann.org/committees/security/dns-ddos-advisory-31mar06.pdf 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.[http://www.heise.de/netze/news/meldung/84880 heise Netze – Großangriff auf DNS-Rootserver]
Kritik
Kritiker erachten das Mitspracherecht der US-Regierung als problematisch.[http://www.icannwatch.org/article.pl?sid=06/08/25/2325205&mode=nocomment ICANNWatch | ICANN Strategy Committee] Dies betrifft zum einen den rechtlichen Status der ICANN, die als kalifornische Institution den US-Gesetzen untersteht. Zum anderen ist die ICANN seit ihrer Gründung mittels eines Memorandum of Understanding (MoU) an das US-Handelsministerium gebunden. Das MoU wurde zuletzt 2006 für drei Jahre verlängert.[http://www.heise.de/newsticker/meldung/78894 heise online – Drei weitere Jahre ICANN und US-Aufsicht über Adressierung im Netz]
Auch VeriSign, die verteilende Instanz der Root-Zonenänderungen, unterliegt als kalifornisches Unternehmen der US-Gesetzgebung.
Um die Einflussnahme der USA auf das Domain Name System zu verringern, entstand unter Mitwirkung von Internetpionieren wie Paul Vixie 2002 das Open Root Server Network (ORSN) als alternativer Root. Der Betrieb des ORSN wurde jedoch zum 31. Dezember 2008 eingestellt.[http://www.heise.de/netze/Alternative-DNS-Root-Server-vor-der-Abschaltung--/news/meldung/117863 heise online - Alternative DNS-Root-Server vor der Abschaltung]
Alternative DNS-Roots
Neben den ICANN-Root-Servern gibt es eine Reihe von alternativen Root-Server-Netzwerken, die aus politischen oder kommerziellen Gründen entstanden sind. Das bereits erwähnte Open Root Server Network, dessen Betrieb eingestellt wurde, verstand sich als politische Non-Profit-Alternative, um den Einfluss der ICANN auf das Domain Name System zu senken. Kommerzielle DNS-Roots verfolgen das Ziel, Domains unterhalb eigener Top-Level-Domains zu verkaufen. Diese TLDs sind ausschließlich Nutzern des jeweiligen Anbieters zugänglich, da sie in der ICANN-Root-Zone nicht vorhanden sind.
Public-Root versteht sich als unabhängige Non-Profit-Alternative. Neben den Top-Level-Domains der ICANN-Zone löst Public-Root auch Top-Level-Domains der kommerziellen Anbieter UN1D und TLD.NAME auf. Ein weiterer alternativer DNS-Root-Betreiber ist OpenNIC, nach eigener Aussage von Freiwilligen ohne kommerzielle Interessen betrieben. Neben den Top-Level-Domains der ICANN löst OpenNIC auch einige eigene TLDs auf.
Aus der Geschichte
Ursprünglich wurde die Anzahl auf 13 beschränkt[http://tools.ietf.org/html/draft-ietf-enum-edns0-00 dns extension mechanism for enum (en)]RFC 3226 – DNSSEC, IPv6 requirements (en):* Da nicht mehr Server inklusive der Zusatzinformationen in ein 512 Byte großes Paket passen, vorgegeben durch konservative Annahme der MTU Konfiguration.
* Weil aus Leistungsgründen UDP das bevorzugte Protokoll ist: ein Paket Anfrage, eines als Antwort in den meisten Fällen.
* Größere Pakete können aufgeteilt werden, jedoch haben frühere Betriebssystem- und Routerversionen das Zusammenfügen dieser fragmentierten Pakete nicht gut unterstützt, also hat der DNS-Standard vorgeschrieben, die Anfrage erneut mittels TCP zu stellen.
Bevor Anycast eingesetzt wurde, befanden sich 10 der 13 Root-Server in den USA. Dies wurde hinsichtlich der Ausfallsicherheit kritisiert, da eine geographische Zentrierung dem Dezentralisierungsgedanken des Internets entgegenläuft.
Einzelnachweise
Weblinks
* [http://www.internic.net/zones/named.root DNS Root Zone / Hints File] – Für die Installation von Domain Nameservern* [http://public-root.com/ public-root.com] – Alternatives Root-Server-Netzwerk
* [http://www.heise.de/newsticker/meldung/43814 Internet in Deutschland bekommt eigenen DNS-Rootserver] (heise online)
* [http://www.isoc.org/briefings/019/ DNS Root Name Servers explained for Non-Experts (en)]
* [http://distributeddns.sourceforge.net/ Distributed DNS] (DDNS)
* RFC 1122 Section 4, historic UDP problems impacting DNS (en)
Kategorie:Domain Name SystemRoot name server
es:Servidor Raíz
fi:Juurinimipalvelin
Serveur racine du DNS
it:Root nameserver
ja:ルートサーバ
nl:DNS-rootserver
pt:Servidor Raiz
ru:Корневые серверы DNS
zh:根域名服務器
Text und Bilder dieses Beitrags stammen aus dem Artikel Root-Nameserver der freien Enzyklopädie Wikipedia und stehen unter der GNU Free Documentation License. Die Liste der Autoren ist in der Wikipedia unter dieser Seite verfügbar, der Original-Artikel lässt sich hier bearbeiten.