Wie DNS funktioniert: rekursive Auflösung, Caching und TTLs im Diagramm

Du änderst einen A-Record, führst dig aus und siehst die neue Adresse. Deine Kollegin in einem anderen Büro bekommt eine Stunde später immer noch die alte. Eine neue Subdomain funktioniert bei dir und liefert bei einem Kunden NXDOMAIN. Nichts davon ist Zufall: Es folgt daraus, wie DNS-Auflösung und Caching funktionieren, und sobald du den Weg einer Abfrage zeichnen kannst, kannst du es vorhersagen.

Dieser Beitrag verfolgt eine Abfrage vom Browser bis zum autoritativen Server und zurück, mit einem Diagramm, und behandelt dann TTLs, negatives Caching, Delegation, Transport und die Fehlerbilder, die dir in Produktion begegnen.

Die vier Rollen in jeder Abfrage

Eine Abfrage berührt bis zu vier Arten von Servern. Jeder kennt einen anderen Teil der Antwort.

Die Root ist nicht eine Maschine. Es gibt 13 Root-Server-Identitäten, a bis m.root-servers.net, betrieben von 12 unabhängigen Organisationen, und Anycast verteilt sie auf mehr als 2.000 Instanzen weltweit, laut root-servers.org im November 2026.

Eine Abfrage Schritt für Schritt

Angenommen, dein Browser braucht app.example.com und nirgends ist etwas gecacht:

1. Der Browser prüft seinen eigenen Cache und fragt dann den Stub-Resolver des Betriebssystems.
2. Der Stub schickt eine Abfrage mit dem Flag „recursion desired“ an den konfigurierten rekursiven Resolver: Was ist der A-Record für app.example.com?
3. Der Resolver hat nichts gecacht, also fragt er einen Root-Server. Die Root kennt die Antwort nicht, weiß aber, wer com betreibt, und liefert deshalb ein Referral: die NS-Records für com plus deren Adressen (Glue).
4. Der Resolver fragt einen com-TLD-Server, der ein weiteres Referral liefert: die Nameserver für example.com.
5. Der Resolver fragt einen dieser autoritativen Server, der die Antwort liefert: app.example.com. 300 IN A 203.0.113.10.
6. Der Resolver cacht jeden gelernten Record für seine TTL und gibt die Antwort an den Stub zurück, der sie an den Browser weiterreicht.

Der Stub stellt eine rekursive Abfrage: Er will eine endgültige Antwort. Der Resolver stellt iterative Abfragen: Jeder Server liefert entweder die Antwort oder einen Verweis auf jemanden, der näher daran ist. Root- und TLD-Server jagen nie Antworten für dich.

Den iterativen Teil kannst du mit dig +trace beobachten, das an der Root beginnt, statt den Cache deines Resolvers zu nutzen (Ausgabe gekürzt):

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

Moderne Resolver wenden außerdem QNAME-Minimierung an (RFC 9156): Sie fragen die Root nur nach com und die TLD nur nach example.com, sodass weiter oben liegende Server nie den vollständigen Namen sehen, den du abgefragt hast.

Caching und TTLs

Jeder Record trägt eine Time to Live in Sekunden. Ein Resolver, der app.example.com mit einer TTL von 300 cacht, antwortet die nächsten fünf Minuten aus dem Cache, zählt dabei herunter und fragt erst dann wieder den autoritativen Server. Browser und Betriebssysteme halten obendrauf eigene kurze Caches.

Das ist es, was man Propagation nennt. Wenn du einen Record änderst, wird nichts irgendwohin gepusht. Jeder Resolver, der den alten Wert gecacht hat, liefert ihn weiter, bis seine Kopie abläuft, also ist der schlimmste Fall ungefähr die alte TTL, nicht die neue. Resolver kappen außerdem sehr lange TTLs: Unbound zum Beispiel begrenzt gecachte Records standardmäßig auf einen Tag.

Praktische Regeln für Änderungen:

• Senk die TTL vor einer geplanten Änderung. Hat ein Record eine TTL von 86400, setz sie mindestens einen Tag vor der Migration auf 300, warte, bis die alte TTL abgelaufen ist, nimm die Änderung vor und erhöhe sie dann wieder.
• Nutze kurze TTLs nur dort, wo du schnelles Failover brauchst. Eine TTL von 60 Sekunden bedeutet mehr Abfragen bei deinem Anbieter und mehr Cache-Misses für Benutzer, jeder davon kostet eine volle Abfrage.
• Nameserver zu wechseln, dauert länger. Die NS-Records der Elternzone für example.com haben ihre eigene TTL, in com 172800 Sekunden (zwei Tage), und die kannst du nicht verkürzen.

