DNS
Lektion 2 von 6
So funktioniert eine DNS-Auflösung
Verfolge eine typische Anfrage über Resolver, Cache, Root-, TLD- und autoritative Server.
Lernziele
Nach Abschluss dieser Lektion kannst du:
- die Rolle des Clients beziehungsweise Stub-Resolvers erklären
- die Rolle eines rekursiven DNS-Resolvers erklären
- rekursive und iterative Auflösung konzeptionell unterscheiden
- Root-, TLD- und autoritative Serverrollen nennen
- einen typischen ungespeicherten Auflösungsablauf beschreiben
- DNS-Caching und TTL erklären
- erkennen, dass Cache-Antworten Hierarchieabfragen vermeiden können
- UDP und TCP auf Port 53 als klassische DNS-Transporte einordnen
- vermeiden, normale Clientanfragen als direkte Root-Anfragen darzustellen
Vom Programm zum Resolver
Eine Anwendung bittet gewöhnlich den lokalen Resolver des Betriebssystems – oft Stub-Resolver genannt – um die Auflösung eines Namens. Der Host kennt einen oder mehrere konfigurierte DNS-Resolver und sendet die Anfrage typischerweise dorthin. Normale Anwendungen fragen nicht für jede Webseite selbst Root-Server ab.
Der rekursive Resolver
Der rekursive Resolver soll dem Client eine abschließende Antwort liefern. Er kann sie aus seinem Cache beantworten oder weitere DNS-Anfragen durchführen. Solche Resolver gibt es in Unternehmen, beim Internetanbieter, im Heimnetz oder als öffentliche Dienste; hier wird kein Anbieter empfohlen.
Client → Resolver ist konzeptionell eine Anfrage nach dem Endergebnis. Der Resolver arbeitet Richtung DNS-Hierarchie typischerweise iterativ: Eine Zwischenstelle kann statt der finalen Antwort sinngemäß sagen „Frage als Nächstes diese Nameserver“.
Root → TLD → autoritativ
Für www.example.com verweist ein Root-Server auf die Nameserver der Top-Level-Domain .com. Ein TLD-Server verweist auf autoritative Nameserver für example.com. Der zuständige autoritative Server liefert den relevanten Record oder eine passende autoritative Antwort.
Root-Server speichern nicht die IP jeder Webseite, und TLD-Server müssen nicht die finalen A-/AAAA-Records jedes Hosts enthalten.
Client-Anfrage
www.example.comRekursiver Resolver
1. Cache prüfen
2. bei Bedarf iterativ fragen
1
Root-Server
Verweis zu .com
2
.com-TLD-Server
Verweis zu example.com
3
Autoritativer Server
Antwort für www.example.com
Zehn Schritte als ungespeichertes Lehrbeispiel
- Client fragt den konfigurierten rekursiven Resolver.
- Resolver prüft den Cache.
- Falls nötig fragt er einen Root-Server.
- Root verweist auf .com-Server.
- Resolver fragt einen .com-TLD-Server.
- TLD verweist auf autoritative Server für example.com.
- Resolver fragt einen autoritativen Server.
- Resolver erhält die relevante Antwort.
- Resolver speichert sie gemäß TTL zwischen.
- Resolver gibt die Antwort an den Client zurück.
Cache, TTL und DNS-Änderungen
Temporäres Caching macht Folgeantworten schneller, senkt DNS-Verkehr und entlastet autoritative Infrastruktur. Ein Cache ist nicht dauerhaft und nicht jede Information bleibt gleich lang gespeichert.
TTL bedeutet Time To Live. Die TTL eines Resource Records beziehungsweise RRsets gibt an, wie lange ein Caching-Resolver die Information normalerweise behalten darf, bevor sie abläuft und erneut abgefragt werden muss. Sie löscht nicht den autoritativen Record.
Nach einer Änderung können alte Cache-Daten bis zum Ablauf der relevanten TTL sichtbar bleiben. Es gibt keine universelle Regel „DNS dauert immer 24 oder 48 Stunden“; Cache, TTL und Betriebsumgebung bestimmen das Verhalten mit.
Klassisches DNS: UDP und TCP Port 53
UDP 53TCP 53UDP ist für viele gewöhnliche Anfragen verbreitet. TCP gehört ebenfalls zu DNS und wird unter anderem bei größeren Antworten, Truncation/Fallback und Zonentransfers verwendet. TCP 53 ist daher nicht ausschließlich für Zonentransfers reserviert. Moderne verschlüsselte Transporte wie DoT und DoH existieren, sind aber nicht Kern dieser Lektion.
Reihenfolge prüfen
Der vereinfachte ungespeicherte Ablauf
Ordne den Lehrbuchablauf. In der Praxis können bereits gespeicherte Antworten oder Delegationen Schritte ersparen.
Typische Fehlvorstellungen
- Falsch: „Mein PC fragt bei jeder Webseite zuerst einen Root-Server.“
- Korrektur: Üblicherweise fragt der Client seinen konfigurierten rekursiven Resolver.
- Falsch: „Root-Server kennen die IP-Adresse jeder Webseite.“
- Korrektur: Sie liefern hauptsächlich Verweise zur passenden TLD-Infrastruktur.
- Falsch: „DNS benutzt immer UDP.“
- Korrektur: Klassisches DNS nutzt UDP und TCP auf Port 53.
- Falsch: „TTL sagt, wann ein DNS-Eintrag gelöscht wird.“
- Korrektur: TTL steuert die Cache-Lebensdauer, nicht die Existenz des autoritativen Eintrags.
- Falsch: „DNS-Änderungen brauchen immer 24 oder 48 Stunden.“
- Korrektur: Es gibt keine feste Universalzeit; relevante Cache- und TTL-Werte wirken sich aus.
Antwort und befragten Resolver beobachten
nslookup www.example.comAchte auf den verwendeten DNS-Server und die zurückgegebenen Adressinformationen. Die Ausgabe beweist allein nicht zuverlässig, ob ein Cache getroffen wurde.
nslookup -type=ns example.comZeigt konzeptionell NS-Informationen; genaue Ausgabe kann je nach Betriebssystem variieren. dig ist optional, falls bereits vorhanden.
Nächste Lektion
DNS-Records verstehen
Als Nächstes lernst du, welche Informationen A, AAAA, CNAME, MX, NS, PTR, TXT und SRV ausdrücken.
Dein Lernstand
Lektion in Bearbeitung
Das Öffnen startet die Lektion. Als erledigt zählt sie erst nach deiner ausdrücklichen Bestätigung.