Hunderte von Abfragen für eine Domain: Die verborgene Arbeit hinter einer Kaltstart-DNS-Auflösung

Jedes Mal, wenn Sie eine Webadresse eingeben, übersetzt ein stiller Hintergrundprozess namens DNS-Auflösung diesen Namen in eine maschinenlesbare IP-Adresse. Normalerweise ist ein Großteil dieser Arbeit unsichtbar, weil Ihr lokaler Resolver einen temporären Speicher, einen Cache, für kürzlich durchgeführte Lookups bereithält. Aber was passiert, wenn dieser Cache leer ist? Dieser sogenannte Kaltstart-Zustand zwingt den Resolver, die gesamte Informationskette von Grund auf neu zu entdecken, und wie neue Forschungsergebnisse, die beim RIPE-92-Treffen von Ondřej Surý vom Internet Systems Consortium vorgestellt wurden, zeigen, können die Kosten dramatisch variieren, von nur wenigen Abfragen bis zu mehreren hundert.

Um das Ausmaß zu verstehen, betrachten Sie ein einfaches Beispiel: die Domain www.potaroo.net. Mit einem BIND-Rekursiv-Resolver Version 9.20.23 ohne zwischengespeicherte Daten dauert die Auflösung nur vier Abfragen. Der Resolver beginnt damit, einen Root-Server (dessen Adressen vorkonfiguriert sind) nach den Nameservern der Root-Zone zu fragen, eine Aktualisierung, die auch aktuelle IP-Adressen für diese Root-Server zurückgibt. Als Nächstes fragt er einen dieser Server nach den Nameservern der Top-Level-Domain .net. Eine dritte Abfrage geht an einen .net-Server, um die Nameserver von potaroo.net zu erfahren, und die letzte Abfrage fordert die IP-Adresse von www.potaroo.net selbst an. Da jedes Label im Namen einem Delegationspunkt entspricht, einer Übergabe von einer Zone zur nächsten, sind vier Abfragen das theoretische Minimum. Der Resolver verwendet eine Technik namens Query-Name-Minimierung, die nur nach der nächsten benötigten Information fragt, aber selbst ein direkterer Ansatz würde die gleiche Anzahl von Schritten ergeben.

Wechseln Sie zu einem komplexeren Namen wie teams.microsoft.com, und das Bild ändert sich drastisch. Surýs Tests ergaben, dass ein BIND-9.16-Resolver 247 Abfragen benötigte, um dieselbe Kaltstart-Auflösung durchzuführen. Version 9.20 reduzierte dies auf 94 Abfragen, und Version 9.21 brachte es weiter auf nur 29 herunter. Die Ursache liegt in einer Kette von vier CNAME-Einträgen, Aliase, die dem Resolver sagen: „Dieser Name zeigt auf einen anderen Namen, schauen Sie stattdessen dort nach.“ Jeder CNAME startet den Auflösungsprozess effektiv neu, und da die Ziele über verschiedene Top-Level-Domains verteilt sind (office.com, dann eine .net-Domain), muss der Resolver den DNS-Baum wiederholt von der Wurzel aus neu durchlaufen. Lange CNAME-Ketten, insbesondere solche, die zwischen unabhängigen Zonen springen, vervielfachen die Arbeit.

Ein weiterer Faktor ist die Behandlung von Nameserver-Adressen. Wenn eine übergeordnete Zone eine Subdomain delegiert, stellt sie die Namen der autoritativen Server bereit, aber nicht direkt deren IP-Adressen. Um ein Huhn-und-Ei-Problem zu vermeiden, fügt die übergeordnete Zone oft Glue-Records hinzu: IP-Adressen, die im Additional-Abschnitt der Antwort geliefert werden. Glue ist obligatorisch, wenn der Nameserver-Name innerhalb der delegierten Zone liegt (in-baliwick), da die Auflösung sonst in einer Sackgasse enden würde. Für Nameserver, die Geschwister sind, denselben übergeordneten Domain-Namen teilen, aber außerhalb der delegierten Zone liegen, ist die Bereitstellung von Glue optional. Historisch vertrauten Resolver diesem Geschwister-Glue, aber eine Cache-Poisoning-Schwachstelle in BIND (CVE-2025-40778) führte ab Version 9.20.14 zu Änderungen: Geschwister-Glue wird jetzt ignoriert, was den Resolver zwingt, diese IP-Adressen unabhängig nachzuschlagen. Dies fügt zusätzliche Abfragen hinzu, schließt aber eine Sicherheitslücke.

