Was ist DNS und wie funktioniert die Namensauflösung

Was DNS bei jeder Anfrage wirklich tut

Jede Anfrage an example.com beginnt mit einer Abfrage, die mit Ihrer Anwendung nichts zu tun hat: Etwas muss diesen Namen erst in eine IP-Adresse umwandeln, bevor ein einziges TCP-Paket die Maschine verlässt. Diese Übersetzung ist DNS, das Domain Name System, und sie läuft bei jeder Anfrage, egal ob der Client ein Browser, curl oder ein Backend-Dienst ist, der einen anderen über dessen Hostnamen aufruft.

Dahinter steckt keine einzelne Tabelle. DNS ist eine Hierarchie von Servern: Jeder ist für einen Ausschnitt des Namensraums zuständig, und sie werden der Reihe nach befragt, bis die Antwort zurückkommt. Diese Kette zu kennen macht aus “die Seite ist down” entweder “das Zertifikat ist abgelaufen” oder “der Record zeigt noch auf die alte IP” – zwei völlig verschiedene Fehlerbilder, die im Browser-Tab identisch aussehen.

Wie ein rekursiver Resolver die DNS-Hierarchie durchläuft

Zwei Server-Typen teilen sich die Arbeit, und ihre Aufgaben sind klar getrennt. Der rekursive Resolver ist derjenige, mit dem Ihre Maschine spricht: der Ihres Providers, oder ein öffentlicher wie 1.1.1.1 oder 8.8.8.8. Er übernimmt den Weg für Sie und liefert am Ende eine einzige Antwort zurück. Die autoritativen Server halten die eigentlichen Records einer Domain, verteilt auf eine Hierarchie, die die Punkte im Namen widerspiegelt.

1
2
3
4
5
6
7
8

Client   ->  Resolver                             eine Anfrage, eine Antwort
             Resolver -> Root-Server              "wer verwaltet .com?"
                      <- Nameserver für .com
             Resolver -> .com-TLD-Server          "wer verwaltet example.com?"
                      <- Nameserver für example.com
             Resolver -> Nameserver example.com   "A-Record für example.com?"
                      <- 93.184.216.34
Client   <-  Resolver                             93.184.216.34

Root-Server wissen nichts über example.com. Sie wissen nur, welche Server .com verwalten. Der .com-TLD-Server (Top-Level-Domain) hält den Record ebenfalls nicht selbst; er weiß nur, welche Nameserver für example.com autoritativ sind – die, auf die Ihr Registrar zeigt, wenn Sie die Domain einrichten. Nur dieser letzte Server hält den A-Record und liefert eine IP zurück. Drei Roundtrips, damit Ihre Maschine diese Hierarchie nie kennen muss.

Der größte Teil dieses Wegs findet bei einer echten Anfrage gar nicht statt. Resolver cachen Antworten von Root- und TLD-Servern stundenlang oder tagelang, weil die sich kaum ändern – eine echte Anfrage startet also meist schon beim autoritativen Server für den konkreten Record. Oft kommt sie nicht einmal so weit: Die Antwort liegt bereits im Cache.

Die DNS-Record-Typen, die Sie wirklich brauchen

Der autoritative Server einer Domain hält eine Reihe von Records, jeder eine andere Antwort auf eine andere Frage:

Der CNAME ist der Stolperstein für die meisten. Er zeigt nicht auf eine IP, sondern auf einen anderen Namen, und der Resolver muss auch diesen nachschlagen, der Kette folgend, bis er auf einen A- oder AAAA-Record trifft. Ein CDN oder eine SaaS-Plattform gibt Ihnen genau deshalb einen Hostnamen wie abcd123.cloudfront.net: Sie kann die IPs hinter diesem Namen jederzeit ändern und je nach Herkunft der Anfrage eine andere zurückgeben, ohne dass Sie Ihren DNS-Record anfassen müssen.

Eine Einschränkung trifft jeden, der eine nackte Domain einrichtet: Ein CNAME kann nicht neben anderen Records auf demselben Namen existieren, und der Zonen-Apex (example.com ohne Subdomain) braucht immer NS- und SOA-Records. Sie können den Apex also nicht per CNAME auf den Hostnamen eines CDN zeigen lassen, nur eine Subdomain wie www. Anbieter umgehen das mit einem Verfahren, das sie ALIAS, ANAME oder CNAME-Flattening nennen: Der autoritative Server löst das Ziel selbst auf und liefert einen A-Record zurück, sodass der Apex für jeden Client wie ein gewöhnlicher Adress-Record aussieht, während er die sich ändernden IPs des CDN dahinter trotzdem verfolgt.

Wie Sie DNS mit dig abfragen

dig stellt diese Fragen direkt, ohne dass Ihnen der Browser-Cache dazwischenfunkt.

1

dig example.com

Entscheidend ist die ANSWER SECTION:

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Fünf Felder in dieser Reihenfolge: der abgefragte Name, die TTL in Sekunden (wie lange diese Antwort gecacht werden darf), die Klasse (IN für Internet, praktisch immer diese), der Record-Typ und der Wert. Eine TTL von 300 bedeutet: Jeder Resolver, der diese Antwort im Cache hat, fragt sie spätestens nach fünf Minuten erneut ab.

