Stolperfallen im Domain Name System
Jeder fleißige Internetznutzer benutzt es mehrmals täglich, meistens aber unbewusst: Das Domain Name System, kurz: DNS. Die oft als «Gelbe Seiten des Internet» bezeichnete Datenbank ist eine gigantische verteilte Informationsbibliothek, die auch dem erfahrenen Surfer manchmal noch magisch vorkommt. Die Schwierigkeiten, die sich beim Betrieb einer eigenen Internetplattform, sei es Web- oder Mailserver ergeben und wie man sie umschiffen kann, wird in diesem Artikel behandelt.
Es begann mit einer Datei
Als das Internet noch aus einer Sammlung einiger Dutzend Computer bestand, konnte die Übersetzung der Rechnernamen (z.B. www.example.net) zu den eigentlichen IP-Adressen (z.B. 123.45.67.8) noch in einer Datei gehalten werden, die einfach hosts hieß und von Zeit zu Zeit über die einzelnen Rechner kopiert wurde. Sehr schnell wurde aber schon damals (als «Surfen» noch einen Wassersport bezeichnete) klar, dass bei dem drastischen Wachstum des Netzes ein leistungsfähigeres System benötigt würde.
Das 1983 neu geschaffene Domain Name System erfüllte bereits die Anforderungen, die man an ein verteiltes Datenbanksystem haben kann. Heute besteht sie aus tausenden Rechnern, die weltweit verteilt sind, damit das System vor Ausfällen gut geschützt ist. Das DNS speichert längst nicht mehr nur Netzwerkadressen sondern kann alle möglichen Informationen aufnehmen. So spielt DNS beim Versand von E-Mails eine große Rolle. Hierbei werden die Mail-Datensätze, so genannte MX-Records abgefragt, die den zuständigen Mailserver einer Domain liefern.
Bedingt durch die hierarchische Struktur des DNS können Domains in Unterdomains unterteilt werden oder sogar je nach geografischer Lage unterschiedliche Antworten liefern, wie das bei großen Websites der Fall ist, die die Netzwerkauslastung auf ihre weltweit verteilten Rechenzentren aufteilen wollen.
Back to the Roots!
Der «Anfasspunkt» für jede Abfrage ist einer der so genannten Root-Server, man kehrt gewissermaßen auf die Wurzeln des Internet zurück. Die Root-Zone besteht aus 13 Rechnern, die ihrerseits auf weitere zuständige Name Server verweisen. Anfragen für eine Internetadresse, also z.B. www.example.net werden rekursiv von mehreren zuständigen Servern beantwortet. Das bedeutet, dass zunächst der letzte Teil der durch Punkte getrennten Adresse, in diesem Fall .net angefragt wird. Der Root-Server wird nun wissen, welche Vergabestelle für die Top Level Domain .net zuständig ist und wird den Anfragesteller an dessen Name Server verweisen. Für den Rootserver ist die Aufgabe damit beendet und er kann sich einer der Millionen weiteren Anfragen, die pro Stunde auf ihn einprasseln, zuwenden.
Der Fragesteller, also der zum Surfen benutzte Computer, kann sich nun an den genannten Server wenden. Dieser wird ihm aber auch lediglich die Adresse zweier (oder mehr) Nameserver desjenigen Providers nennen, bei dem die Domain example.net gehostet wird. Einer derer allerdings kennt dann in der Regel tatsächlich die IP-Adresse des Rechners www.example.net. In diesem Fall ist es ein Server der Organisation IANA, die u.a für die Verwaltung der Root-Zonen zuständig ist.
Wer ist hier zuständig?
Der in der oben genannten Kette «letzte» Server wird auch als autoritativer Server bezeichnet; wir nennen ihn im Folgenden einfach den zuständigen Nameserver. Für ihn gelten einige Besonderheiten, von denen weiter unten noch zu sprechen sein wird.
Damit nun nicht jede Anfrage im Internet den gesamten rekursiven Vorgang wiederholen muss, gibt es eine Reihe von Zwischenspeichern, die so genannten Resolver, die das Endergebnis speichern und bei wiederholten Anfragen schnell ausliefern können. Außerdem sind sie in der Lage, die rekursiven Anfragen selbständig, sozusagen im Auftrag zu erledigen.
Internetprovider betreiben meist für ihre angeschlossenen DSL-Kunden mehrere solcher Resolver, um die ausgehenden Anfragen gering zu halten. Das ist nicht immer unproblematisch, da damit auch gewisse Einflussmöglichkeiten verbunden sind. So hat die Zeitschrift c’t mehrfach darauf hingewiesen, dass Anfragen an den Resolver des Providers, die z.B. wegen falsch geschriebener Adressen nicht beantwortet werden konnten, mit einer anderen Adresse beantwortet werden, die zum Portal des Providers oder eines Werbepartners führt.
Dies kommt einer Manipulation gleich, die auch bei den viel diskutierten Netzsperren zur Anwendung kommen sollte. Fatal wird ein solches Verhalten beim Versenden von E-Mails, da die Mail in dem Fall von einem anderen Server abgefangen werden kann. Um solche Manipulationen zu vermeiden, kann man auf einen alternativen Resolver ausweichen. Google bietet z.B. einen offenen Resolver mit der einprägsamen IP-Adresse 8.8.8.8 an, auf den man ausweichen kann.
Mehr Resolver
Inzwischen (der Original-Artikel bezieht sich auf die Situation im Jahr 2011) haben weitere große Anbieter solche Resolver mit praktischen Zusatzfähigkeiten, wie dem Filtern von Malware ergänzt – das ist zwar auch wieder eine Manupulation, aber man darf seinen Resolver ja selber aussuchen. Daher hier ein Überblick:
| Anbieter | IPv4-Adressen | IPv6-Adressen | Protokolle | Besonderheiten |
|---|---|---|---|---|
8.8.8.8, 8.8.4.4 | 2001:4860:4860::8888, ::8844 | DNS, DoH, DoT | Hohe Verfügbarkeit, keine Filterung, unterstützt DNSSSEC | |
| Cloudflare | 1.1.1.1, 1.0.0.1 | 2606:4700:4700::1111, ::1001 | DNS, DoH, DoT | Sehr schnelle Antwortzeiten, keine IP-Logs, bietet “1.1.1.1 for Families” mit Malware- und Jugendschutzfiltern |
| Quad9 | 9.9.9.9, 149.112.112.112 | 2620:fe::fe, 2620:fe::9 | DNS, DoH, DoT | Blockiert bekannte Schadseiten, keine Speicherung personenbezogener Daten, basiert in der Schweiz |
Will mam mehr Kontrolle, bietet es sich an, einen eigene aufzusetzen: Mit dem Projekt Pi-Hole setzt man ohne Vorkenntnisse einen Resolver für das lokale Netz auf, der Werbeeinblendungen zu einem großen Teil wegfiltert.
Wem das immer noch nicht reicht (🙋♂️), der setzt einen autoritativen Server mit PowerDNS auf in Kombination mit dem PowerDNS Recursor. Diese Kombination lässt sich gut managen über API, PostgreSQL, Prometheus und ist enorm leistungsfähig. Ich habe bereits bei einem großen Mailprovider die Blocklisten-Infrastruktur mit PowerDNS aufgebaut und kann bestätigen, dass das eine sehr solide Lösung ist.
Letztlich braucht es immer ein gewisses Maß an Vertrauen, wenn man nicht einen eigenen Resolver verwenden kann. Die Installation eines eigenen Resolvers ist übrigens immer dann angeraten, wenn man einen eigenen Internetservice anbietet, da viele Server-Applikationen selber DNS-Anfragen versenden. Dieser ausgehende Netzwerkverkehr kann dann unter Umständen den eigentlichen Dienst ausbremsen.
Vertrauensstellung
Eine empfehlenswerte Maßnahme, vor allem für Internetprovider und -dienstanbieter ist die Trennung von autoritativen Nameservern und Resolvern: Bietet nämlich ein Provider für die Domains seiner Kunden den zuständigen DNS an (was in der Regel der Fall ist), können durch manipulierte Einträge unter Umständen Domains «entführt» werden, wenn der anfragende Computer denselben Server als Resolver verwendet. So erhält er nämlich eine Antwort für eine Domain, für die er gar nicht zuständig ist! Würde man nämlich den oben genannten (langen) rekursiven Weg gehen, erhielte man die richtige Antwort, da die Anfrage dann garantiert über den wirklich zuständigen Server gehen würde. Das lässt sich relativ leicht einrichten, indem man auf dem autoritativen Server rekursive Abfragen abschaltet.
Das DNS wurde auf der Basis von Offenheit und Vertrauen entworfen und genügt nicht mehr den heutigen Sicherheitsanforderungen. Wegen der oben genannten möglichen Probleme wurde bereits vor Jahren der Standard «Secure DNS», kurz DNSSEC, entworfen, der nach langer Entwurfszeit heute produktiv ist.
Im Wesentlichen beruht dieser Service auf fälschungssicheren DNS-Einträgen. Gewährleistet wird das durch eine kryptografische Signatur für jeden einzelnen Namenseintrag und die Signierung durch die jeweils übergeordnete Instanz. Dadurch wird eine Kette des Vertrauens gebildet, vorausgesetzt natürlich, man vertraut in letzter Instanz den US-Amerikanischen Behörden, die de facto die Aufsicht über Internetorganisationen wie ICANN haben.
Der Anwender bekommt von dieser Absicherung nichts mit. Wird tatsächlich eine Antwort eines Servers gefälscht, liefert der letztlich antwortende Resolver lediglich ein «nichts gefunden».
Ausblick
Das heutige System ist nicht perfekt, funktioniert aber stabil und ist einigermaßen robust. Die Netzanbieter tun ihr Übriges, um ihre Nameserver vor Ausfällen oder gar Attacken aus dem Netz zu schützen. Mit der Einführung von DNSSEC wird vor allem bei sensiblen Diensten wie Online-Banking mehr Sicherheit geboten werden. Allerdings kommt auf die Betreiber auch eine höhere Rechenlast zu, da die Signaturen aufwändig berechnet und überprüft werden müssen. Mit der allmählichen Einführung des neuen Internetprotokolls IPv6 kommen weitere Herausforderungen hinzu, da sich die Anzahl der Adressen potenzieren wird. Diese können heute kaum abgeschätzt werden.