Ein DNS- Stammserver ist ein DNS-Server , der auf Fragen zu Top-Level-Domain- Namen ( TLDs ) reagiert und diese an den entsprechenden Top-Level-DNS-Server umleitet. Obwohl es möglicherweise andere DNS-Hierarchien ( Domain Name System ) mit alternativen Root-Servern gibt , wird "DNS-Root-Server" im Allgemeinen verwendet, um auf einen der dreizehn Root-Server des Domain Name System des Internets zu verweisen, die unter der Autorität von ICANN verwaltet werden .
Im Domain Name System ist der Punkt ein Domaintrennzeichen. Konventionell wird ein vollständig qualifizierter Domänenname mit einem Punkt abgeschlossen. Dies bedeutet, dass auf ihn eine leere Zeichenfolge folgt, die die Stammdomäne darstellt. In der Erweiterung stellen wir die Stammdomäne auch durch einen Punkt dar.
Top-Level-Domains (z. B. .com , .org und .fr ) sind Subdomains der Root-Domain.
Ein DNS- Server adressiert einen Stammserver in zwei Fällen:
Die Informationen werden dann für einen langen Zeitraum auf dem DNS-Server zwischengespeichert: 6 Tage für die Liste der Stammserver, 2 Tage für die Informationen der Server der Top-Level-Domains ( TLD ). Da diese Informationen nicht sehr unterschiedlich sind, sind die Anforderungen an die Stammserver relativ gering.
Stammserver sind nicht rekursiv, dh sie liefern nur autorisierende Antworten, leiten keine Anforderungen an einen anderen Server weiter und verwenden keinen Cache. Sie können daher nicht direkt vom Resolver eines Endkunden verwendet werden.
Eine Studie aus dem Jahr 2003 zeigt, dass nur 2% der Anfragen an diese Server legitim waren. Schlechtes oder kein Caching verursacht 75% der Anfragen. 12,5% beziehen sich auf Anfragen nach unbekannten Top-Level-Domains, 7% darauf, dass IP- Adressen als Domain-Namen usw. behandelt werden. Einige falsch konfigurierte Desktops versuchen sogar, Stammserverdatensätze zu aktualisieren oder eine Rekursion anzufordern, was auf einen Konfigurationsfehler zurückzuführen ist. Die beobachteten Probleme und die Lösungen zu ihrer Behebung sind in RFC 4697 beschrieben.
Im Jahr 2007 gingen täglich rund zehn Milliarden Anfragen an Root-Server ein.
Root-Server sind auch für die Top-Level- Domain .arpa maßgeblich . Die Zone inaddr.arpa, die für die umgekehrte Auflösung von IPv4- Adressen verwendet wird , wurde von Root-Servern bis verwaltetFebruar 2011. Es steht nun unter der technischen Leitung der regionalen Internetregister .
Entgegen der landläufigen Meinung gibt es heute nicht physisch länger und nur dreizehn DNS - Root - Server , sondern dreizehn „Server - Identitäten“ , deren Namen von der Form Brief .root-servers.net wo Brief jedoch ein Brief zwischen einem und M. ist, Diese "Identitäten" (oder Servernamen (in) ), denen jeweils eine einzelne Adress- IP zugewiesen ist, werden üblicherweise als "Stammserver" bezeichnet.
Zwölf Organisationen kontrollieren diese Server, zwei sind europäische (RIPE NCC und Autonomica, eine Abteilung von Netnod), eine japanische (WIDE), die andere amerikanische. Neun dieser Server sind keine einfachen Computer, sondern entsprechen mehreren Installationen, die an verschiedenen geografischen Standorten verteilt sind. Bis zum 19. Juli 2019 gibt es mehr als 997 Standorte in 53 Ländern, auf denen ein DNS-Stammserver gehostet wird. Im Jahr 2007 gab es 130 Standorte. .
Die Server wurden unter demselben Domänennamen gruppiert, um einen Mechanismus zur Vermeidung von Wiederholungsnamen im DNS- Protokoll auszunutzen .
Brief | IPv4- Adresse | IPv6- Adresse | Autonomes System | Früherer Name | Gesellschaft | Ort | Websites (global / lokal) |
Software |
---|---|---|---|---|---|---|---|---|
BEIM | 198.41.0.4 | 2001: 503: ba3e :: 2: 30 | AS19836 | ns.internic.net | VeriSign | Verkehr von Anycast verteilt | 6 (6/0) |
BINDEN |
B. | 199.9.14.201 | 2001: 500: 200 :: b | AS394353 | ns1.isi.edu | Universität von Südkalifornien | Marina Del Rey, Kalifornien, Vereinigte Staaten | 1 (1/0) |
BINDEN |
VS | 192.33.4.12 | 2001: 500: 2 :: c | AS2149 | c.psi.net | Cogent Communications | Verkehr von Anycast verteilt | 6 (6/0) |
BINDEN |
D. | 199.7.91.13 | 2001: 500: 2d :: d | AS10886 | terp.umd.edu | Universität von Maryland | College Park, Maryland, Vereinigte Staaten | 1 (1/0) |
BINDEN |
E. | 192.203.230.10 | 2001: 500: a8 :: e | AS21556 | ns.nasa.gov | NASA | Mountain View, Kalifornien, Vereinigte Staaten | 1 (1/0) |
BINDEN |
F. | 192.5.5.241 | 2001: 500: 2f :: f | AS3557 | ns.isc.org | Internet Systems Consortium | Verkehr von Anycast verteilt | 49 (2/47) |
BINDEN |
G | 192.112.36.4 | 2001: 500: 12 :: d0d | AS5927 | ns.nic.ddn.mil | Agentur für Verteidigungsinformationssysteme | Verkehr von Anycast verteilt | 6 (6/0) |
BINDEN |
H. | 198.97.190.53 | 2001: 500: 1 :: 53 | AS1508 | aos.arl.army.mil | Forschungslabor der US-Armee (en) | Aberdeen, Maryland, Vereinigte Staaten | 1 (1/0) |
NSD |
ich | 192.36.148.17 | 2001: 7fe :: 53 | AS29216 | nic.nordu.net | Autonomica ( Netnod (en) ) | Verkehr von Anycast verteilt | 68 | BINDEN |
J. | 192.58.128.30 | 2001: 503: c27 :: 2: 30 | AS26415 | VeriSign | Verkehr von Anycast verteilt | 70 (63/7) |
BINDEN | |
K. | 193.0.14.129 | 2001: 7fd :: 1 | AS25152 | RIPE NCC | Verkehr von Anycast verteilt | 18 (5/13) |
BIND , NSD | |
L. | 199.7.83.42 | 2001: 500: 3 :: 42 | AS20144 | ICANN | Verkehr von Anycast verteilt | 38 (37/1) |
NSD | |
M. | 202.12.27.33 | 2001: dc3 :: 35 | AS7500 | WIDE-Projekt (en) | Verkehr von Anycast verteilt | 6 (5/1) |
BINDEN |
Der RFC 1035 erfordert, dass das DNS für Anforderungen und Antworten im Benutzerdatagrammprotokoll (UDP) 512 Byte nicht überschreitet. Wenn die Antwort größer ist, sollte TCP verwendet werden. Dies verbraucht mehr Ressourcen und birgt das Risiko, von einer Firewall blockiert zu werden. Dieser große Antwortfall ist in der Praxis selten, aber die Liste der Stammzonennamenserver mit entsprechenden IP- Adressen erreicht diese Grenze. Für eine vollständige Antwort in sind 671 Bytes erforderlichJuli 2010.
Die Server A, C, F, G, I, J, K, L und M sind jetzt dank Anycast geografisch verteilt . Im Allgemeinen wird dann der Server verwendet, der dem Client im Sinne des Netzwerks am nächsten liegt. Infolgedessen befinden sich die meisten physischen Server des Domain Name Systems jetzt außerhalb der USA.
Die Stammserver des Domain Name Systems können auch lokal verwendet werden, beispielsweise in den Netzwerken von Internet Service Providern. Sie sollten mit der von ICANN empfohlenen Stammzonendatei des US-Handelsministeriums synchronisiert werden . Solche Server sind keine alternativen DNS- Server, sondern eine lokale Variation der Root-Server von A bis M.
Die Erweiterung EDNS 0 ( RFC 2671) ermöglicht die Verwendung einer größeren Paketgröße. Die Unterstützung wird sowohl für IPv6 als auch für DNSSEC empfohlen .
Root-Server spielen eine wichtige Rolle im Domain Name System ( DNS ). Wenn einer oder mehrere von ihnen nicht mehr reagieren, wird die Last auf die verbleibenden Server verteilt. Wenn keiner von ihnen auf Anfragen antworten könnte, würden Domänennamen allmählich unzugänglich, da die Informationen in den Caches abgelaufen sind, d. H. Insgesamt etwa 2% pro Stunde Ausfallzeit.
Die Möglichkeit eines Fehlers, der alle Server betreffen würde, ist durch die Vielfalt der verwendeten Softwareversionen begrenzt: BINDv8, BINDv9 und NSD. Die Hardware, auf der die Server arbeiten, ist vielfältig.
Das Risiko von Denial-of-Service-Angriffen wird durch die Anzahl der Anycast-Server verringert. Die Unicast-Adresse der meisten Server wird nicht veröffentlicht, um gezielte Angriffe zu vermeiden. Es ist nicht ungewöhnlich, dass einer der Server Gegenstand eines Denial-of-Service-Angriffs ist, ohne dass dies die Leistung des gesamten DNS spürbar beeinträchtigt.
Einige groß angelegte Angriffe aufgetreten sind jedoch XXI th Jahrhundert:
Das 21. Oktober 2002Der vollständige DNS- Stamm wurde eine Stunde lang einem groß angelegten Angriff ausgesetzt, wobei die dreizehn Server A bis M als Ziel ausgewählt wurden. Während dieses Angriffs wurde bei sieben von dreizehn Servern die Leistung aufgrund eines Flusses von 100.000 bis 200.000 Anforderungen pro Sekunde an jeden der Server verschlechtert. Der Angriff verursachte jedoch keine größeren Störungen im globalen Netzwerk, was die Robustheit des Systems zeigt. Laut dem CEO von Verisign, das zwei Root-Server verwaltet, könnten alle Anfragen von einem einzigen Server bearbeitet worden sein.
Der Angriff wurde mit der DDoS- Methode ( Denial of Service ) durchgeführt. Dank einer sehr großen Maschinenflotte konnten die Hacker eine Anzahl von Anfragen generieren, die zwei- bis dreimal so hoch waren wie die Ladekapazität der dreizehn Zielserver, dh das Vierzigfache des üblichen Anfragenvolumens.
Das Anycast- System wurde nach diesem Angriff eingerichtet, um Angriffe vom Typ DoS zu neutralisieren.
Das 6. Februar 2007Die Server F, G, L und M wurden ab 10:00 UTC 24 Stunden lang angegriffen . G und L waren ernsthaft betroffen, während F und M eine ungewöhnliche Anklage meldeten. Die Auswirkungen auf M wurden dank Anycast verringert.
Die Quelle ist ein Botnetz von 5.000 Maschinen, die hauptsächlich in Südkorea ansässig sind und aus den USA stammen .
30. November 2015 (06.50 Uhr UTC bis 09:30 UTC) und der 1 st Dezember 2015 (05.10 UTC bis 06.10 UTC), die 13 Root - Server haben zwei Angriffe DDoS gewesen, was zu Timeouts auf Root - Server B, C, G und H. Ungefähr 5 Millionen Anforderungen wurden pro Sekunde an Server mit zwei eindeutigen Domänen gesendet, die den Angriff verursachen, eine für jeden Angriff. Laut dem Bericht von root-servers.org waren drei der dreizehn Root-Server langsamer, aber die Auswirkungen auf das gesamte Internet waren begrenzt.
Die Stammzonendatei ist öffentlich verfügbar. Es ist recht klein (in der Größenordnung von 2,1MB ) und enthält 1.531 Top-Level - Domain Delegationen , 7295 Nameserver, 4265 A - Datensätze und 3641 AAAA - Einträge ab April 2019.
DNSSEC RRSIG- Signaturen wurden im Juli 2010 zu den Root-Dateien hinzugefügt. Am 11. Oktober 2018 wurde der Root Zone Key Signing Key ( KSK ) von ICANN erfolgreich geändert . Im April 2019 wurden von allen 1.531 vorhandenen Top-Level-Domains 1.388 bei DNSSEC unterzeichnet.
Es ist möglich, eine alternative DNS- Hierarchie mit einer Reihe alternativer Stammserver zu erstellen . Ein Server, der es verwenden möchte, muss über die Liste der Stammserver für diese alternative DNS- Hierarchie verfügen .
Diese Hierarchien können andere Domänen der obersten Ebene definieren. Auf diese Domänen können Clients, die diese Server nicht verwenden, nicht zugreifen. Es besteht auch die Möglichkeit, dass eine Domäne der obersten Ebene zwischen alternativen Hierarchien unterschiedlich definiert wird.
Unter diesen alternativen Hierarchien können wir zitieren:
Das Internet Architecture Board (IAB) drückte in RFC 2826 die Notwendigkeit aus, eine einzige Hierarchie beizubehalten, um den Zusammenhalt des Internet-Netzwerks aufrechtzuerhalten.
Es wurden auch verschiedene Peer-to-Peer- Netzwerksysteme erstellt, um eine praktikable Alternative zu bieten und gleichzeitig die Infrastrukturkosten zu senken, darunter: