Im Rahmen meines Studiums beschäftige ich mich mit vielen Themen. Darunter auch solche, von denen man eigentlich nicht viel mitbekommt. Oft weil die Technologien in diesen Bereichen bereits seit relativ langer Zeit verwendet werden und bereits „erwachsen geworden sind“. Das DNS (Domain Name System) ist eines dieser Themen. Viele Leute bekommen nicht einmal mit, was das DNS alles tut. Wir wissen alle: Wenn wir eine Adresse in unseren Browser eingeben erscheint die Website dazu. Die meisten wissen auch, dass das DNS hier im Hintergrund tätig wird und die Adresse in eine passende IP-Adresse „übersetzt“.

So gut wie niemand macht sich aber heutzutage noch Gedanken darüber, wo diese Informationen eigentlich herkommen. Woher weiß der  DNS-Server von Cloudflare (1.1.1.1), dass genau diese IP zu der Adresse gehört? Und wie werden diese Daten gespeichert und verwaltet?

Das DNS ist im Prinzip eine baumartig organisierte, verteilte Datenbank. Zu Zeiten des ARPANETs in den 1970er bestand das Netz aus wenigen hundert Hosts, die Zuordnung von Namen auf Adressen erfolgte in einer einfachen Textdatei Namens ‚HOSTS‘. Diese Datei findet man übrigens Heute noch in sowohl Windows als auch UNIX-Systemen.

Als das Netz später auf TCP/IP umstellte stieg die Anzahl der Hosts rasant an. Daraus ergaben einige Probleme. Zum einen entstand aufgrund der steigenden Anzahl an Hosts durch das Verteilen der HOSTS eine große Menge an Datenverkehr, zum Anderen gab es aufgrund der Größe des Netzes Konsistenzprobleme bei der Verteilung der Datei. Auch Kollisionen bei der Namensauflösung aufgrund doppelt verwendeter Namen wurden zu einem Problem. Ein Nachfolger für die HOSTS musste entwickelt werden. Es sollte dezentralisiert und hierarchisch aufgebaut sein. In 1984 veröffentlichte Paul Mockapetris die RFCs 882 und 883, die das Domain Name System beschreiben und seither mehrere Male aktualisiert und erweitert wurden. Beispielsweise definiert RFC920 die Anforderungen an eine Domain und legt fest, dass das Management der Namensräume aufgeteilt werden kann. Hier wurden die Top Level Domains .arpa, .com, .edu, .gov, .mil und .org festgelegt.

Diese verteilte Datenbank kann aber noch deutlich mehr als nur Telefonbuch zu spielen.  Ip-Adressen sind lediglich einer von vielen Record-Typen.  Record-Typen sind die eigentlichen Datensätze in dem DNS. Hierbei handelt es sich um textbasierte Einträge. Diese können mehrere Typen haben. Neben den Typen A und AAAA für IPv4 und IPv6, gibt es z.B. auch den Typen TXT. Dieser kann vielseitig eingesetzt werden. In der Praxis wird er z.B. für das Ausstellen von SSL-Wildcard-Zertifikaten, oder die Definition von Regeln zu Spam-Prävention verwendet. Der Dienst LetsEncrypt bietet TXT-Records als Möglichkeit an um Wildcard-SSL-Zertifikate auszustellen. Für diese muss die Inhaberschaft einer Domain verifiziert werden. Dies geschieht ¨ indem der Antragsteller eine Zeichenkette erhält, die er in einen TXT-Record mit dem Namen ’ acme-challenge.’ schreibt.  LetsEncrypt stellt daraufhin eine Anfrage für diesen Record, an den für die Domain zuständigen Nameserver. Wenn dieser mit der Zeichenkette antwortet, ist bewiesen, dass der Antragsteller Zugriff auf den Authoritative Nameserver der Domain hat. Somit darf er diese verwalten und ein Wildcard-SSL-Zertifikat kann bedenkenlos ausgestellt werden. Spam-Prävention wird unter Anderem über das sogenannte SPF-Protokoll (Sender Policy Framework) betrieben. Hierfür kann ein TXT-Record angelegt werden der mit „’v=spf1’“ beginnt und definiert welche Server berechtigt sind, Mails im Namen dieser Domain zu verwenden. Das SPF-Protokoll ist so weit verbreitet, dass es mittlerweile einen eigenen Record Typen ’SPF’ gibt. Die Nutzung eines TXT-Records funktioniert aber weiterhin.

Bei wem dieser kleine Ausblick das Interesse geweckt hat, der kann meine Ausarbeitung lesen, die ich dazu im Rahmen des Studiums angefertigt habe. Diese gibt einen etwas detailreicheren Überblick.