DNS
Was zwischen dem Eintippen von „example.com“ und dem ersten Byte passiert: wie eine weltweit verteilte Datenbank Namen in Adressen übersetzt, warum Änderungen „Zeit brauchen“ und warum es so oft am DNS liegt.
Rechner im Internet finden sich über IP-Adressen. Menschen merken sich Namen. Das Domain Name System (DNS) übersetzt das eine ins andere – example.com in 192.0.2.10. Es ist eine der größten verteilten Datenbanken der Welt, und es gibt keinen zentralen Server, der alle Namen kennt.
Stattdessen ist DNS eine Hierarchie: Die Root-Server kennen die Server für .com oder .de, die kennen die Server jeder einzelnen Domain. Ein Resolver fragt sich durch und merkt sich die Antworten so lange, wie ihre TTL erlaubt. Deshalb ist DNS schnell – und deshalb brauchen Änderungen Zeit.
Namen von rechts nach links
Ein Domainname wird von rechts nach links gelesen, wie eine Postadresse von Land zu Straße. Ganz rechts steht eigentlich noch ein unsichtbarer Punkt: die Wurzel.
Jede Ebene ist für die darunter zuständig und kann Verantwortung weitergeben – man sagt: delegieren. Die Wurzel delegiert .de an die DENIC in Frankfurt, die DENIC delegiert example.de an die Server, die der Inhaber angibt. Diese Server heißen autoritativ: Sie kennen die echte Antwort, alle anderen geben nur Kopien weiter.
Eine Anfrage, Schritt für Schritt
Dein Rechner fragt nicht selbst die ganze Kette ab. Er gibt die Frage an einen rekursiven Resolver weiter – meist beim Internetanbieter oder ein öffentlicher wie 1.1.1.1 oder 8.8.8.8. Der Resolver erledigt die Arbeit:
Der kalte Fall ist selten. Die Adressen der .com- und .de-Server hat jeder Resolver ohnehin im Cache, die Root-Server werden kaum noch gefragt. Trotzdem sind sie entscheidend: Es gibt 13 Root-Server-Namen, von a.root-servers.net bis m.root-servers.net, betrieben von zwölf Organisationen. Hinter jedem Namen stehen dank Anycast viele Maschinen weltweit – zusammen weit über tausend Standorte. Eine Anfrage landet automatisch beim nächstgelegenen.
Was im DNS steht
DNS kennt nicht nur Adressen. Jeder Eintrag (Resource Record) hat einen Typ. Mit dem Werkzeug dig (oder nslookup) kann man sie abfragen:
TTL: warum Änderungen „Zeit brauchen“
Jede Antwort trägt eine TTL (time to live): So viele Sekunden darf sie zwischengespeichert werden. Caches gibt es auf jeder Ebene – im Browser, im Betriebssystem, im Resolver, sogar in der JVM. Ändert man die IP-Adresse eines Servers, sehen Nutzer die neue erst, wenn ihr Cache abgelaufen ist. Das ist das, was oft „DNS-Propagation“ genannt wird: Es breitet sich nichts aus, es laufen nur Kopien ab.
Die Profi-Technik daraus: Ein paar Tage vor einem Umzug die TTL senken, etwa auf fünf Minuten. Dann umziehen – alle sind schnell auf der neuen Adresse. Danach die TTL wieder erhöhen, denn kurze TTLs bedeuten mehr Anfragen und etwas langsamere erste Aufrufe. Wichtig: Die Senkung wirkt erst, wenn die alte, lange TTL einmal abgelaufen ist.
Sicherheit und Ausfälle
DNS stammt aus dem Jahr 1983 und wurde für ein freundliches Netz entworfen. Anfragen gehen meist unverschlüsselt per UDP über Port 53. Daraus ergeben sich drei Probleme:
Gefälschte Antworten
Wer einem Resolver eine falsche Antwort unterschiebt, bevor die echte ankommt, leitet alle seine Nutzer um – Cache Poisoning. 2008 zeigte Dan Kaminsky, wie leicht das ging. DNSSEC signiert Einträge kryptografisch, ist aber längst nicht überall eingeführt.
Mitlesen
Jeder auf dem Weg sieht, welche Namen du abfragst. DNS over HTTPS (DoH) und DNS over TLS (DoT) verschlüsseln die Anfragen; viele Browser nutzen das inzwischen.
Ausfälle
Ist DNS weg, ist alles weg – auch wenn die Server laufen. Im Oktober 2021 war Facebook rund sechs Stunden unerreichbar, weil seine DNS-Server nach einer Fehlkonfiguration aus dem Internet verschwunden waren.
Nicht umsonst kursiert unter Administratoren der Spruch: „It's always DNS.“ Wenn etwas Unerklärliches mit dem Netz passiert, lohnt sich der erste Blick dorthin.
Für Entwickler übersetzt
InetAddress[] alle = InetAddress.getAllByName("www.example.com"); // A und AAAA
for (InetAddress a : alle) System.out.println(a.getHostAddress());
// Die JVM hat einen eigenen DNS-Cache – unabhängig von der TTL des Eintrags.
// Setzen, bevor der erste Name aufgelöst wird:
Security.setProperty("networkaddress.cache.ttl", "60"); // Erfolge: 60 s
Security.setProperty("networkaddress.cache.negative.ttl", "5"); // Fehlschläge: 5 s| Thema | Was man wissen sollte |
|---|---|
| JVM-Cache | Ohne Einstellung hält die JVM erfolgreiche Antworten typischerweise 30 Sekunden, fehlgeschlagene 10 Sekunden. In älteren Konfigurationen mit Security Manager sogar für immer – dann sieht ein langlaufender Dienst einen Server-Umzug nie. |
| Blockieren | Eine DNS-Auflösung ist ein blockierender Aufruf, der bei Problemen Sekunden dauern kann. Wer Antwortzeiten misst, sollte DNS-Zeit von Verbindungszeit trennen. |
| Eigener Resolver | Seit Java 18 lässt sich die Namensauflösung über die Schnittstelle InetAddressResolver austauschen – praktisch für Tests. |
| Kubernetes | Dienste finden sich dort über DNS-Namen wie bestellung.shop.svc.cluster.local. Kurze Namen werden mit mehreren Suchdomänen ausprobiert – ein externer Name kann so mehrere vergebliche Anfragen auslösen, bevor er aufgelöst wird. Ein Punkt am Ende (api.example.com.) macht ihn eindeutig. |
| Testen | Die hosts-Datei des Betriebssystems wird vor DNS gefragt. Ein Eintrag dort lenkt einen Namen auf dem eigenen Rechner um – ideal zum Ausprobieren eines neuen Servers. |