Root-Nameserver (kurz:Root-Server) sindServer zurNamensauflösung an der Wurzel (Root) desDomain Name Systems im Internet. Die Root-Zone umfasst Namen undIP-Adressen der Nameserver allerTop-Level-Domains (TLD).
Praktisch jeder ansInternet angeschlossene Rechner bekommt einenNameserver 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,speichert er die Antworten für eine gewisse Zeit.
Root-Server werden von verschiedenen Institutionen betrieben. DieInternet Corporation for Assigned Names and Numbers (ICANN) koordiniert den Betrieb.
Es gibt 13 Root-Nameserver, die fortlaufend nach dem Schema<Buchstabe>.root-servers.net benannt sind. Jeder Root-Nameserver ist unter einerIPv4-Adresse und einerIPv6-Adresse erreichbar. Alle Root-Nameserver setzenAnycast zurLastverteilung 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.[1]
| Buchstabe | Alter Name | IPv4-Adresse | IPv6-Adresse | Betreiber |
|---|---|---|---|---|
| A | ns.internic.net | 198.41.0.4 | 2001:503:ba3e::2:30 | VeriSign |
| B | ns1.isi.edu | 170.247.170.2 | 2801:1b8:10::b | USC-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 |
| E | ns.nasa.gov | 192.203.230.10 | 2001:500:a8::e | NASA Ames Research Center |
| F | ns.isc.org | 192.5.5.241 | 2001:500:2f::f | ISC |
| G | ns.nic.ddn.mil | 192.112.36.4 | 2001:500:12::d0d | U.S. DoD NIC |
| H | aos.arl.army.mil | 198.97.190.53 | 2001:500:1::53 | US Army Research Lab |
| I | nic.nordu.net | 192.36.148.17 | 2001:7fe::53 | Netnod |
| J | - | 192.58.128.30 | 2001:503:c27::2:30 | VeriSign |
| K | - | 193.0.14.129 | 2001:7fd::1 | RIPE NCC |
| L | - | 199.7.83.42 | 2001:500:9f::42 | ICANN |
| M | - | 202.12.27.33 | 2001:dc3::35 | WIDE Project |
Historisch lag die Aufsicht über die Verwaltung der Root-Zone und weitererIANA-Aufgaben bei der US-Regierung. Die TelekommunikationsbehördeNTIA, die demUS-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 alskalifornische Organisation dem Risiko einer politischen Einflussnahme ausgesetzt ist.[2]
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 TochterfirmaPublic 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[3] und anschließend anVerisign weitergeleitet. Verisign führt die Änderung durch, signiert die geänderte Root-Zone mitDNSSEC und verteilt die neueZonendatei über dedizierte Verteilungs-Server an die Root-Server-Betreiber.[4] Bis 2002 erfolgte die Verteilung direkt überZonentransfers vom A-Root-Server, was aus Sicherheitsgründen aufgegeben wurde.[5]
Die Root-Server bearbeiten eine sehr große Anzahl von Anfragen, ein erheblicher Teil davon verursacht durch fehlerhafte Software oder Netzwerkkonfiguration.[6] 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[7] 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. EinDDoS 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.[8] Dieser DDoS-Angriff wurde alsDNS 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.[9]
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ührungneuer Top-Level-Domains besteht das Risiko von Kollisionen für die Nutzer alternativer Root-Server.
Aktive Anbieter:
Ehemalige Anbieter:
Historisch wurde die Anzahl der Server auf 13 beschränkt:[12][13]
BevorAnycast eingesetzt wurde, befanden sich 10 der 13 Root-Server in denUSA. Dies wurde hinsichtlich der Ausfallsicherheit kritisiert, da eine geografische Zentrierung dem Dezentralisierungsgedanken des Internets entgegenläuft.
