Discovery of Designated Resolvers

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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.[1][2] Das Verfahren wurde durch die Internet Engineering Task Force im RFC 9462[3] 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,[4] DNS over QUIC (DoQ) RFC 9250,[5] oder DNS over HTTPS (DoH) RFC 8484[6] stattfinden.[7]

Ablauf

[Bearbeiten | Quelltext bearbeiten]

Dies ist eine vereinfachte schematische Darstellung des Ablaufes einer DDR initiierten DoH auf DNS Abfrage:

  1. Client ↔ DNS-Server mit SVCB Record.
    Der Client macht eine special use domain name (SUDN) RFC 6761[8] 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.
  2. 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.
  3. 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.[9][10] Die Verbindungen über TLS werden bei der Verbindung zu den verschlüsselten DNS Servern mit Encrypted Client Hello’s (ECH) initiiert.[11][12] 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

[Bearbeiten | Quelltext bearbeiten]

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.[13] 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.[14]

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.[15]

Seit MacOS Ventura und iOS 16 sind DoT sowie DoH mit dem DDR Verbindungsautomatismus standardmäßig benutzbar und ohne Konsolen Eingriff in MacOS nutzbar.[16]

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.[17]

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.[18][19][20]

Siehe auch

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Discovery of Designated Resolvers. Internet Engineering Task Force, abgerufen am 12. Mai 2023 (englisch).
  2. ↑ Discovery of Designated Resolvers (Datatracker). Internet Engineering Task Force, abgerufen am 12. Mai 2023 (englisch).
  3. ↑ RFC: 9462 – Discovery of Designated Resolvers. (englisch).
  4. ↑ RFC: 7858 – Specification for DNS over Transport Layer Security (TLS). Mai 2016 (englisch).
  5. ↑ RFC: 9250 – DNS over Dedicated QUIC Connections. Mai 2022 (englisch).
  6. ↑ RFC: 8484 – DNS Queries over HTTPS (DoH). Oktober 2018 (englisch).
  7. ↑ Eliot Lear: Improving DNS Security While Preserving Resiliency. In: CISCO Blogs. Abgerufen am 13. Mai 2023 (englisch).
  8. ↑ RFC: 6761 – Special-Use Domain Names. Februar 2013 (englisch).
  9. ↑ Rafael Vanoni: The Use Cases and Benefits of SVCB and HTTPS DNS Record Types. Abgerufen am 18. Mai 2023 (englisch).
  10. ↑ Carsten Strotmann, Alan Clegg: HTTPS and SVCB Records (New records for the Web). (PDF) Abgerufen am 18. Mai 2023 (englisch).
  11. ↑ TLS Encrypted Client Hello. Internet Engineering Task Force, abgerufen am 18. Mai 2023 (englisch).
  12. ↑ TLS Encrypted Client Hello (Datatracker). Internet Engineering Task Force, abgerufen am 18. Mai 2023 (englisch).
  13. ↑ Christopher Wood, Anbang Wen: Announcing experimental DDR in 1.1.1.1. In: Cloudflare Blog. Abgerufen am 13. Mai 2023 (englisch).
  14. ↑ Tommy Jensen: DNS over TLS available to Windows Insiders. Microsoft Tech Community, abgerufen am 13. Mai 2023 (englisch).
  15. ↑ Albert Jelica: Windows 11 22H2: Alle Neuerungen und neue Funktionen. Windows Area, abgerufen am 13. Mai 2023.
  16. ↑ Qiaoyu (Joey) Deng: Improve DNS security for apps and servers. Apple Develeopers, abgerufen am 14. Mai 2023 (englisch).
  17. ↑ Remi Gacogne: First release candidate of dnsdist 1.8.0 – Release notes. In: dnsdist.org. Abgerufen am 22. Mai 2023 (englisch).
  18. ↑ Jan Žorž: DNS privacy in new Android 9. In: internetsociety.org. 21. August 2018, abgerufen am 19. August 2024 (englisch).
  19. ↑ Sebastian Günther: Google macht DNS auf Android per DoH schneller. In: www.linux-magazin.de. 21. Juli 2022, abgerufen am 19. August 2024.
  20. ↑ Nadine Dressler: Android verbessert Datenschutz mit Unterstützung für DNS-over-HTTP/3. In: www.winfuture.de. 21. Juli 2022, abgerufen am 19. August 2024.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Discovery_of_Designated_Resolvers&oldid=250324394“