Fragen Sie statt des Standard-A einen bestimmten Typ ab:

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Fügen Sie +short hinzu, wenn Sie nur den Wert wollen – genau das, was Sie in einem Skript brauchen:

1
2

dig +short example.com
93.184.216.34

Fragen Sie mit @ einen bestimmten Resolver ab. So prüfen Sie, ob eine Änderung bei einem Anbieter schon angekommen ist, bevor sie bei Ihnen ankommt:

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

+trace spielt den gesamten Weg noch einmal ab, vom Root-Server bis zur autoritativen Antwort, statt einem gecachten Ergebnis zu vertrauen:

1

dig +trace example.com

nslookup erledigt dieselbe Grundaufgabe mit einer älteren, umständlicheren Oberfläche. Kennen sollte man es trotzdem, weil es standardmäßig unter Windows dabei ist, wo dig oft fehlt.

Warum eine DNS-Änderung Zeit braucht: TTL und Caching

Sie ändern einen Record, und er erscheint nicht überall sofort. Diese Verzögerung wird “Propagation” genannt – ein Wort, das etwas suggeriert, das sich Kopie für Kopie durchs Internet verbreitet. Nichts verbreitet sich. Der neue Wert ist auf dem autoritativen Server aktiv, sobald Sie ihn speichern. Was Zeit braucht, ist jeder Resolver, der die alte Antwort schon gecacht hat und sie weiter ausliefert, bis diese Kopie abläuft.

Das ändert die Frage, die eigentlich wichtig ist. Nicht “wie lange dauert die Propagation”, sondern “welche TTL hatte der alte Record, und wie viele Resolver haben ihn gecacht”. Eine TTL von 300 Sekunden bedeutet, dass ein Resolver, der vor einer Minute abgefragt hat, die alte Antwort höchstens noch vier weitere Minuten ausliefert. Eine TTL von 86400 bedeutet, dass irgendein Resolver noch bis zu einem Tag nach Ihrer Änderung mit der alten IP antwortet. Manche Anbieter ignorieren die von Ihnen gesetzte TTL sogar und cachen länger als gewünscht – der andere Grund, warum zwei Personen in unterschiedlichen Netzen mitten in einer Änderung ehrlich unterschiedliche Antworten sehen können.

Planen Sie die Änderung also, statt sie einfach auszusitzen. Einen Tag vor einer geplanten Migration zu einem neuen Server oder einem neuen CDN senken Sie die TTL des betroffenen Records auf 60 oder 300 Sekunden. Diese niedrige TTL muss zuerst die Caches erreichen und die langlebigen Kopien ablaufen lassen. Dann nehmen Sie die eigentliche Änderung vor: Jeder Resolver aktualisiert sich jetzt im neuen kurzen Fenster statt im alten langen. Setzen Sie die TTL wieder hoch, sobald der neue Wert bestätigt ist.

Häufige DNS-Fehler, und wann das Problem nicht DNS ist

Ein verwaister CNAME ist der häufigste Fehler in der Praxis. Eine Subdomain zeigt noch auf einen abgeschalteten Dienst, einen alten S3-Bucket oder eine gelöschte CDN-Distribution, und wer immer diesen Namen auf der anderen Seite beansprucht, kann eigene Inhalte unter Ihrer Domain ausliefern. Löschen Sie den DNS-Record am selben Tag, an dem Sie das Ziel abschalten, auf das er zeigt – nicht Wochen später.

Fehlende oder falsche MX-Records wirken wie ein Mailserver-Problem. Wenn ausgehende E-Mails funktionieren, aber nichts ankommt, prüfen Sie den MX-Record der Domain, bevor Sie an der Mailserver-Konfiguration schrauben; er zeigt vielleicht noch auf einen Dienst, von dem Sie vor Monaten weggezogen sind.

Viele “DNS ist kaputt”-Meldungen haben mit DNS gar nichts zu tun. Liefert dig example.com die aktuell richtige IP, und die Seite lädt trotzdem nicht, war die Auflösung bereits erfolgreich und das Problem liegt weiter unten: eine Firewall-Regel, ein nicht passendes Zertifikat beim TLS-Handshake, oder ein Reverse Proxy, der anhand eines Host-Headers routet, den er nicht erkennt. Prüfen Sie die Antwort mit dig, bevor Sie aus der Browseranzeige Schlüsse ziehen.

Wo Sie zuerst nachsehen, wenn eine Domain nicht auflöst

Führen Sie dig +short <Domain> gegen Ihren System-Resolver und gegen einen öffentlichen aus (dig @1.1.1.1 +short <Domain>). Stimmen sie nicht überein, sind Sie mitten in einer Änderung, und die alte TTL sagt Ihnen, wie viel länger Sie noch warten müssen. Stimmen sie überein und die IP ist korrekt, hat DNS seine Aufgabe erledigt: Prüfen Sie als Nächstes TLS, Routing oder die Anwendung. Ist die IP falsch oder kommt gar nichts zurück, beheben Sie das am autoritativen Nameserver. Das Leeren Ihres lokalen Caches ändert nichts daran, was andere sehen.

Verwandte Artikel

• Was ist ein CDN und wie funktioniert es
• Was ist TLS und wie funktioniert die HTTPS-Verschlüsselung
• Was ist ein Reverse Proxy und wie funktioniert er