Über Glue hinaus stehen Resolver-Designer vor einer strategischen Wahl. Ein Ansatz besteht darin, jeden Nameserver-Namen vollständig aufzulösen und den Cache mit allen IP-Adressen für sowohl IPv4 als auch IPv6 zu füllen. Dies schafft Widerstandsfähigkeit, wenn ein Server ausfällt, sind Alternativen sofort verfügbar. Mit langen CNAME-Ketten und vielen Out-of-Baliwick-Nameservern explodiert jedoch die Anzahl der Abfragen. Der gegenteilige Ansatz löst nur einen Nameserver oder sogar nur eine Adressfamilie auf und greift nur bei Fehlern auf Alternativen zurück. Dies beschleunigt die Kaltstart-Leistung und reduziert die Gesamtabfragelast, birgt jedoch das Risiko von Zeitüberschreitungen, wenn der gewählte Server langsam oder nicht erreichbar ist.

Eine verwandte Entscheidung ist, ob man den Delegationsdaten der übergeordneten Zone vertrauen oder sie durch Abfragen der untergeordneten Zone selbst überprüfen soll. BIND 9.21.20 wechselte zu einem übergeordneten-zentrierten Modell, das sich auf die Nameserver-Liste der übergeordneten Zone verlässt, ohne eine zusätzliche Abfrage an die untergeordnete Zone durchzuführen. Die Begründung ist pragmatisch: Wenn die Daten der übergeordneten Zone manipuliert wurden, ist der Resolver bereits fehlgeleitet, bevor eine untergeordnete Abfrage helfen kann. Für eine stärkere Absicherung bietet DNSSEC, ein System, das DNS-Einträge kryptografisch signiert, eine robustere Verteidigung, obwohl es seinen eigenen Overhead hinzufügt. Im potaroo.net-Beispiel erforderte die DNSSEC-Validierung zwei zusätzliche Abfragen für DNSKEY-Einträge; bei CNAME-Ketten skaliert die zusätzliche Arbeit mit der Anzahl der Labels jedes Alias.

Was können Zonenbetreiber tun, um die Last zu verringern? Surýs Präsentation bot klare Anleitungen. Verwenden Sie wann immer möglich Nameserver-Namen, die innerhalb der Domain liegen, die sie bedienen (in-baliwick), sodass Glue-Records garantiert sind und die Auflösung effizient ist. Google.com ist ein Lehrbuchfall: Alle seine Nameserver enden auf google.com. Vermeiden Sie es, Nameserver-Namen über viele Top-Level-Domains zu verteilen, eine Praxis, die Resolver zwingt, IP-Adressen durch mehrere Zonen zu jagen. Eine einfache DNS-Infrastruktur hilft nicht nur der Leistung, sondern entfernt auch unnötige Fehlerquellen.

Für normale Benutzer ist die Komplexität der Kaltstart-Auflösung weitgehend unsichtbar, da Caches sie verbergen. Dennoch sind die Designprinzipien wichtig: Ein Resolver, der zu aggressiv ist, kann Ressourcen verschwenden, während einer, der Abstriche macht, zu langsamen oder fehlgeschlagenen Lookups führen kann. Die Verwendung eines DNS-Dienstes, der intelligentes Caching mit starken Sicherheitspraktiken kombiniert, hilft sowohl Geschwindigkeit als auch Sicherheit. Ein datenschutzorientierter, verschlüsselter DNS-Resolver wie AEU DNS verschlüsselt Ihre Abfragen Ende-zu-Ende und verhindert, dass Lauscher sehen, welche Websites Sie besuchen, während seine No-Log-Richtlinie sicherstellt, dass selbst der Resolver-Betreiber Ihre Aktivitäten nicht aufzeichnet. Indem Sie einen Resolver wählen, der moderne Standards einhält, Query-Minimierung, sorgfältige Glue-Behandlung und DNSSEC-Validierung, erhalten Sie Schutz, ohne auf Leistung zu verzichten.