DNS-Abfragekomplexität und Post-Quantum-DNSSEC unter der Lupe

Auf der 126. Sitzung der Internet Engineering Task Force (IETF) in Wien, Österreich, Ende Juli 2026 zeigten Diskussionen über das Domain Name System (DNS) sowohl die verborgene Komplexität alltäglicher DNS-Abfragen als auch Experimente, die darauf abzielen, die DNS-Sicherheit für Quantencomputer bereit zu machen. Geoff Huston berichtete im APNIC-Blog und fasste zwei zentrale Sitzungen zusammen: einen tiefen Einblick in das Abfrageverhalten rekursiver Resolver von Ondřej Surý vom Internet Systems Consortium (ISC) und Post-Quantum-DNSSEC-Ideen, die von Johan Stenstam vorgestellt wurden.

Ein rekursiver Resolver ist der Teil des DNS, der die Arbeit übernimmt, wenn Ihr Computer nach einer Website fragt: Er beginnt ohne jegliches Wissen über den Namen und fragt wiederholt andere DNS-Server, bis er die Antwort findet. Surý untersuchte, was passiert, wenn ein solcher Resolver mit einem völlig leeren Cache startet, was als kalter Cache bezeichnet wird. Sein verblüffendes Beispiel war ein IPv6-Rückwärtsname, bei dem die Abfrage einen Pointer-Eintrag (PTR) anforderte. Die Auflösung dieses einzelnen Namens erforderte bei BIND 2.18, einer weit verbreiteten DNS-Server-Software, erstaunliche 329 Abfragen. Nicht jeder Name ist so komplex, aber ohne vorgewärmten Cache wird die innere Navigation des Resolvers durch die DNS-Hierarchie sichtbar.

Mehrere Faktoren treiben die Anzahl der Abfragen in die Höhe. Ein DNS-Name kann viele Delegierungspunkte haben, also die Grenzen, an denen die Zuständigkeit für einen Teil des Namens an andere Server übergeben wird. Oft befinden sich diese autoritativen Server in einem anderen Teil des DNS-Baums, sogenannte Out-of-Bailiwick-Nameserver, was zusätzliche Nachschlagevorgänge erzwingt. Kanonische Namen (CNAMEs), die als Aliasse fungieren und einen Namen auf einen anderen verweisen, können völlig neue Auflösungsketten auslösen. Die DNSSEC-Validierung, die digitale Signaturen von DNS-Daten überprüft, fügt weitere Abfragen nach Delegation-Signer-Einträgen (DS) entlang der Kette hinzu. Selbst ein einfacher Name wie www.example.com zeigt dieses Geflecht impliziten Vertrauens: Ein kalter Resolver benötigt eine Priming-Abfrage für die Root-Zone, dann eine Abfrage an einen Root-Server nach einem .com-Server, dann eine Abfrage an einen .com-Server nach einem example.com-Server und schließlich die abschließende Abfrage. Das scheinen vier Vertrauenspunkte zu sein, aber weil es dreizehn benannte Root-Server und dreizehn .com-Server gibt und weil die Root-Server-Namen selbst in der .net-Zone liegen, umfasst das vollständige Vertrauensbild auch alle diese Server. Das Tool Transitive Trust Checker veranschaulicht dieses Netz von Abhängigkeiten.

Glue-Records fügen eine weitere Ebene hinzu. Wenn ein Resolver die IP-Adresse eines Nameservers benötigt, der sich innerhalb derselben Domain befindet, die er aufzulösen versucht, kann die Antwort diese Adressen in einem zusätzlichen Abschnitt enthalten. Bei zirkulärer Abhängigkeit ist der Resolver gezwungen, ihnen zu vertrauen. Historisch wurden Glue-Records großzügig eingefügt, aber das wurde für DNS-Cache-Poisoning missbraucht, bei dem Angreifer falsche Glue-Records einschleusen, um Benutzer auf bösartige Websites umzuleiten. Moderne Resolver sollen eine strikte In-Bailiwick-Bedingung durchsetzen: Sie vertrauen einem Glue-Record nur, wenn der Name des Nameservers innerhalb der Zone liegt, die aufgelöst wird. CNAME-Ketten sind besonders häufig in Content-Distribution-Netzwerken. Zum Beispiel löst die Auflösung von teams.microsoft.com zunächst eine Auflösung in .com aus, die dann zu einer Kette von CNAMEs führt, die in der .net-Domain endet und eine völlig neue Abfolge von Abfragen erzeugt. Microsoft.com selbst verwendet Nameserver in azure-dns.org, azure-dns.info, azure-dns.com und azure-dns.net, alle außerhalb seiner eigenen Domain, was die Komplexität erhöht.

