Kim Davies von der ICANN hat im ICANN Blog eine interessante Feststellung und wohl auch etwas seinem Ärger Luft gemacht. Alle Welt spricht von 13 Root-Servern im DNS. Warum eigentlich, wo wir gerade bei diesem Punkt, ausgerechnet 13 Root-Server?
Das hat seine Ursache in technischen Grenzen von UDP, das für Übertragungen von DNS-Informationen genutzt wird. UDP hat bekanntlicherweise im Gegensatz zu TCP die Einschränkung, dass es verbindungslos arbeitet, also muss die Antwort auf eine Anfrage komplett in das UDP-Paket hineinpassen, wenn nicht aufwendig ein Mechanismus benötigt werden soll, der mehrere UDP-Pakete wieder zusammenbringt. Bei DNS nicht der Fall, deshalb passen nur 13 Adressen in ein Paket und dito.
Nun darf man sich natürlich nicht vorstellen, dass hinter jeder der 13 IP-Adressen ein einzelner Rechner steht, denn der würde die Anzahl der Anfragen sicherlich nicht bewältigen können. Denn jeder DNS-Server auf dieser weiten Welt muss mindestens alle 42,33 Tage alle diese Root-Server einmal abklappern. Da genügend DNS-Server jedoch erheblich öfter gestartet werden, genügend Administratoren ihre DNS-Server nicht im Griff haben und auch noch genügend technisch Versierte Schabernack mit den DNS-Root-Servern treiben, ist also mächtig was los bei diesen Servern. Mit Loadbalancern ist es technisch kein Thema, an einem Standort unter einer IP-Adresse eine ganze Rechnerfarm zu betreiben. Alles kein Problem.
Naja, doch noch ein kleines Problem, zumindest ein Designproblem. Wir haben jetzt zwar vielleicht ein paar Dutzend DNS-Root-Server, die an 13 Standorten stehen. Sind aber 13 Standorte nicht zu wenig? Wäre es nicht praktischer, wenn man Instanzen der DNS-Root-Server auch an weniger frequentierten Stellen im Internet positionieren könnte, um den interkontinentalen Datenverkehr zu verringern?
Kann man, und zwar mit einer Technik namens Anycast!
Mit Anycast kann man auf kontrollierte Weise etwas machen, was eigentlich in jedem größeren Netzwerk unweigerlich zu einer grande catastrophe führt, wenn man nicht hundertprozentig weiß, was man da genau tut: Rechner in einem verteilten Netzwerk mit identischen IP-Adressen ausstatten. Vereinfacht betrachtet besteht also eine DNS-Root-Server-Instanz, nehmen wir mal den Root-Server “K”, der vom RIPE betrieben wird, nicht an einer Stelle im Internet, sondern an vielen, nämlich in London, Amsterdam, Frankfurt, Athen, Doha (Katar), Mailand, Reykjavik, Helsinki, Genf, Poznan (Polen), Budapest, Abu Dhabi, Tokio, Brisbane, Miami, Delhi und Nowosibirsk. Und überall haben diese Instanzen zum einen genau die gleiche IP-Adresse und auch den genau gleichen Inhalt auf ihrem DNS-Server. Und da diese Instanzen an größeren Knotenpunkten liegen, ist in den Routingtabellen der Anbieter, die an diesen Knotenpunkten eine Verbindung haben, mit Routing-Einträgen geregelt, dass die Zugriffe an diese bestimmte IP-Adresse eben zu der Instanz gehen, die lokal oder in unmittelbarer Netznähe steht.
Ergebnis dieses Konfigurationsaufwandes – und das ist es wirklich – ist, dass diese ganze Phalanx an einzelnen Instanzen im Idealfall erheblich schwerer verwundbar ist, als wenn alles an einem Standort und über einige wenige Anbindungen erreichbar wäre. Wollte also beispielsweise ein böser Mensch die Instanz lahmlegen, müsste er alle einzelnen Instanzen gleichzeitig angreifen. Das ist pauschal nicht ganz unmöglich, jedoch extrem schwer.
Und schon haben wir mit Anycast und nur 13 offiziellen DNS-Root-Servern, die jedoch an über 130 Standorten laufen (immer gut für eine Fangfrage..) eine ziemlich stabile DNS-Oberkante.
Schreibe einen Kommentar