OARC 45: Warum die Verschlüsselung des DNS-Hops vom Resolver zum Authoritativen Server ins Stocken geraten ist

Das Domain Name System (DNS), oft als das Telefonbuch des Internets bezeichnet, übersetzt benutzerfreundliche Domainnamen in die numerischen IP-Adressen, die Computer verwenden. Fast jede Online-Aktivität beginnt mit einer DNS-Abfrage, und wenn jemand alle Ihre DNS-Abfragen beobachten kann, kann er ein detailliertes Bild Ihres Online-Lebens erstellen. Jahrelang fand diese Datenschutzschwäche wenig Beachtung, aber die Snowden-Enthüllungen 2013 brachten Massenüberwachung und DNS-Datenschutz fest auf die Tagesordnung. Standardmäßig werden DNS-Abfragen und -Antworten im Klartext übertragen, was sie anfällig für Abhören und Manipulation durch jeden im Netzwerkpfad macht.

Um dies zu beheben, entwickelte die Internet Engineering Task Force (IETF) verschlüsselte DNS-Protokolle: DNS over TLS (DoT), DNS over QUIC (DoQ) und DNS over HTTPS (DoH), zusammen als DoX bekannt. Diese fügen Verschlüsselung und Serverauthentifizierung zwischen dem Gerät des Benutzers (dem 'Stub-Resolver') und einem rekursiven Resolver hinzu, dem Server, der die eigentliche Arbeit der DNS-Auflösung übernimmt. Das Einrichten einer verschlüsselten Sitzung verursacht im Vergleich zu einer einfachen UDP-Abfrage zusätzlichen Aufwand, aber da das Gerät dieselbe verschlüsselte Sitzung für viele Abfragen wiederverwenden kann, amortisieren sich die Kosten. Geoff Huston stellt fest, dass bei Cloudflares öffentlichem Resolver 1.1.1.1 DoH etwa 15 % der Abfragelast ausmacht und DoT etwa 10 %, obwohl er vermutet, dass die Zahlen bei ISP-betriebenen Resolvern viel niedriger sind, da der Benutzer bereits im Netzwerk des ISP ist.

Dies deckt jedoch nur den ersten Hop ab. Der zweite Hop liegt zwischen dem rekursiven Resolver und den autoritativen Nameservern, die die offiziellen Aufzeichnungen für eine Domain halten. Dieses Segment stellt ein geringeres individuelles Datenschutzrisiko dar, da die IP-Adresse des Benutzers nicht in der Abfrage enthalten ist, aber es gibt immer noch eine Exposition: Abfragen zeigen, welche Domain nachgeschlagen wird, und wenn ein Angreifer eine Antwort ändern kann, kann er den Cache des rekursiven Resolvers vergiften, sodass dieser vielen Benutzern falsche Antworten liefert, bis der Cache abläuft, ein Angriff, der als Cache-Poisoning bekannt ist. Eine Gegenmaßnahme ist Query Name Minimisation (RFC 9516), bei der der rekursive Resolver während des Auflösungsprozesses nur die minimal notwendigen Labels an jeden autoritativen Server sendet und den ursprünglichen Abfragetyp möglicherweise verbirgt. Eine Messstudie von 2020 ergab, dass etwa 18 % der Internetnutzer ihre Abfragen über rekursive Resolver leiten, die Query Name Minimisation durchführen.

Ein anderer Ansatz ist die opportunistische Verschlüsselung des Hops vom rekursiven zum autoritativen Server, beschrieben in RFC 9539 'Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS'. Dieser verwendet Verschlüsselung ohne Authentifizierung, nach dem Prinzip der opportunistischen Sicherheit aus RFC 7435. Eine kürzlich auf OARC 46 vorgestellte Studie maß die Unterstützung für opportunistisches Authoritative DNS über verschlüsselten Transport (ADoX). Sie ergab, dass autoritative Server für 3.074.281 registrierte Domains (0,93 %) eine Form von ADoX unterstützen, und bei Betrachtung der IP-Adressen dieser Nameserver nur 2.585 eindeutige Nameserver (0,32 %) ADoX unterstützen. Eine vergleichbare Studie mit RIPE-Atlas-Sonden fand keine rekursiven Resolver, die ADoQ verwenden, und nur 44 Sonden hinter rekursiven Resolvern, die ADoT verwenden, meist vom offenen Resolver-Dienst Quad9 betrieben. In der Praxis ist die Einführung ins Stocken geraten: Betreiber autoritativer Server sehen wenig Nutzen in der Unterstützung von ADoX, wenn kein Resolver es verwendet, und die inkrementellen Serverkosten für verschlüsselte Sitzungen sind viel höher als bei zustandslosem UDP. Rekursive Resolver sehen keinen Grund, ADoX zu unterstützen, wenn keine autoritativen Server es unterstützen.

