DNS-Auflösung von Anfang bis Ende

Jedes Mal, wenn Sie eine Domain in einen Browser eingeben, läuft eine Kette von Abfragen ab, bevor auch nur ein Paket die Site erreicht, die Sie wollen. Der größte Teil dieser Kette ist unsichtbar, und die meisten Erklärungen dazu enden bei "es ist wie ein Telefonbuch." Hier ist, was tatsächlich geschieht, Schritt für Schritt, inklusive der Teile, die Menschen üblicherweise überspringen.

Der Stub-Resolver ist nicht intelligent

Ihr Betriebssystem führt DNS-Auflösung nicht selbst durch. Es läuft einen Stub-Resolver, ein dünnes Stück Code, das Ihre Abfrage einfach an jeden DNS-Server weiterleitet, der in /etc/resolv.conf unter Linux oder in Ihren Netzwerkadapter-Einstellungen unter Windows konfiguriert ist. Überprüfen Sie Ihre mit:

cat /etc/resolv.conf

Diese Datei zeigt üblicherweise auf Ihren Router (wie 192.168.1.1), den Resolver Ihres ISP, oder einen öffentlichen wie 1.1.1.1 oder 8.8.8.8. Der Stub-Resolver hat über das hinaus, was das Betriebssystem oder ein lokaler Daemon wie systemd-resolved bereitstellt, keine eigene Cache-Logik.

Der rekursive Resolver leistet die echte Arbeit

Sobald Ihre Abfrage einen rekursiven Resolver erreicht, übernimmt dieser Server die Aufgabe, die Antwort zu finden, selbst wenn er mehrere andere Server danach fragen muss. Wenn die Antwort bereits aus einer früheren Abfrage zwischengespeichert ist, erhalten Sie sie sofort zurück. Überprüfen Sie die TTL mit:

dig example.com

Schauen Sie sich den ANSWER SECTION an — die Zahl vor dem Recordtyp (wie 300 vor A) ist die TTL in Sekunden. Das ist die Zeit, die Resolver den Record zwischenspeichern dürfen, bevor sie erneut abfragen.

Wenn nichts zwischengespeichert ist, beginnt der rekursive Resolver einen Durchgang durch die DNS-Hierarchie von der Root.

Root-, TLD- und autoritative Server

Es gibt 13 Root-Server-Adressen (a.root-servers.net bis m.root-servers.net), jede wird von vielen physischen Maschinen durch Anycast-Routing unterstützt. Der Root-Server weiß nicht, wo example.com sich befindet, aber er weiß, welche Server .com handhaben, also gibt er eine Weitergabe zurück.

Der Resolver fragt dann einen .com TLD-Server, der wiederum nicht die endgültige Antwort kennt, aber weiß, welche Nameserver für example.com speziell autoritativ sind. Sie können diese Delegierung selbst sehen:

dig +trace example.com

Dieser Befehl zeigt jeden Sprung: Root, dann TLD, dann die autoritativen Nameserver für die Domain, endend mit dem tatsächlichen A- oder AAAA-Record. Es ist der beste einzelne Befehl zum visuellen Verstehen von DNS anstatt theoretisch.

Der autoritative Nameserver ist die letzte Station. Es ist der Server, den der Domain-Besitzer tatsächlich konfiguriert hat, oft durch das DNS-Panel eines Registrars oder einen Service wie Route 53 oder Cloudflare DNS. Das ist der einzige Server in der ganzen Kette, der die echte, kanonische Antwort hat anstatt einer zwischengespeicherten Kopie oder einer Weitergabe.

Recordtypen, denen Sie tatsächlich begegnen

Ein A-Record bildet einen Namen auf eine IPv4-Adresse ab, AAAA macht das Gleiche für IPv6. CNAME zeigt einen Namen auf einen anderen Namen anstatt auf eine IP, was der Grund ist, wie CDNs wie Cloudflare oder Fastly Traffic routen, ohne rohe IPs offenzulegen. MX-Records handhaben Mail-Routing, und TXT-Records tragen beliebigen Text, am häufigsten jetzt für SPF, DKIM und Domain-Verifizierungszeichenfolgen verwendet. NS-Records teilen der Welt mit, welche Server für eine Zone autoritativ sind, und das ist der Recordtyp, der Delegierung überhaupt erst möglich macht.

Wo Caching tatsächlich lebt

Caching findet auf mehreren Ebenen gleichzeitig statt: der Browser selbst (Chrome hat seinen eigenen DNS-Cache sichtbar unter chrome://net-internals/#dns), der Betriebssystem-Resolver-Cache, der lokale Router und der rekursive Resolver stromaufwärts. Das ist der Grund, warum eine DNS-Änderung auf einem Gerät sofort zu funktionieren scheint und auf einem anderen Stunden dauert – Sie treffen nicht denselben Cache.

Wenn Sie den TTL eines Records vor einer geplanten Migration senken, beschleunigen Sie nichts sofort. Sie verkleinern einfach das Fenster, in dem veraltete Daten bestehen bleiben können, sobald die Änderung tatsächlich stattfindet. Tun Sie das mindestens einen TTL-Zyklus im Voraus, nicht fünf Minuten vor dem Cutover.

Warum das für die Fehlerbehebung wichtig ist

Wenn eine Site unerreichbar ist, sagt Ihnen dig +trace genau, welche Ebene kaputt ist: ein Root-/TLD-Problem sieht völlig anders aus als ein falsch konfigurierter autoritativer Server oder ein veralteter Cache auf Ihrer eigenen Maschine. Der Vergleich von dig example.com gegen einen bekannt guten Resolver wie dig example.com @1.1.1.1 isoliert, ob das Problem Ihr lokaler Resolver oder die tatsächliche DNS-Einrichtung der Domain ist.

DNS sieht von außen einfach aus, weil es normalerweise in unter 100ms aufgelöst wird und niemand darüber nachdenkt. Darunter ist es ein verteiltes, zwischengespeichertes, hierarchisches Abfragesystem, das seit den 1980ern praktisch unverändert in seiner Struktur läuft, was ein ziemlich gutes Argument dafür ist, wie gut das ursprüngliche Design standgehalten hat.

Wenn Sie weiter damit gehen wollen, hat Korra Studio verwandte Segmente auf DEFENSE_GRID, die DNS-Sicherheitserweiterungen, DNS-Tunneling als Exfiltrationstechnik und das Bauen Ihres eigenen Resolvers von Grund auf in Python abdecken.