Resolver-Entwickler stehen vor einer schwierigen Wahl. Der Ansatz „alles auflösen“ löst die Namen aller Out-of-Bailiwick-Nameserver auf jeder Delegierungsebene auf, was gründlich ist, aber von böswilligen Akteuren ausgenutzt werden kann, die Namen konstruieren, die schwere Arbeitslasten auslösen. Der Ansatz „selektive Auflösung“ wählt auf jeder Ebene einen einzigen Nameserver aus, was effizient ist, wenn dieser Server antwortet; fällt er jedoch aus, kann der Wechsel zu einem anderen Server eine vollständige erneute Auflösung erfordern. Surýs Empfehlungen für Domain-Betreiber und Resolver-Implementierer sind praktisch: Bevorzugen Sie nach Möglichkeit In-Domain-Nameserver, beschränken Sie verwaltete DNS-Anbieter auf höchstens zwei, vermeiden Sie lange CNAME-Ketten, nutzen Sie aggressives NSEC-Caching (eine DNSSEC-Funktion, die Nichtexistenz effizient beweisen kann) und setzen Sie längere Time-to-Live-Werte (TTL) für DNS-Einträge, damit Resolver Antworten länger aus dem Cache liefern können. Er wies auch darauf hin, dass das Vorab-Auflösen aller Nameserver-Namen vor der Verarbeitung Arbeit mit geringem Nutzen erzeugt.

Das zweite große Thema war Post-Quantum-DNSSEC. Quantencomputer, die die heutige Verschlüsselung brechen können, sind noch spekulativ; die derzeitige Meilensteinleistung ist die Faktorisierung der Zahl 35. Doch die Geschichte zeigt schnelle Innovation, wie der Germanium-Transistor von 1947, der zu heutigen Chips mit Billionen Gattern führte. Huston argumentierte, dass die wirksamste Gegenmaßnahme heute nicht der Einsatz von Post-Quantum-Kryptographie (PQC) ist, sondern die Verkürzung der Lebensdauer von DNSSEC-Schlüsseln, denn sobald ein Schlüssel gewechselt wird, ist das Brechen eines alten Schlüssels nutzlos. Die ineinandergreifende Schlüsselstruktur von DNSSEC bedeutet, dass ein Schlüssel nur nützlich ist, bis er ersetzt wird. Die eigentliche Sorge ist, ob ein zukünftiger Quantencomputer einen Schlüssel innerhalb seiner Nutzungsdauer brechen könnte.

Wenn Post-Quantum-Algorithmen schließlich benötigt werden, bringen sie praktische Herausforderungen mit sich. PQC-Signaturen sind viel größer und könnten DNS vom leichtgewichtigen User Datagram Protocol (UDP) zum schwereren Transport Control Protocol (TCP) zwingen oder eine Fragmentierung auf Anwendungsebene erfordern. Huston wies darauf hin, dass es zwar technisch machbar wäre, den gesamten DNS-Verkehr riesige Nutzlasten tragen zu lassen, dies aber wirtschaftlich unerschwinglich wäre, weil DNS derzeit aufgrund kleiner Nachrichtengrößen unglaublich günstig ist.

Johan Stenstam stellte drei Experimente vor, um Post-Quantum-DNSSEC zu erproben, ohne das System zu beschädigen. Sein erstes Experiment nutzte die Tatsache, dass Shors Algorithmus, der RSA-Verschlüsselung auf einem Quantencomputer brechen würde, für einen 2.048-Bit-Schlüssel Stunden bis Tage benötigt. Er verwendete DSYNC, um einen DNSSEC Key-Signing Key (KSK) drei Monate lang alle zehn Minuten zu wechseln, wobei nur der quantenopake DS-Hash des Schlüssels vorab veröffentlicht wurde. Bis ein Angreifer den KSK brechen könnte, war er bereits gewechselt und nutzlos. Das zweite Experiment verwendete ein geteiltes Profil: einen großen Post-Quantum-KSK, um den DNSKEY-Eintrag am Zonenapex zu signieren, während ein kleinerer Zone-Signing Key (ZSK) die tatsächlichen Antworten signierte. Gewöhnliche Abfragen würden die kleinen ZSK-Signaturen verwenden und innerhalb der UDP-Grenzen bleiben, während nur der DNSKEY-Eintrag groß wäre. Das dritte Experiment, genannt „Gargantuan“ Combined Signing Key (CSK), führte zu einer DNSKEY-Antwort von 23.843 Bytes. Zwei solche Schlüssel passen immer noch in eine DNS-TCP-Antwort, da diese unter dem 64K-Limit liegt, aber die DNS-Implementierung benötigt einen Patch, um große Puffer zu verwenden. Stenstam bemerkte, dass es dann „funktioniert einwandfrei“.

Diese Experimente deuten darauf hin, dass der bisher in DNSSEC verwendete Mono-Algorithmus-Ansatz für den Post-Quantum-Einsatz möglicherweise ungeeignet ist. Der KSK, der selten verwendet wird, aber lange stabil bleiben muss, hat andere Anforderungen als der ZSK, der jede Antwort signiert und klein sein muss. Innovationen wie geteilte Profile oder schneller Schlüsselwechsel könnten es DNSSEC ermöglichen, das Quantenzeitalter zu überstehen, ohne den DNS-Verkehr zu schwer für die Ökonomie des Internets zu machen.

Für alltägliche Internetnutzer und Unternehmen kann die Wahl eines datenschutzorientierten verschlüsselten DNS-Dienstes wie AEU DNS (https://aeu-dns.com) dazu beitragen, die Anfälligkeit für diese Risiken zu verringern. Verschlüsseltes DNS verhindert Manipulationen an DNS-Antworten auf dem Übertragungsweg, die die Grundlage von Cache-Poisoning-Angriffen bilden, und ein gut geführter Resolver, der DNSSEC validiert, fügt eine weitere Sicherheitsebene hinzu, dass Antworten authentisch sind.