„Root-Nameserver“ – Versionsunterschied
[ungesichtete Version] | [gesichtete Version] |
ergänzt |
Xenein (Diskussion | Beiträge) Linkvorschlag-Funktion: 2 Links hinzugefügt. |
||
(351 dazwischenliegende Versionen von mehr als 100 Benutzern, die nicht angezeigt werden) | |||
Zeile 1: | Zeile 1: | ||
[[Datei:Ams-ix.k.root-servers.net.jpg|mini|Netzwerkgeräte der globalen Anycast-Instanz des K-Root-Servers im [[AMS-IX]].]] |
|||
'''Root-Server''' nehmen im [[Internet]] [[Domain Name System]]-Anfragen von [[Rechner]]n aus aller Welt entgegen und leiten zu den autoritativen DNS-Servern der gewünschten [[Top Level Domain]] weiter. |
|||
'''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). |
|||
Root-Server stehen hierarchisch gesehen an oberster Stelle im Domain Name System. |
|||
Sie werden von verschiedenen Institutionen betrieben und von der [[ICANN]] koordiniert. |
|||
Praktisch jeder ans [[Internet]] angeschlossene Rechner bekommt einen [[Domain Name System#Nameserver|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, [[DNS-Caching|speichert]] er die Antworten für eine gewisse Zeit. |
|||
Derzeit (Stand: Januar 2004) gibt es 14 dieser [[Server]] im [[Internet]]. |
|||
Aus historischen Gründen befindet sich der Großteil der Root-Server insgesamt 11 in den [[USA]]. Weitere drei stehen in Europa (London, Amsterdam und Frankfurt am Main) und einer in Japan (Tokio). |
|||
Root-Server werden von verschiedenen Institutionen betrieben. Die [[Internet Corporation for Assigned Names and Numbers]] (ICANN) koordiniert den Betrieb. |
|||
Die Konzentration in den USA wird kritisiert, da es das Domain Name System, welches einen wesentlichen Bestandteil des Internets darstellt, für physische Angriffe verwundbarer macht. |
|||
Zudem konzentriert es die Macht auf Institutionen, die der US-Regierung unterstellt sind. |
|||
== |
== 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" |
|||
* http://www.isc.org/services/public/F-root-server.html - Betreiber des Root-Servers 'F' |
|||
|- |
|||
* http://www.orsn.net - Eine europäische Alternative zu den von [[ICANN]] koordinierten Root-Servern |
|||
! Buchstabe |
|||
* http://root-servers.org/ |
|||
! 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 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 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 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.<ref>[http://icann.org/committees/security/dns-ddos-advisory-31mar06.pdf icann.org] (PDF)</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> |
|||
== 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]] |
|||
[[en:Root nameserver]] |
|||
[[Kategorie:Verzeichnis]] |
|||
[[ja:ルートサーバ]] |
Aktuelle Version vom 31. Oktober 2024, 22:33 Uhr

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 Karte mit 123 Anycast-Instanzen (Stand 2006)
Weblinks
[Bearbeiten | Quelltext 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 | Quelltext bearbeiten]- ↑ Root Server Technical Operations Association. Abgerufen am 14. Mai 2024.
- ↑ 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).