DNS-basiertes Failover hängt an diesen Zahlen. Das AWS-Multi-Region-Architekturdiagramm und das Disaster-Recovery-Architekturdiagramm zeigen, wo ein DNS-Record mit Health Check hingehört und warum seine TTL deine Wiederherstellungszeit begrenzt.

Negatives Caching: die NXDOMAIN-Falle

Resolver cachen auch „existiert nicht“. Fehlt ein Name, liefert der autoritative Server NXDOMAIN zusammen mit dem SOA-Record der Zone, und der Resolver cacht diese negative Antwort für den kleineren Wert aus der TTL des SOA-Records und seinem MINIMUM-Feld (RFC 2308).

Der klassische Fehler: Jemand fragt api.example.com ab, bevor der Record existiert, ein Resolver cacht NXDOMAIN für eine Stunde, du legst den Record an, und dieser Resolver behauptet weiter, dass er nicht existiert, bis die Stunde um ist. Prüf die negative TTL mit dig example.com SOA, bevor du einen neuen Hostnamen ankündigst, und leg Records an, bevor irgendjemand sie testet.

Delegation, Glue und Lame Server

Eine Zone existiert im DNS, weil ihre Elternzone an sie delegiert. Die Zone com enthält NS-Records, die angeben, welche Server für example.com autoritativ sind. Liegen diese Nameserver in der Zone, die sie bedienen, etwa ns1.example.com, hält die Elternzone auch ihre Adressen als Glue-Records; sonst könnten Resolver sie nicht finden.

Delegation bricht auf zwei typische Arten. Eine Lame Delegation ist eine Elternzone, die auf einen Server zeigt, der die Zone nicht mehr bedient, oft nach einem Anbieterwechsel, und sie verursacht bei manchen Benutzern Timeouts oder SERVFAIL. Eine Abweichung zwischen den NS-Records bei der Elternzone und in der Zone selbst macht das Verhalten davon abhängig, welchen Satz ein Resolver zufällig gecacht hat.

Transport und Privatsphäre

Der Großteil des DNS-Verkehrs ist UDP auf Port 53. Antworten, die nicht passen, setzen das Truncation-Flag, und der Client versucht es über TCP erneut, also muss TCP-Port 53 ebenfalls offen sein. Seit dem DNS Flag Day 2020 nutzt wichtige DNS-Software standardmäßig eine EDNS-Puffergröße von 1.232 Byte, um IP-Fragmentierung zu vermeiden, was den Rückfall auf TCP bei großen Antworten wie DNSSEC-signierten Records häufiger macht.

Klassisches DNS ist unverschlüsselt. DNS over TLS (Port 853), DNS over HTTPS und DNS over QUIC verschlüsseln den Abschnitt zwischen Stub und rekursivem Resolver; die Abschnitte vom Resolver zu Root-, TLD- und autoritativen Servern sind weiterhin meist Klartext.

DNSSEC löst ein anderes Problem: Authentizität, nicht Privatsphäre. Jede Zone signiert ihre Records, und die Elternzone bürgt für den Schlüssel der Kindzone, bis hinauf zum Root-Schlüssel, dem validierende Resolver vertrauen. Am 11. Oktober 2026 schloss die Root-Zone den Wechsel zu einem neuen Key Signing Key ab, KSK-2024. Ein validierender Resolver, der den neuen Trust Anchor nie übernommen hat, scheitert bei jeder Abfrage mit SERVFAIL.

Wenn Abfragen scheitern

Den autoritativen Server direkt mit dig @ns1.example.net app.example.com zu fragen, zeigt dir die Wahrheit; einen Resolver zu fragen, zeigt dir, was Benutzer sehen.

Das DNS-Auflösungsdiagramm

So liest du es:

