DNS-Rootserver: Anycast für mehr Ausfallsicherheit

Die Betreiber der DNS-Rootserver nehmen die Dezentralisierungsfrage selbst in die Hand, ohne weiter auf Entscheidungen der DNS-Verwalter von der ICANN zu warten.

In Pocket speichern vorlesen Druckansicht 36 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Monika Ermert

Die Betreiber der 13 offiziellen DNS-Rootserver reagieren möglicherweise mit einem Anycast-System für ihrer Rootserver auf die gewachsenen Sicherheits- und Auslastungsanforderungen. In der vergangenen Woche veröffentlichte Daniel Karrenberg von der europäischen IP-Registry RIPE NCC ein Memo, in der er die Einrichtung eines verteilten Netzes von K-Root-Servern unter ein und derselben IP-Adresse entwarf. Mittlerweile gingen Paul Vixie, Entwickler des DNS-Servers BIND, und Paul Wilson, Generaldirektor der IP-Registry für den asiatisch-pazifischen Raum APNIC, mit der gemeinsamen Erklärung an die Öffentlichkeit, ein Netz von F-Rootserver-Spiegeln in der Region Asien-Pazifik aufzubauen.

Über die Jahre habe sich das System der 13 DNS-Root-Server als sehr verlässlicher Service erwiesen, heißt es im Memo von RIPE. Allerdings sei immer wieder die Frage nach der unterschiedlich schnellen Anbindung je nach Entfernung vom K-Server erhoben worden. "Eine bessere Verteilung des Service wird generell positiv beurteilt", schreibt Karrenberg, wegen "kürzerer Antwortzeiten auf Grund geringerer Entfernungen zwischen Client und Server", wegen einer "geringeren Abhängigkeit von der Konnektivität an einem einzigen Punkt", weil verteilte Server besser auf hohe Zugriffszahlen und besonders auf DDoS-Attacken antworten können, und wegen höherer Redundanz ganz allgemein. Auf der Basis eines noch recht neuen Request for Comment (Distributing Authoritative Name Servers via Shared Unicast Addresses, RFC 3258) entwirft Karrenberg daher das K-Anycast-System als mögliches Modell.

Gerade im asiatisch-pazifischen Raum, wo sich derzeit lediglich ein einzelner Root-Server befindet, wird seit langer Zeit die Forderung nach einer besseren Dezentralisierung des Root-Server-Systems gefordert. "APNIC wurde oft aufgefordert, Anstrengungen zur Systemsicherheit zu unterstützten und dies ist wirklich eine Möglichkeit, etwas zu tun", verkündete Wilson in der gemeinsamen Erklärung mit Vixies Internet Software Consortium (ISC), das den F-Root-Server betreibt. In dem Maß, in dem dieses gemeinsame Projekt sich entwickle, meinte Wilson, könne man den Domain Name Service innerhalb der Region deutlich verbessern. Genaue Angaben zur Zahl, Platzierung und den technischen Einzelheiten des geplanten Dienstes liegen bislang aber nicht vor. Ob Vixie und Wilson auch auf das Anycast-Modell setzen, ist daher nicht klar.

Die Rootserver-Betreiber nehmen mit ihren Bemühungen die Dezentralisierungsfrage auf jeden Fall selbst in die Hand, ohne weiter auf Entscheidungen der DNS-Verwalter von der Internet Corporation for Assigned Names and Numbers (ICANN) zu warten. ICANN-Präsident Stuart Lynn hatte kürzlich einen möglichen Umzug eines Root-Servers nach Asien als zu kompliziert abgetan. Die Ausbreitung von F-Kindern in die Region kann nicht zuletzt als Antwort auf ICANNs zögerliche Haltung gesehen werden. Gleichzeitig dürfte dies auch eine Reaktion auf die Bemühungen des ORSN darstellen, ein Netz von EU-Root-Spiegeln aufzubauen. Bislang lehnte die offizielle DNS-Welt dieses Projekt Open Root Server Network mehrheitlich ab, das unter anderem einen Spiegel der Rootzone unter NS1.DE.EU.ORSN.NET anbietet.

Im Karrenberg-Memo wird einer der möglichen Gründe für diese Ablehnung offenbar, wenn dort die Rede vom Dilemma zwischen den Vorteilen eines verteilten Systems und der damit wachsenden Schwierigkeit die Rede ist, für die Konsistenz der Daten zu sorgen. Mit dem Anycast-System, bei dem alle Inkarnationen der Rootserver identisch blieben, soll ein Kompromiss realisiert werden. Vor einer Implementierung seien allerdings auch noch eine Reihe von Fragen zu klären wie etwa die Verteilung der finanziellen Lasten für die Anycast-Server und die notwendige Werbung im Kreis der Internet-Provider. Diese müssten entsprechend das Server-Prefix anpassen, um das neue System anzusprechen. (Monika Ermert) / (jk)