# Discovery of Designated Resolvers

Discovery of Designated Resolvers (DDR) ist eine Sammlung von Mechanismen, welche es einem mit dem Internet verbundenen Computer ermöglichen, lediglich anhand einer IP eine verschlüsselte Verbindung zu einem Domain-Name-System-Dienst aufzubauen. Das Verfahren wurde durch die Internet Engineering Task Force im spezifiziert. Es befindet sich im Status eines vorgeschlagenen Standards.
Ähnlich dem DHCP-Protokoll initiiert dieser Mechanismus dabei nur anhand einer IP-Adresse eines nicht verschlüsselten DNS-Servers eine gesicherte Verbindung zu einem oder mehreren in Verbund arbeitenden spezialisierten DNS Servern. DDR handelt die Bedingungen der verschlüsselten Kommunikation aus, die nach dem ersten Kontakt folgt. Nach dem erfolgreichen Durchlaufen dieses Mechanismus sollte – wenn alles funktioniert – eine durch Transport Layer Security (TLS, früher auch Secure Socket Layer (SSL) genannt) getunnelte Verbindung zum Server bestehen, um die eigentliche DNS Abfrage einzuleiten. Die eigentliche DNS Abfrage kann dabei durch DNS over TLS (DoT) Request for Comments RFC 7858, DNS over QUIC (DoQ) RFC 9250, oder DNS over HTTPS (DoH) RFC 8484 stattfinden.

## Ablauf

Dies ist eine vereinfachte schematische Darstellung des Ablaufes einer DDR initiierten DoH auf DNS Abfrage:
* Client ↔ DNS-Server mit SVCB Record. Der Client macht eine special use domain name (SUDN) RFC 6761 Abfrage auf einen SVCB (Service Binding) Eintrag eines DNS Servers. In diesem Eintrag steht ein Zeiger auf die Adresse eines verschlüsselten DNS Servers sowie die Parameter und Bedingungen der Verbindung dorthin. In diesem Schritt ist der DDR-Mechanismus bei der Arbeit. Es müssen neben der IP-Adresse des auflösenden DNS-Servers auch andere Daten ausgetauscht werden, wozu zum Beispiel der qualifizierte Hostname, alternative IP-Adressen, nicht standardmäßige Ports und die URI Vorlagen gehören. Das ist normalerweise nicht Bestandteil einer standard DNS Abfrage. Sind alle notwendigen Daten in diesem SVCB Record enthalten folgt Schritt zwei, die Eigentliche DNS Abfrage.
* Client → DNS Anfrage auf den endgültigen Resolver wie beschrieben im SVCB Record. Auf den Empfang der Daten vom SVCB Halter hin öffnet der Client eine verschlüsselte Verbindung zu dem endgültigen vom SVCB DNS Record designierten Resolver.
* Client ← DNS Abfrage auf das Ziel „example.com“ wird bedient und gegengecheckt. Im letzten Schritt wird die Integrität der gesamten Interaktion überprüft. Im endgültigen DNS record steht, wer designieren darf, und es wird ein Zertifikat auf dem Client mit dem Server abgeglichen.
Wichtig anzumerken ist das die meiste Arbeit bei diesem Ablauf durch den Client und nicht den Server erfolgt. Dadurch wird die Last des Servers verringert sowie die Ansprechzeit des Servers beibehalten. Der gesamte DDR First Contact Mechanism ist dazu ausgelegt, innerhalb des Netzwerks des Service Anbieters zu vermitteln. Es muss eine Aushandlung der eigentlichen Verbindungseigenschaften im ersten Schritt unter anderem deswegen geben, weil es higher und lower priority service endpoints (die verschlüsselten Server) gibt. Es wird eine Art von Quality of Service der Abfrage gewährleistet. Des Weiteren würde es bei der Benutzung von DNSSEC zu einem Verbindungsabbruch aus Sicherheitsgründen kommen was vermieden werden soll. Die Verbindungen über TLS werden bei der Verbindung zu den verschlüsselten DNS Servern mit Encrypted Client Hello’s (ECH) initiiert. Die Benutzung von DDR macht im Vergleich zur Benutzung der DNS over HTTPS Optionen in verschiedenen Browsern alle DNS Abfragen sicher, auch DNS Abfragen von jeglichen Programmen die nicht DoH, DoT oder DoQ aware sind. Im besten Fall werden auch zum Beispiel Drucker oder IoT-Geräte im lokalen Netzwerk des Clients nur mit verschlüsselten DNS-Abfragen vermittelt durch den Router versorgt. Dazu kann auch das Client-Betriebssystem als Router dienen.

## Implementierungen

Seit 2022 bestehen erste Absichtserklärungen der Implementierungen bei Herstellern von Betriebssystemen wie Microsoft und Apple. Es gibt bereits Implementierungen für Teilnehmer des Windows-Insider-Programmes in Vorabversionen des Windows 11 Betriebssystems. Erste Anbieter von verschlüsselten DNS Servern haben 2022 die Möglichkeit zur Aushandlung einer sicheren Verbindung zu ihren Servern per DDR in ihre Systeme bereits integriert.
DDR ist seit dem 22H2 Update im Windows 11 stable Kanal also dem standard Windows enthalten. Man gibt eine IP des DNS Resolvers an und Windows und der DNS-Server machen den Rest.
Seit MacOS Ventura und iOS 16 sind DoT sowie DoH mit dem DDR Verbindungsautomatismus standardmäßig benutzbar und ohne Konsolen Eingriff in MacOS nutzbar.
Der DNS loadblancer dnsdist von PowerDNS der DNS Abfragen an DNS server kanalisiert um deren Auslastung (load) zu balancieren enthält seit Februar 2023 in der Version 1.8.0 ebenfalls DDR als client sowie als server. dnsdist ist im userspace für die Linux Distributionen von zum Beispiel Debian und Redhat sowie den BSD Derivaten NetBSD, OpenBSD und FreeBSD verfügbar. Seit Version 12 von FreeBSD und spätestens OpenBSD 6.7 ist es durch setzten einer rc.conf Variable sehr einfach möglich ebenfalls mit dem local unbound DNS cache daemon DNS-over-TLS Anfragen zu tätigen. Ebenso ist der unbound daemon in NetBSD in der Lage DNS Abfragen sowohl über TLS als auch durch das HTTPS Protokoll zu leiten und lokal einen cache dafür zu betreiben.
Ab Version 9 des Betriebssystems Android wurde die sogenannte sichere DNS Option zu den Netzwerkoptionen hinzugefügt. Seit Android 11 wird der hier beschriebene Mechanismus verwendet.