• Fang beim Laptop an. Sein Stub-Resolver schickt eine rekursive Abfrage an den Resolver (Schritt 1) und bekommt eine Antwort zurück (Schritt 8).
• Der Resolver läuft die Kette ab. Schritte 2 bis 7 sind iterative Abfragen: Die Root und die com-Server liefern Referrals, und der autoritative Server für example.com liefert den Record.
• TTLs stehen an den Antworten. Der A-Record kommt mit einer TTL von 300 Sekunden zurück; so lange nutzt der Resolver ihn, ohne erneut zu fragen.
• Der Rahmen gruppiert die Hierarchie, die du nicht betreibst, außer dem autoritativen Server, der dir oder deinem DNS-Anbieter gehört.
• Der Markdown-Block listet die Cache-Schichten und die TTLs, die entscheiden, wie schnell eine Änderung bei den Benutzern ankommt.

DNS-Diagramme zeichnen, die echte Fragen beantworten

• Nummeriere die Schritte. Bei DNS-Fragen geht es um Reihenfolge: wer wen fragt und wann stattdessen der Cache antwortet.
• Trenne rekursiven von iterativem Verkehr. Eine Abfrage vom Client, mehrere vom Resolver. Sehen beide gleich aus, versteckt das Diagramm die wichtigste Idee.
• Schreib TTLs an die Antworten. Sie erklären Propagation besser als ein Absatz.
• Zeig Zuständigkeiten. Markiere, welche Server du kontrollierst. Bei einem Incident entscheidet das, wen du anrufst.
• Zeichne die Record-Änderung als eigenes Diagramm. Eine Migrations-Zeitleiste mit gesenkter TTL, Umschaltung und wieder erhöhter TTL ist klarer als Anmerkungen am Abfragediagramm.

Wenn es auf die Reihenfolge der Nachrichten ankommt, funktioniert auch ein Sequenzdiagramm, mit dem Resolver und jedem Server als Lebenslinie. Für die physische Seite, also wo die Resolver in deinem Netz sitzen, siehe den Leitfaden zum Netzwerktopologie-Diagramm.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge einen Gerät-Node aus dem Netzwerk-Pack für den Laptop und einen DNS-Node für den rekursiven Resolver hinzu.
3. Füge einen Rahmen aus dem Basis-Pack hinzu, benannt nach der DNS-Hierarchie, und setz drei weitere DNS-Nodes hinein: Root, com-TLD und den autoritativen Server für example.com.
4. Füge einen Server-Node aus dem Netzwerk-Pack für app.example.com hinzu, den Host, mit dem sich der Browser nach der Abfrage verbindet.
5. Zeichne die Kanten der Reihe nach und nummeriere ihre Beschriftungen: Abfrage und Antwort des Clients, dann je eine Abfrage und eine Antwort zwischen dem Resolver und jedem Server. Schreib die TTL an die letzte Antwort.
6. Füge einen Markdown-Block aus dem Basis-Pack mit den Cache-Schichten und den TTL-Regeln hinzu.

Das Beispiel nutzt 8 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Wie lange dauert die DNS-Propagation? Bis zur TTL des alten Records, für jeden Resolver, der ihn gecacht hat. Nichts wird gepusht; Caches laufen ab. Nameserver-Wechsel dauern länger, weil die NS-Records der Elternzone ihre eigene TTL haben, in com zwei Tage.

Was ist der Unterschied zwischen einem rekursiven und einem autoritativen DNS-Server? Ein rekursiver Resolver findet Antworten im Auftrag von Clients und cacht sie. Ein autoritativer Server hält die Records einer Zone und antwortet nur für diese Zone.

Warum sehe ich nach einer Änderung immer noch die alte IP-Adresse? Ein Cache zwischen dir und dem autoritativen Server hält noch den alten Record: dein Browser, dein Betriebssystem oder dein Resolver. Frag den autoritativen Server direkt, um die Änderung zu bestätigen, und warte dann, bis die TTL abläuft.

Ist eine sehr niedrige TTL ein Problem? Sie kostet mehr Abfragen bei deinem DNS-Anbieter und mehr volle Abfragen für Benutzer, was bei Cache-Misses Latenz hinzufügt. Nutze niedrige TTLs für Records, bei denen du eventuell ein Failover brauchst, und längere für stabile Records.

Ist DNS-Verkehr verschlüsselt? Standardmäßig nicht. DNS over TLS, HTTPS oder QUIC verschlüsselt den Abschnitt zwischen deinem Gerät und dem Resolver. DNSSEC ergänzt Signaturen, die belegen, dass Records echt sind, verschlüsselt aber nichts.

Kostenlos starten — ein Seat, keine Kreditkarte.