Zusammenfassung

  • DoH schützt den Kanal zwischen Client und Resolver, bestimmt aber nicht den für den Nutzungskontext richtigen Resolver.
  • Discovery kann den bekannten Netzwerk-Resolver auf einen verschlüsselten Dienst anheben; die Auswahl bleibt Client-Politik.
  • Namensraum, Filter, Fallback und Rechtsraum der Protokolle wandern mit der Resolver-Wahl.
  • Eine Resolver-Richtlinienkarte muss Designation, Authentisierung, Auswahl, Namenskontext und Datenpraxis verbinden.

Ein hypothetisches Szenario: Zwei verwaltete Laptops verbinden sich mit demselben Büronetz. Das Betriebssystem des ersten findet und prüft den verschlüsselten Endpunkt des Resolvers, den das Netz vorgibt; ein interner Dienstname lässt sich weiterhin auflösen. Auf dem zweiten wählt der Browser einen öffentlichen DoH-Dienst. Die TLS-Verbindung funktioniert, doch der interne Name wird nicht mehr aufgelöst und der DNS-Filter des Netzes liegt nicht mehr im Abfragepfad. Beide verschlüsselten Verbindungen sind intakt. Der Unterschied liegt in der Resolver-Auswahl und in den damit geltenden Regeln.

RFC 8484 bildet jedes DNS-Anfrage-Antwort-Paar auf einen HTTPS-Austausch ab. TLS schützt Vertraulichkeit und Integrität. Derselbe Standard erläutert, dass lokale Regeln und Split-DNS je nach Resolver zu verschiedenen Antworten führen können. Inspektion, die unverschlüsseltes DNS voraussetzt, greift bei DoH ebenfalls nicht. Der geschützte Kanal macht damit eine zuvor oft implizite Governance-Entscheidung sichtbar: Welcher Baustein wählt den antwortenden Dienst?

RFC 9462 legt klare Grenzen für die Ermittlung eines solchen Dienstes fest. DDR erlaubt den Wechsel von einem bekannten unverschlüsselten Resolver zum verschlüsselten Angebot desselben oder eines kooperierenden Betreibers. Verified Discovery verlangt eine gültige Zertifikatskette und einen subjectAltName-Eintrag mit der IP-Adresse des Resolvers, der den Dienst bekanntgibt. Bei Opportunistic Discovery dürfen verschlüsselter und unverschlüsselter Dienst dieselbe IP-Adresse verwenden; empfohlen wird dieses Verfahren nur für private oder lokale Adressen.

Der Transport wird verschlüsselt, ohne die Resolver-Identität über den Zertifikatsnamen zu bestätigen. Die beiden Verfahren bieten damit unterschiedliche Sicherheit und nehmen dem Client die Auswahlentscheidung nicht ab.

RFC 9463 lässt das Netz verschlüsselte Resolver über DHCPv4, DHCPv6 oder IPv6 Router Advertisements bekanntgeben. Dabei können Authentisierungsdomain, Adressen, Protokollangaben und Prioritäten übermittelt werden. Diese netzseitige Vorgabe ist ein Angebot. Betriebssystem oder Anwendung können es annehmen, mit einer anderen Konfiguration vergleichen oder ablehnen. Verantwortung verteilt sich dadurch auf Zugangsnetz, Client-Plattform, Anwendung und Resolver-Betreiber.

Auch die Daten-Governance zieht um. RFC 8932 empfiehlt Datensparsamkeit, die kürzeste praktikable betriebliche Aufbewahrung, begrenzten Mitarbeiterzugriff und Transparenz über die Praxis. Ein Resolver-Wechsel kann deshalb zugleich Verarbeitungsort, Aufbewahrung, Rechtsraum und verfügbare Nachweise für Störungsanalysen verändern.

Das operative Instrument ist eine Resolver-Richtlinienkarte. Für jede Client-Gruppe und Netzsituation hält sie den Richtlinienverantwortlichen und den Entscheidungszeitpunkt fest, wer den Resolver vorgegeben hat, wie seine Identität geprüft wurde, welche Komponente ihn auswählte, welche Namensräume er bedient, welche Kontrollen gelten und welcher Fallback zulässig ist. Zusätzlich nennt sie die Verantwortung für Abfragen und Protokolle, die Aufbewahrungsdauer und den anwendbaren Rechtsraum. Öffentliche und interne Namen werden gemeinsam getestet; Änderungen an Browser, System, DHCP, Zertifikat oder Endpunkt lösen einen neuen Test aus.

Quellen