Der opportunistische Ansatz hat klare Nachteile. Es dauert mehrere Round-Trip-Austausche, um eine TLS/TCP- oder QUIC-Verbindung mit einem autoritativen Server zu versuchen; für eine einzelne Abfrage ist dieser Aufwand höher als eine einfache UDP-Transaktion. Anders als beim Stub-zu-Resolver-Fall gibt es keine Sicherheit der Sitzungswiederverwendung: Der Resolver fragt diesen autoritativen Server möglicherweise nie wieder ab. Da der Server bei opportunistischer Verschlüsselung nicht authentifiziert wird, könnte ein Angreifer weiterhin als Mann-in-der-Mitte agieren; DNSSEC-Validierung signierter Domains ist erforderlich, um die Authentizität der Antworten zu bestätigen. Positiv ist, dass verschlüsselter Transport große Antworten besser handhaben kann und experimentelle Ansätze wie CHAIN Query Requests (RFC 7901) ermöglicht.

Ein anderer Ansatz verwendet den vorgeschlagenen DELEG-Ressourceneintrag, um die Fähigkeiten eines Servers für verschlüsselten Transport zu signalisieren. DELEG baut auf dem Service Binding (SVCB)-Format auf und ist keine kleine Änderung; es stellt eine größere architektonische Änderung dar. In einem DELEG-Eintrag fügt die übergeordnete Zone Informationen hinzu, dass ein Label ein Delegationspunkt ist, zusammen mit den Nameservern der delegierten Zone, ihren kryptografischen Schlüsseln, IP-Adressen und Protokollfähigkeiten, alles in einem DNSSEC-signierten Eintrag. Für einen Resolver kann DELEG streng kommunizieren, welchen verschlüsselten Transport die autoritativen Server unterstützen, sodass der Resolver opportunistisches Probing überspringen und einfach das beworbene Protokoll verwenden kann. Huston weist jedoch darauf hin, dass DNSSEC-Validierung nur die Authentizität der endgültigen DNS-Antwort garantiert; es garantiert nicht, dass der Resolver tatsächlich von der übergeordneten zur untergeordneten Zone gewandert ist oder dass jede DELEG-Delegation unabhängig validiert wurde. Auf dem OARC-Workshop gab es Warnungen, dass die Umstellung des gesamten DNS von leichtgewichtigem UDP auf verschlüsselte Sitzungen bei überstürzter Umsetzung 'katastrophale Folgen' haben könnte.

Ist diese Arbeit also mehr als eine akademische Übung? Derzeit sind die Spezifikationen für opportunistisches ADoX und DELEG größtenteils Papiertiger. Das aktuelle Framework des Internets zur Authentifizierung von Online-Transaktionen basiert auf X.509-Domainzertifikaten und TLS, nicht auf der Sicherstellung von DNS-Auflösungsergebnissen. Ein Angreifer kann weiterhin falsche DNS-Informationen injizieren, aber wenn ein Anwendungsdienst TLS verwendet (z. B. HTTPS), muss der Server nachweisen, dass er den privaten Schlüssel für den Domainnamen besitzt; wenn er das nicht kann, wird die Verbindung abgebrochen. ADoX oder DELEG ändern dieses Bild nicht. Sie können auch DNSSEC nicht ersetzen; die beiden lösen unterschiedliche Probleme: ADoX geht darum, wie ein Resolver einen Namen auflöst, während DNSSEC darum geht, ob ein Benutzer dem Ergebnis vertrauen kann. Sie sind komplementär.

Ein Sicherheitspurist würde strenge Kontrollen auf jedem Schritt wünschen: signierte DELEG-Einträge validieren, verschlüsselte und endpunktauthentifizierte Sitzungen mit jedem autoritativen Server öffnen und die endgültige Antwort DNSSEC-validieren. Aber die pragmatische Realität ist, dass Benutzer und Dienstanbieter schnelles, billiges DNS bevorzugen. Die Authentifizierungsfunktion wird über den TLS-Handshake auf die Anwendungsebene verlagert, und DNS-Infrastrukturbetreiber tragen keine der inkrementellen Kosten. Der Versuch, die Kosten für die Sicherstellung wieder auf die Namensauflösungsinfrastruktur zu verlagern, stößt auf erheblichen Widerstand. Mit anderen Worten: Die DPRIVE-Agenda blieb beim Hop vom rekursiven zum autoritativen Server stehen, weil kein ausreichendes Interesse bestand, dieses Infrastrukturmodell zu betreiben.

Wie sieht die Zukunft für die Verschlüsselung des Hops vom rekursiven zum autoritativen Server aus? Huston ist sich nicht sicher, ob er auf eine gesicherte Zukunft verweisen kann. Die Ökonomie spricht gegen DNS-Infrastrukturbetreiber; zusätzliche Kosten für verschlüsselte Sitzungen ohne zusätzliche Einnahmen zu übernehmen, ist keine vernünftige Geschäftsentscheidung. Für Benutzer bleibt DNS weitgehend kostenlos, weil Authentifizierung durch TLS auf der Anwendungsebene bereitgestellt wird. Dieses Bild wird sich wahrscheinlich nicht bald ändern. Für Leser, die heute praktischen Schutz wünschen, kann die Wahl eines datenschutzorientierten verschlüsselten DNS-Resolvers wie AEU DNS helfen, den ersten Hop zwischen Ihren Geräten und dem Resolver zu verschlüsseln, auch wenn die hier beschriebene tiefere Verschlüsselung zwischen Resolver und autoritativem Server ungelöst bleibt.