Die Reise einer DNS-Anfrage

Modul 1: Was ist DNS? · Lesezeit: 8 Minuten

Lernziel: Nach dieser Lektion können Sie Schritt für Schritt erklären, wie ein Resolver eine Antwort findet, und wo unterwegs Antworten gespeichert werden.

Kernbegriffe: Resolver (rekursiv), Rootserver, TLD-Server, autoritativer Nameserver, Verweis (Delegation), Cache

Zwei Arten von DNS-Servern

In Lektion 1.1 haben Sie gesehen, dass DNS verteilt ist: Niemand weiss alles. Wie kommt Ihr Browser dann trotzdem an die Adresse von www.example.com? Dafür arbeiten zwei Arten von Servern zusammen:

• Autoritative Nameserver (englisch authoritative) kennen die Antwort für ihren eigenen Bereich. Die Nameserver von example.com kennen die Einträge von example.com. Sie suchen nichts für andere nach.
• Resolver (auch rekursive Resolver genannt) suchen die Antwort für Sie. Sie fragen so lange nach, bis sie sie haben. Ihr Internetanbieter hat einen Resolver, und es gibt öffentliche Resolver wie die von Quad9, Cloudflare oder Google.

Ihr Computer selbst sucht fast nichts nach. Er hat einen kleinen Stub-Resolver, der die Anfrage an den Resolver Ihres Netzwerks weitergibt und die Antwort zurückbekommt.

Die Reise, Schritt für Schritt

Angenommen, der Resolver hat noch nichts gespeichert, und Sie fragen nach dem A-Record von www.example.com.

1. Ihr Computer fragt den Resolver: „Was ist der A-Record von www.example.com?“
2. Der Resolver fragt einen Rootserver. Jeder Resolver hat eine Liste mit den Adressen der Rootserver eingebaut. Der Rootserver weiss nichts über example.com, aber wohl, wer .com verwaltet. Er antwortet mit einem Verweis: „Dafür müssen Sie zu den Nameservern von com: a.gtld-servers.net, b.gtld-servers.net, und so weiter.“
3. Der Resolver fragt einen Nameserver von .com. Der kennt auch nicht die IP-Adresse von www.example.com, aber wohl, welche Nameserver example.com hat. Wieder ein Verweis: „Fragen Sie ns1.hosting.example oder ns2.hosting.example.“
4. Der Resolver fragt einen Nameserver von example.com. Der ist für diese Domain autoritativ und gibt die Antwort: „www.example.com hat den A-Record 192.0.2.10.“
5. Der Resolver gibt die Antwort an Ihren Computer weiter. Ihr Browser baut eine Verbindung zu 192.0.2.10 auf.

Ein Verweis von einer höheren Ebene auf die Nameserver einer niedrigeren Ebene heisst Delegation. Die Root delegiert .com an Verisign, .com delegiert example.com an die Nameserver, die der Domaininhaber angegeben hat. Bei einer .nl-Domain läuft es genauso ab, nur verweist die Root dann auf die Nameserver von .nl (SIDN, die Registry von .nl in den Niederlanden, zum Beispiel ns1.dns.nl). Das sehen Sie selbst in der Aufgabe am Ende dieser Lektion. Deshalb ist es so wichtig, dass die Nameserver bei der Registry stimmen (Lektion 2.1).

Der Cache: nicht jedes Mal die ganze Reise

Würde jeder Resolver bei jeder Anfrage wieder bei der Root beginnen, bekäme die Root eine unvorstellbare Menge an Anfragen. Das passiert nicht, denn der Resolver merkt sich die Antworten eine Weile. Dieses Gedächtnis heisst Cache.

Wie lange eine Antwort gespeichert werden darf, steht in der Antwort selbst: die TTL (time to live), in Sekunden. Eine TTL von 3600 bedeutet: Diese Antwort darf eine Stunde lang gespeichert werden. Auch die Verweise werden gespeichert. Ein Resolver, der gerade erfahren hat, welche Nameserver .com hat, muss das beim nächsten Mal nicht erneut bei der Root erfragen.

