Root-Nameserver (kurz: Root-Server) sind Server zur Namensauflösung an der Wurzel (Root) des Domain Name Systems im Internet. Die Root-Zone umfasst Namen und IP-Adressen der Nameserver aller Top-Level-Domains (TLD).
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 Bearbeiten
Es gibt 13 Root-Nameserver, die fortlaufend nach dem Schema <Buchstabe>.root-servers.net benannt sind. Jeder Root-Nameserver ist unter einer IPv4-Adresse und einer IPv6-Adresse erreichbar. Alle Root-Nameserver setzen Anycast zur Lastverteilung ein, sodass die 13 Adressen von tatsächlich über 1600 Servern an verschiedenen Orten der Welt bedient werden.
| 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 | 199.9.14.201 | 2001:500:200::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 |
| 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 |
Aufsicht Bearbeiten
Historisch lag die Aufsicht über die Verwaltung der Root-Zone und weiterer IANA-Aufgaben bei der US-Regierung. Die Telekommunikationsbehörde NTIA, die dem 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 kalifornische Organisation dem Risiko einer politischen Einflussnahme ausgesetzt ist.
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 und anschließend an Verisign weitergeleitet. Verisign führt die Änderung durch, signiert die geänderte Root-Zone mit DNSSEC und verteilt die neue Zonendatei über dedizierte Verteilungs-Server an die Root-Server-Betreiber. Bis 2002 erfolgte die Verteilung direkt über Zonentransfers vom A-Root-Server, was aus Sicherheitsgründen aufgegeben wurde.
Ausfallsicherheit und Angriffe Bearbeiten
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. 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.
Alternative DNS-Roots Bearbeiten
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 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.
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 Bearbeiten
Historisch wurde die Anzahl der Server auf 13 beschränkt:
- Die maximale Größe (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 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 USA. Dies wurde hinsichtlich der Ausfallsicherheit kritisiert, da eine geografische Zentrierung dem Dezentralisierungsgedanken des Internets entgegenläuft.
Weblinks Bearbeiten
- root-servers.org
- iana.org – Root Zone Management
- Internet in Deutschland bekommt eigenen DNS-Rootserver. heise online
- Daniel Karrenberg: The Internet Domain Name System Explained for Non-Experts. internetsociety.org (englisch).
Einzelnachweise Bearbeiten
- root-servers.org. Root Server Technical Operations Association, abgerufen am 7. Juni 2022 (englisch).
- ICANN Strategy Committee. ICANNWatch
- Root Zone Change Request Process. IANA.
- iana.org (PDF)
- gao.gov (PDF; 0,5 MB) S. 6.
- News Release. University of California, San Diego, External Relations: News & Information
- RFC – Root Name Server Operational Requirements. Juni 2000 (englisch).
- icann.org (PDF)
- Großangriff auf DNS-Rootserver. heise Netze
- RFC – Yeti DNS Testbed. Oktober 2018 (englisch).
- yeti-dns.org
- dns extension mechanism for enum. IETF (englisch)
- RFC – DNSSEC, IPv6 requirements. (englisch).