Quelltext der Seite Root-Nameserver

[[Datei:Ams-ix.k.root-servers.net.jpg|mini|Netzwerkgeräte der globalen Anycast-Instanz des K-Root-Servers im [[AMS-IX]].]]

'''Root-Nameserver''' (kurz: ''Root-Server'') sind [[Server]] zur [[Namensauflösung]] an der Wurzel (''Root'') des [[Domain Name System]]s im Internet. Die Root-[[Zone (DNS)|Zone]] umfasst Namen und [[IP-Adresse]]n der Nameserver aller [[Top-Level-Domain]]s (TLD).

Praktisch jeder ans [[Internet]] angeschlossene Rechner bekommt einen [[Domain Name System#Nameserver|Nameserver]] zugewiesen, der Namen wie „de.wikipedia.org“ in 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, [[DNS-Caching|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.

== Auflistung ==
Es gibt 13 Root-Nameserver, die fortlaufend nach dem Schema <span style="font-family:monospace;"><Buchstabe>.root-servers.net</span> benannt sind. Jeder Root-Nameserver ist unter einer [[IPv4]]-Adresse und einer [[IPv6]]-Adresse erreichbar. Alle Root-Nameserver setzen [[Anycast]] zur [[Lastverteilung (Informatik)|Lastverteilung]] ein, sodass die 13 Adressen gleichzeitig von verschiedenen Orten der Welt bedient werden. Stand August 2024 gibt es zusammen mit allen Anycast-Instanzen 1865 Root-Server.<ref>{{Internetquelle |url=https://root-servers.org/ |titel=Root Server Technical Operations Association |abruf=2024-05-14}}</ref>

{| class="wikitable"
|-
! Buchstabe
! Alter Name
! IPv4-Adresse
! IPv6-Adresse
! Betreiber
|-
! A
| ns.internic.net
| 198.41.0.4
| 2001:503:ba3e::2:30
| [[Verisign|VeriSign]]
|-
! B
| ns1.isi.edu
| 170.247.170.2
| 2801:1b8:10::b
| [[University of Southern California|USC]]-[[Information Sciences Institute|ISI]]
|-
! C
| c.psi.net
| 192.33.4.12
| 2001:500:2::c
| [[Cogent Communications]]
|-
! D
| terp.umd.edu
| 199.7.91.13
| 2001:500:2d::d
| [[University of Maryland, College Park|University of Maryland]]
|-
! E
| ns.nasa.gov
| 192.203.230.10
| 2001:500:a8::e
| [[NASA|NASA Ames Research Center]]
|-
! F
| ns.isc.org
| 192.5.5.241
| 2001:500:2f::f
| [[Internet Systems Consortium|ISC]]
|-
! G
| ns.nic.ddn.mil
| 192.112.36.4
| 2001:500:12::d0d
| [[Verteidigungsministerium der Vereinigten Staaten|U.S. DoD]] NIC
|-
! H
| aos.arl.army.mil
| 198.97.190.53
| 2001:500:1::53
| [[United States Army Research Laboratory|US Army Research Lab]]
|-
! I
| nic.nordu.net
| 192.36.148.17
| 2001:7fe::53
| [[Netnod]]
|-
! J
|<nowiki>-</nowiki>
| 192.58.128.30
| 2001:503:c27::2:30
| [[Verisign|VeriSign]]
|-
! K
|<nowiki>-</nowiki>
| 193.0.14.129
| 2001:7fd::1
| [[RIPE Network Coordination Centre|RIPE NCC]]
|-
! L
|<nowiki>-</nowiki>
| 199.7.83.42
| 2001:500:9f::42
| [[Internet Corporation for Assigned Names and Numbers|ICANN]]
|-
! M
|<nowiki>-</nowiki>
| 202.12.27.33
| 2001:dc3::35
| [[WIDE-Projekt|WIDE Project]]
|}

== Aufsicht ==

Historisch lag die Aufsicht über die Verwaltung der Root-Zone und weiterer [[Internet Assigned Numbers Authority|IANA]]-Aufgaben bei der US-Regierung. Die Telekommunikationsbehörde [[National Telecommunications and Information Administration|NTIA]], die dem [[Handelsministerium der Vereinigten Staaten|US-Handelsministerium]] unterstellt ist, beauftragte die ICANN mit den IANA-Aufgaben. Kritiker erachteten das Mitspracherecht der US-Regierung als problematisch. Neben der vertraglichen Bindung wurde auch kritisiert, dass die ICANN als [[Kalifornien|kalifornische]] Organisation dem Risiko einer politischen Einflussnahme ausgesetzt ist.<ref>[http://www.icannwatch.org/article.pl?sid=06/08/25/2325205&mode=nocomment ''ICANN Strategy Committee''.] ICANNWatch</ref>

Seit 2016 trägt die ICANN die Verantwortung selbst, da die NTIA auf ihre Aufsichtsrolle verzichtet hat. Die ICANN gab die IANA-Aufgaben an ihre neu gegründete Tochterfirma [[Public Technical Identifiers]] (PTI) ab, um technische und strategische Funktionen organisatorisch zu trennen.

Änderungsanträge an der Root-Zone werden zunächst von der PTI entgegengenommen, auf technische und formale Korrektheit geprüft<ref>[http://iana.org/procedures/process-flow.html ''Root Zone Change Request Process''.] [[Internet Assigned Numbers Authority|IANA]].</ref> und anschließend an [[Verisign]] weitergeleitet. Verisign führt die Änderung durch, signiert die geänderte Root-Zone mit [[Domain Name System Security Extensions|DNSSEC]] und verteilt die neue [[Zonendatei]] über dedizierte Verteilungs-Server an die Root-Server-Betreiber.<ref>[https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf iana.org] (PDF) </ref> Bis 2002 erfolgte die Verteilung direkt über [[Zonentransfer]]s vom A-Root-Server, was aus Sicherheitsgründen aufgegeben wurde.<ref>[https://www.gao.gov/assets/680/679691.pdf gao.gov] (PDF; 0,5&nbsp;MB) S. 6.</ref>

== Ausfallsicherheit und Angriffe ==

Die Root-Server bearbeiten eine sehr große Anzahl von Anfragen, ein erheblicher Teil davon verursacht durch fehlerhafte Software oder Netzwerkkonfiguration.<ref>[http://ucsdnews.ucsd.edu/newsrel/science/sdscRoot.htm News Release.] University of California, San Diego, External Relations: News & Information</ref> 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äß <nowiki>RFC&nbsp;2870</nowiki><ref>{{RFC-Internet |RFC=2870 |Titel=Root Name Server Operational Requirements |Datum=2000-06}}</ref> 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 [[Distributed Denial of Service|DDoS]] erfolgte 75 Minuten lang mit zusammen 900&nbsp;MBit/s (1,8&nbsp;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.<ref>[https://icann.org/committees/security/dns-ddos-advisory-31mar06.pdf icann.org] (PDF; 0,9&nbsp;MB)</ref> 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.<ref>[https://www.heise.de/netze/meldung/Grossangriff-auf-DNS-Rootserver-143116.html ''Großangriff auf DNS-Rootserver''.] heise Netze</ref>

Ende November 2015 wurden von mehr als 4'000 IP-Adressen knapp 5 Millionen DNS-Anfragen pro Sekunde auf die Root-Server ausgelöst.<ref>{{Internetquelle |autor=Christian Kahle |url=https://winfuture.de/news,90173.html |titel=DNS-Root-Server widerstehen ungewöhnlich heftigem DDoS-Angriff |werk=WinFuture |datum=2015-12-09 |sprache=de |abruf=2026-03-01}}</ref> 4 der 13 Root-Server waren dabei zeitweise nicht mehr erreichbar. In einer Präsentation präsentierte VeriSign, dass der Angriff nicht direkt den Root-Servern, sondern zwei in China registrierten Domains galt.<ref>{{Internetquelle |autor=Michael Mimoso |url=https://threatpost.com/root-servers-were-not-targets-of-2015-ddos-attack/117082/ |titel=Root Servers Were Not Targets of 2015 DDoS Attack |werk=Threatpost |datum=2016-03-30 |sprache=en |abruf=2026-03-01}}</ref>

== Alternative DNS-Roots ==

Neben den ICANN-Root-Servern gibt es alternative Root-Server-Netzwerke, die aus politischen oder kommerziellen Gründen entstanden sind. In der Regel bezwecken die Anbieter eine Autonomie gegenüber dem etablierten Root-Server-Netzwerk. Vereinzelt werden Domains unterhalb eigener Top-Level-Domains verkauft. Diese TLDs sind ausschließlich Nutzern des jeweiligen Anbieters zugänglich, da sie in der ICANN-Root-Zone nicht vorhanden sind. Durch die Einführung [[Neue Top-Level-Domains|neuer Top-Level-Domains]] besteht das Risiko von Kollisionen für die Nutzer alternativer Root-Server.

Aktive Anbieter:
* [[OpenNIC]] ist ein DNS-Root, der nach eigener Aussage von Freiwilligen ohne kommerzielle Interessen betrieben wird. Neben den Top-Level-Domains der ICANN löst OpenNIC auch einige eigene TLDs auf.
* Yeti DNS ist ein offenes [[Testbed]] zur Durchführung technischer Experimente an einem DNS-Root.<ref>{{RFC-Internet |RFC=8483 |Titel=Yeti DNS Testbed |Datum=2018-10}}</ref><ref>[https://yeti-dns.org/documents.html yeti-dns.org]</ref>

Ehemalige Anbieter:
* Bis 2019 existierte das [[Open Root Server Network]] (ORSN), um den Einfluss der ICANN auf das Domain Name System zu senken.
* Public-Root war ein Anbieter, der sich als unabhängige Non-Profit-Alternative verstand. Seit 2011 wird die Website nicht mehr gepflegt und die DNS-Server sind außer Betrieb.
* Cesidian ROOT
* [[Open Root Server Confederation]]
* Enhanced Domain Name Service (eDNS) bot bis zur Außerbetriebnahme 1998 die zusätzlichen Top-Level-Domains .biz, .corp, .fam, .k12, .npo, .per und .web an.

== Aus der Geschichte ==

Historisch wurde die Anzahl der Server auf 13 beschränkt:<ref>[https://tools.ietf.org/html/draft-ietf-enum-edns0-00 ''dns extension mechanism for enum''.] [[Internet Engineering Task Force|IETF]] (englisch)</ref><ref>{{RFC-Internet |RFC=3226 |Titel=DNSSEC, IPv6 requirements |Datum=}}</ref>
* Die maximale Größe ([[Maximum Transmission Unit|MTU]]) eines Datenpaketes, welches das Internet zuverlässig passieren kann, wurde konservativ angenommen (brutto 576 Byte, abzüglich Verwaltungsdaten).
* Da aus Leistungsgründen das verbindungslose [[User Datagram Protocol|UDP]] das bevorzugte Transport-Protokoll für DNS-Anfragen ist, musste die Antwort in nur einem Paket untergebracht werden.
* So wurde die maximale Größe einer DNS-Antwort auf 512 Byte festgelegt, damit konnten Informationen über maximal 13 Server übermittelt werden.
* Aktuelle Software kann mit größeren DNS-Datenpaketen umgehen.

Bevor [[Anycast]] eingesetzt wurde, befanden sich 10 der 13 Root-Server in den [[Vereinigte Staaten|USA]]. Dies wurde hinsichtlich der Ausfallsicherheit kritisiert, da eine geografische Zentrierung dem Dezentralisierungsgedanken des Internets entgegenläuft.

<gallery widths="500" heights="214">
Datei:Root-historic.svg|Historische Root-Server-Karte vor dem Einsatz von Anycast
Datei:Root-current.svg|Historische Karte mit 123 Anycast-Instanzen (Stand 2006)
</gallery>

== Weblinks ==
* [https://root-servers.org/ root-servers.org]
* [https://www.iana.org/domains/root iana.org] – Root Zone Management
* [https://www.heise.de/newsticker/meldung/Internet-in-Deutschland-bekommt-eigenen-DNS-Rootserver-91959.html ''Internet in Deutschland bekommt eigenen DNS-Rootserver''.] heise online
* [[Daniel Karrenberg]]: [https://www.internetsociety.org/internet-domain-name-system-explained-non-experts-daniel-karrenberg ''The Internet Domain Name System Explained for Non-Experts''.] internetsociety.org (englisch).

== Einzelnachweise ==
<references />

[[Kategorie:Domain Name System]]
[[Kategorie:Verzeichnis]]