Zum Inhalt springen

„Root-Nameserver“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
[ungesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
ergänzt
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.


== Weblinks ==
== 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&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>[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

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.

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

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.

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