Hyperlocal: Wenn die DNS-Root-Zone zu Hause steht
Die DNS-Root-Zone war lange Zeit den 13 Root-Servern vorbehalten. Nun kann man sie auch lokal vorhalten, was viele Vorteile hat.
Eine ganze Reihe der 13 Root-Nameserver erlauben seit geraumer Zeit den Bezug der kompletten Root-Zone. Diese kann man daher auf einem lokalen Resolver vorhalten, um zum Beispiel die Privatsphäre besser zu schützen oder Antwortzeiten zu verkürzen. Das als hyperlocal bezeichnete Konzept sorgt auch für mehr Stabilität, wie Experten auf dem 103. Treffen der Internet Engineering Task Force (IETF) in Bangkok versichern.
Von der Geschwindigkeit der DNS-Kommunikation hängt wesentlich ab, wie schnell Internet-Dienste reagieren, also etwa Webseiten aufgebaut werden. Deshalb diskutiert die IETF Methoden, die DNS-Antworten beschleunigen. Das schließt auch den Fall ein, dass Domains nicht existieren und die Anfragen ins Leere gehen. Eine Methode, DNS-Antworten schneller zu erhalten, besteht darin, die Root-Zone lokal vorzuhalten. Das verkürzt die Signalwege, zumal wenn die Root-Zone auf dem gleichen Server wie der Resolver sitzt. Die Root-Zone ist klein, gerade mal 1,3 Megabyte belegt sie auf dem Speichermedium.
Einschränkend ist allerdings anzufügen, dass ein Resolver von den Root-Servern lediglich Informationen zu TLD-Delegations abfragt. Weil diese 48 Stunden lang gültig sind, liest sie ein Resolver meistens aus dem eigenen Cache aus, wenn er sie benötigt. Unterm Strich heißt das: Resolver befragen Root-Server selten und für diese Anwendung macht es kaum einen Unterschied, ob die Root-Zone lokal vorliegt oder nicht.
Deutlich Zeit lässt sich aber sparen, wenn Benutzer Anfragen nach nichtexistenten Domains auslösen. Das passiert häufig durch Vertipper. Die dann fälligen negativen Antworten kommen viel schneller beim Benutzer an, wenn die Root-Zone lokal vorliegt. Der Browser erhält die Fehlermeldung, dass es die Domain nicht gibt, viel schneller – und der User kann eher weitermachen.
Latenz geht gegen Null
Ein weiterer Vorteil ist, dass Anfragen nach privaten, nicht delegierten Top-Level-Domains (.lan, .netz, .lokal, etc.) nicht bis zu den Root-Servern im Internet gelangen. Wenn die Root-Zone lokal auf dem DNS-Resolver gehostet wird, werden solche Antworten lokal beantwortet. Das ist besonders in Firmenumgebungen von Bedeutung.
"Die Latenz geht damit gegen Null", sagt der CTO der Internet Corporation for Assigned Names and Numbers (ICANN), David Conrad kürzlich im Gespräch mit heise online. Und: "Wenn ein Root-Server durch eine Denial-of-Service Attacke ausgebremst wird, macht mir das nichts aus, weil das Root-Zone-File im Resolver sitzt", erklärte Conrad. Freilich meint er damit nur die Anfragen, die ein Resolver an die Root-Zone richtet. Die danach folgende Kommunikation mit einem autoritativen DNS-Server, der irgendwo auf der Welt sein kann, wird dadurch nicht beschleunigt.
Aber anders als bei der Beheimatung einer Anycast-Instanz der Root-Zone sollten über den eigenen Hyperlocal-Resolver nur eigene Kunden bedient werden, heißt es.
Hyperlocal-Standard
Bei der IETF geht es nun darum, den ursprünglich als Testballon gestarteten Entwurf zu einem Standard zu machen. Wichtig seien klare Vorgaben zum Fallback im Notfall, erklärte Paul Hoffman von der ICANN: "Wenn die Hyperlocal-Instanz Probleme bei der Auflösung bekommt, muss man auf einen der 13 offiziellen Rootserver beziehungsweise Anycast-Server zurückgreifen können."
Die DNSSEC-signierte Root-Zone wird aktuell zwei Mal täglich aktualisiert. Noch zu diskutieren sei, ob der Root-Server grundsätzlich auf dem eigenen lokalen Server zu halten oder auch von einem Partner bezogen werden kann, betonte Hoffman.
Vertraulichkeit als Zusatzprodukt
Klar ist aber nach Ansicht der Experten, dass der Betrieb der Root-Zone auf einem lokalen System effizienter ist als "aggressive prefetching" und "aggressive caching". Inzwischen erlauben einige Rootserver-Betreiber die Transfers des Root-Zone-Files.
Nur einen klaren Nachteil sieht ICANN-Chef Conrad: "Wir sehen deutlich weniger Datenströme, einfach weil die DNS-Anfragen nicht mehr bei den Root-Servern landen." Das mache die Beurteilung von Attacken schwieriger. Bedeutet es aber nicht zugleich ein Mehr an Vertraulichkeit? "Doch", sagt Conrad, "die Vertraulichkeit wird dadurch auch verbessert." Das bewirkt freilich auch schon die QName Minimization, von der zunehmend mehr DNS-Server Gebrauch machen.
Signierte lokale Domains
Ein weiterer Vorteil für Firmen-Netze: Der Administrator kann eine lokal vorgehaltene Root-Zone mit eigenen DNSSEC-Schlüsseln signieren und die zugehörigen Vertrauensanker auf den DNS-Resolvern des Firmen-Netzwerkes verteilen. Dann lassen sich auch private Namensräume durchgängig per DNSSEC absichern, was sonst nicht möglich ist.
Da der Firmen-Admin volle Kontrolle über den Startpunkt der DNSSEC-Vertrauenskette hat, kann er außerdem DNS-Inhalte nach Bedarf ändern. Das funktioniert zwar nur, wenn die DNS-Clients nicht selbst validieren, sondern diesen Schritt den Firmen-DNS-Resolvern überlassen – aber in Firmennetzwerken ist das üblich. (dz)