Fragt eine Minute später jemand anderes beim selben Anbieter nach www.example.com, antwortet der Resolver sofort aus seinem Cache. Keine Reise, keine Wartezeit.

Caches gibt es an mehreren Stellen:

• im Resolver Ihres Anbieters oder dem öffentlichen Resolver, den Sie nutzen;
• in Ihrem Betriebssystem (Windows, macOS, Ihr Telefon);
• in Ihrem Browser;
• manchmal in Ihrem Router.

Das ist schnell und effizient, hat aber eine Folge, die Ihnen später oft begegnet: Ändern Sie einen Eintrag, geben Caches noch die alte Antwort, bis ihre TTL abgelaufen ist. Deshalb sieht der eine eine Änderung bereits und der andere noch nicht. Modul 6 geht darauf ausführlich ein.

Die Rootserver

Es gibt 13 Namen für die Rootserver: a.root-servers.net bis m.root-servers.net. Sie werden von zwölf verschiedenen Organisationen verwaltet. Hinter jedem Namen stehen weltweit viele Server, an hunderten Standorten, die sich dieselbe Adresse teilen (das nennt man Anycast). Ihr Resolver landet automatisch bei einem in der Nähe. Auch die TLD-Nameserver, wie die von .com und .nl, funktionieren so. Dadurch ist DNS schnell und bleibt funktionsfähig, auch wenn irgendwo ein Server ausfällt.

Wo es schiefgehen kann

Wenn Sie die Reise kennen, können Sie Probleme besser einordnen:

• Die Delegation stimmt nicht. Bei der Registry stehen Nameserver, die die Domain nicht (mehr) kennen. Der Resolver kommt dann bei Schritt 4 nicht weiter. Die Antwort ist ein Fehler, oder es kommt überhaupt keine Antwort.
• Der autoritative Server hat eine andere Antwort als erwartet. Sie haben den Eintrag dann an einer anderen Stelle geändert als dort, wo die Nameserver stehen (Lektion 2.1).
• Der Cache hat noch die alte Antwort. Dann ist nichts kaputt. Sie müssen warten, bis die TTL abgelaufen ist, oder Ihren eigenen Cache leeren.
• DNSSEC stimmt nicht. Ein validierender Resolver prüft unterwegs Signaturen. Stimmt die Kette nicht, verweigert er die Antwort (Lektion 8.1).

Mit dem Hilfsmittel dig +trace können Sie die Reise selbst nachvollziehen, von der Root bis zum autoritativen Server. Das lernen Sie in Lektion 8.2. Online-Tools können das ebenfalls.

Zusammenfassung

• Autoritative Nameserver kennen die Antwort für ihre eigene Domain; Resolver suchen die Antwort für Sie.
• Ein Resolver beginnt bei der Root, erhält einen Verweis auf die TLD, dann auf die Nameserver der Domain, und erhält dort die Antwort.
• So ein Verweis heisst Delegation.
• Antworten werden in Caches gespeichert, so lange wie die TTL vorgibt; dadurch sind Änderungen nicht überall sofort sichtbar.
• Es gibt 13 Rootserver-Namen, aber dank Anycast stehen dahinter weltweit viele Server.

Quiz

Aufgabe

Aufgabe Z1.4: Die Reise verfolgen. Verfolgen Sie die Reise für www.sidn.nl mit dig +trace www.sidn.nl oder einem Online-Tool, das eine Trace anzeigt. Tragen Sie ein: (1) einen Nameserver von nl., dem Sie unterwegs begegnen, (2) einen autoritativen Nameserver von sidn.nl.

Weiterführende Informationen

Diese Artikel beschreiben die Situation bei WebOké. Bei anderen Anbietern funktioniert es ähnlich.

• DirectAdmin Anleitung 5.11: Wann wirkt eine Änderung? Wartezeit und TTL
• Wie lange dauert eine Nameserver- oder DNS-Änderung, und was ist, wenn Sie sie nicht sehen?