Root-Nameserver

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
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 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.

Auflistung

[Bearbeiten | Quelltext 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 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

Aufsicht

[Bearbeiten | Quelltext 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.[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 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[3] 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.[4] Bis 2002 erfolgte die Verteilung direkt über Zonentransfers vom A-Root-Server, was aus Sicherheitsgründen aufgegeben wurde.[5]

Ausfallsicherheit und Angriffe

[Bearbeiten | Quelltext bearbeiten]

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. 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.[8] 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.[9]

Alternative DNS-Roots

[Bearbeiten | Quelltext 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.[10][11]

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 | Quelltext bearbeiten]

Historisch wurde die Anzahl der Server auf 13 beschränkt:[12][13]

  • 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.

  • Historische Root-Server-Karte vor dem Einsatz von Anycast
    Historische Root-Server-Karte vor dem Einsatz von Anycast
  • Historische Karte mit 123 Anycast-Instanzen (Stand 2006)
    Historische Karte mit 123 Anycast-Instanzen (Stand 2006)
[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Root Server Technical Operations Association. Abgerufen am 14. Mai 2024.
  2. ↑ ICANN Strategy Committee. ICANNWatch
  3. ↑ Root Zone Change Request Process. IANA.
  4. ↑ iana.org (PDF)
  5. ↑ gao.gov (PDF; 0,5 MB) S. 6.
  6. ↑ News Release. University of California, San Diego, External Relations: News & Information
  7. ↑ RFC 2870 – Root Name Server Operational Requirements. Juni 2000 (englisch).
  8. ↑ icann.org (PDF)
  9. ↑ Großangriff auf DNS-Rootserver. heise Netze
  10. ↑ RFC 8483 – Yeti DNS Testbed. Oktober 2018 (englisch).
  11. ↑ yeti-dns.org
  12. ↑ dns extension mechanism for enum. IETF (englisch)
  13. ↑ RFC 3226 – DNSSEC, IPv6 requirements. (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Root-Nameserver&oldid=249931834“