Stolperfallen im Domain Name System

Es ist mal wieder so weit: Wir wollen unser Angebot verbessern und sorgen dabei erstmal für Verwirrung bei den Kollegen und Kunden. Dabei ist doch alles so einfach, wenn man schon mal einen DNS-Server betrieben hat.

Gut, das hat man in der Regel nicht. Also erstmal eine kleine Einführung: Der mit Abstand wichtigste Dienst im Internet ist der Domain Name Service, kurz DNS. Er wird manchmal auch als die “Gelben Seiten” des Internets bezeichnet und übersetzt die uns bekannten Domainnamen in Computeradressen. Wir benutzen ihn andauernd wie selbstverständlich und dass er uns kaum auffällt, ist auch der Tatsache geschuldet, dass er die meiste Zeit so reibungslos funktioniert. Hin und wieder kommt zwar mal eine Anfrage von Kunden, die aber schnell gelöst werden kann.

“Mein Hund hat die Gelben Seiten gefressen…”

Dass dieses robuste System auch lahmgelegt werden kann, haben schon die Kunden aller Internetprovider schmerzlich feststellen müssen: Der Anschluss geht zwar, pingen lässt sich auch alles, aber irgendwie kommt man nicht ins Netz. Wenn dem so ist, klemmt meistens irgendwas beim so genannten Resolver, das ist die Adresse, die wir beim Anschluss eines Computers oder Routers beim Anschliessen ans Internet konfigurieren müssen.

Wer eine eigene Homepage oder einen Mailserver betreibt, weiss, dass es daneben noch den autoritativen DNS-Server gibt. Beide, Resolver und autoritativer DNS machen scheinbar dasselbe, nämlich Rechnernamen in IP-Adressen “umrechnen”. Deshalb können beide auch auf ein und demselben Computer laufen. Eigentlich spricht nichts dagegen.

Das gilt aber auch nur dann, wenn ich diesen Dienst nicht für hunderte oder tausende Kunden anbiete. Über unser Extranet können die Kunden nämlich ihre Domains und Hostnamen komfortabel selber verwalten und dort auch Domänen eintragen, die ihnen gar nicht gehören. Was sich jetzt erst mal nach einer Sicherheitslücke anhört, ist aber durchaus sinnvoll: Vielleicht bereitet der Kunde ja eine Migration zum Swisscom-DNS um (was erst recht sinnvoll ist!).

Dann dürfen diese Informationen aber nicht in das produktive DNS gelangen, ohne vorher von einem Hostmaster geprüft und aktiv geschaltet zu werden. Denn sonst passiert folgendes: Ein beliebiger Internet-Kunde ruft eben jene Domain ab und benutzt dabei den autoritativen Server als Resolver. Da soeben jemand die Domain dort geändert hat, ist jetzt dieser Rechner der erste Server, der nach dieser Adresse gefragt wurde. Und da er die Infos gleich parat hat, spuckt er sie auch sofort aus. Und der Kunde gelangt auf die falsche Website, was einer mittleren Katastrophe gleichkommt!

Normalerweise benimmt sich ein Resolver so, dass er im hierarchischem Domain Name System sich durch die Hierarchie durchfragt. Auf diese Weise kommt er gar nicht auf die vielleicht fehlerhaft angelegte Domain, weil er zuerst bei dem zuständigen Registrar nachfragt, wem denn die Domain gehöre.

Viele Rechner – Eine Adresse

Die manuelle Überprüfung ist natürlich nicht mehr zeitgemäss. Schon deshalb nicht, weil sich das Internet nicht nach den westeuropäischen Bürozeiten richtet. Deshalb hatten wir uns entschlossen, Resolver und autoritative Server zu trennen. Das macht das Auftreten des eben beschriebenen Phänomens unmöglich.

Und um das Ganze noch spannender zu gestalten, wird eine Technik eingesetzt, die sich als De-Facto-Standard bei DNS durchgesetzt hat: Wir verwenden Anycast, um die Server bereitzustellen. Das bedeutet, dass verschiedene Rechner unter einer IP-Adresse erreichbar sind. Das Netz kümmert sich dann automatisch (naja, fast), darum dass die Anfragen zum nächsten funktionierenden Server gelangen und dort beantwortet werden. Falls dann ein Server ausfällt, wird automatisch auf einen anderen umgeleitet, ohne dass wir manuell eingreifen müssen.

Lektion? Gelernt!

Es ist ratsam, beim Neuaufbau eines DNS-Service, die beiden Aspekte “Resolver” und “Autoritativ” zu trennen. Bei einer nachträglichen Änderung nach mehreren Jahren muss man nämlich damit rechnen, dass die eigenen Kunden die Resolveradressen bereits überall in den meist historisch gewachsenen Infrastrukturen konfiguriert haben diese wiederum bereits einige Wechsel des Administrators hinter sich haben. Dann muss man mit allen diesen Kunden reden und ihnen bei der Umstellung helfen. Und, Hand auf’s Herz: Wir Sysadmins bevorzugen doch gerade jetzt in der kalten Jahreszeit die heimelige Wärme unserer eigenen Shell, oder?