DoH, or Don't?

Carsten Strotmann, sys4.de

2022-02-25 Fri 00:00

Created: 2022-02-25 Fri 08:29

Agenda

  • DNS-Privacy
  • DoH/DoT/DoQ
  • The Dilemma
  • Summary

Privacy in DNS?

  • in recent years, the IETF has expanded the DNS protocol with privacy features
    • DNS-over-TLS (transport encryption between DNS client and DNS resolver)
    • DNS-over-HTTPS (transport encryption between DNS client and DNS resolver)
    • QNAME Minimization (less metadata in DNS)
    • EDNS-Padding (hiding of DNS data in encrypted connections)

The need for more DNS privacy

  • a study presented at IETF 105 during the Applied Networking Research Workshop in July 2019 found that
    • 8.5 % of networks (AS) intercept DNS queries (27.9% in China)
    • (today) most queries are answered un-altered
  • but the situation might change, intercept server might change DNS answers

encrypted transport for DNS

  • Terminology
    • Do53 = DNS-over-Port53 - classic DNS (UDP/TCP port 53)
    • DoT = DNS-over-TLS - TLS as the transport for DNS
    • DoH = DNS-over-HTTPS - HTTPS as the transport for DNS
    • DoQ = DNS-over-QUIC - QUIC as the transport for DNS
    • DoC = DNS-over-Cloud - DNS resolution via cloud services (Google, Q9, Cloudflare …)

Performance of DoT/DoH (1/2)

  • with TLS 1.3 performance of DoT/DoH is quite good
  • with established connections, performance can be similar to DNS-over-UDP due to
    • Pipelining
    • TCP fast open
    • 0-RTT resume
  • on connections with packet loss, DoT/DoH can be faster and more reliable than Do53!
  • not all implementations are fully optimized

Performance of DoT/DoH (2/2)

  • Mozilla found that in lossy networks DoH can be faster and more reliable than Do53
  • The study "Analyzing the Costs (and Benefits) of DNS, DoT, and DoH for the Modern Web" presented at Applied Networking Research Workshop July 2019 confirms that finding

DoT - DNS-over-TLS

DNS-over-TLS (1/3)

dns-over-tls01.png

DNS-over-TLS (2/3)

dns-over-tls02.png

DNS-over-TLS (3/3)

dns-over-tls03.png

DNS-over-TLS modes

  • DNS-over-TLS can be operated in two modes
    • opportunistic - try TLS authentication, but still use server in case authentication fails
    • strict - only use server if there are no errors in the TLS connection

DNS-over-TLS operators

DoH - DNS over HTTP(S)

DoH - DNS-over-HTTPS

dns-over-https.png

DoH timeline

  • IETF 100 - November 2017 - DNS over HTTP(S) (DoH) workinggroup started: https://datatracker.ietf.org/wg/doh/about/
  • IETF 101 - March 2018 - work on DNS Queries over HTTPS finished, start of working group last call (WGLC) in April 2018
  • October 2018 - RFC 8484 published

DNS-over-HTTPS and IDS/Network-filter

Quote from RFC 8484:

Operational Considerations […] Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS.

DoH in Firefox (1/3)

Firefox-61-TRR-Lookups.png

DoH in Firefox (2/3)

  • Firefox Quantum (Screenshot FF 68)

firefox-doh-setting.png

DoH in Firefox (3/3)

  • Mozilla plans to enable DoH in Firefox by default in the future. No date announced.
  • User can select among a list of certified DoH operators per "region"
  • operators of DoH services can apply for privacy certification
  • Mozilla Policy Requirements for DNS over HTTPs Partners: https://wiki.mozilla.org/Security/DOH-resolver-policy

DoH in Google Chrome

DoH operators (Selection)

Current DoT/DoH status

Firefox Browser

  • Firefox Trusted Recursive/Remote Resolver (TRR) Program
    • Cloudflare (default) or NextDNS
    • Comcast XFinity (coming)
    • automatic roll-out started in February 2020

Chrome(ium) Browser

  • DoH is implemented and can be enabled by the user
    • Google Chrome
    • Opera
    • Vivaldi
    • Brave
    • Microsoft Edge
    • Bromite
  • DoH "auto upgrade" for the configured DNS resolver (manual configured or DHCP/RA supplied)
  • Google is experimenting with adaptive DoH-Resolver-Discovery via DNS

Safari Browser (iOS, iPadOS, MacOS)

  • support for DoH and DoT in iOS 14 and MacOS 11 'Big Sur'
  • Support for Adaptive DNS resolver discovery and oblivious DNS (oDoH)

Android

  • DoT available from Android 9 "Pie"
  • manual setting
  • "auto upgrade" from the configured DNS resolver, or Google DNS as fallback

Apple MacOS 11 and iOS/iPadOS 14

  • support for DoT and DoH
  • global and per App/Application resolver selection possible
  • "encrypted DNS" configuration Apps possible, user can choose provider by installing App
  • OS can learn "per Domain" DoH/DoT setting via DNS or HTTP (Adaptive DNS-over-HTTPS)
  • OS can discover DoH/DoT Server via DHCP/PvD (Provisioning Domains) or queries to resolver.arpa via classic DNS53
  • Discovery methods in active discussion in the IETF ADD working group

Microsoft Windows 10

  • support in latest Windows 10/11 builds

Linux

  • DoT support in systemd-resolved for some time
  • opportunistic mode only (automatic fallback to DNS53)
  • no server authentication (MITM possible)
  • global or "per interface" setting
  • not enabled by default

OpenBSD

  • DoT support in unwind
  • not enabled by default
  • opportunistic "auto update" mode or manual configured "strict" mode
  • server authentication via TLS certificate

DoT vs DoH

  • differences between DoT and DoH
    • DoT can be easily blocked, because it is running on an dedicated port (853)
    • DoH is made to look like normal HTTPS traffic, selective blocking of DoH is difficult
    • DoH seems to be easier to implement, because of existing HTTPS library functions in programming languages
    • DoH enables developers to do DNS name resolution on an application level, which some people think is bad

The DoH dilemma

  • to reach the Internet users that are in need of privacy, DoH needs to be enabled by default
    • DoH Server selection can be seen as similar to the CA selections browsers do
  • a fixed selection "per region" will (still) lead to centralization of all DNS queries with a few DNS operators
    • but that might still be the case even without DoH, some countries in Asia send > 90% of DNS queries to DoC (Google)

DoH and DoT Software - only browser?

  • new DNS privacy protocols sparked a large number of new software projects
  • this part of the presentation will look at
    • comparison of the start of new software projects in comparison to the new standards
    • number of projects for DNS-over-HTTPS vs. DNS-over-TLS
    • programming languages used to implement the new protocols

The survey

  • looked at 55 DoT/DoH open source software projects on Github and Gitlab
  • done in May 2019 and June 2019
  • only software products, no composition projects (Docker Container etc)
  • full list: https://doh.defaultroutes.de/implementations.html
  • see presentation at RIPE 78 and recent blog post in the APNIC blog (linked from the page above)

Languages

Projects-by-pgm-language.png

DoT vs DoH

Which protocols are implemented. Some projects implement both:

Projects-by-DNS-privacy-protocol.png

Project start

Year of the first commit, frist release or when DoH/DoT functions were implemented

Project-by-project-start-year.png

Freshness

Activity in the project in the last 6 month?

Project-by-project-activity.png

Applications

  • Firefox
  • Chrome
  • curl
  • Tenta-Browser
  • Bromite

System Resolver

  • systemd-resolved
  • unwind
  • resolver module for Linux glibc

Client-Proxies

  • sdns
  • dnscrypt-proxy2
  • veild
  • stubby
  • unbound
  • cloudflared
  • Dohnut
  • dns-over-https

Server-Proxies

  • rust-doh
  • dnsdist
  • dns-over-https

Server

  • BIND 9.18
  • unbound
  • Knot
  • sdns

Whats missing in DoH/DoT software

  • certificate authentication via DANE
  • Wittness function - query multiple provider and compare response data
  • security audits of DoH/DoT software

DNS over QUIC - the future of DNS?

what is QUIC

  • modern TCP replacement from Google, being currently standardized in the IETF
    • based on UDP, implements TCP features
    • implemented as part of the application, not the OS
    • includes TLS 1.3
    • 0-RTT
  • DoQ similar to Do53 (DNS-over-UDP)
  • QUIC IETF WG documents https://tools.ietf.org/wg/quic/

DNS over QUIC

dns-over-quic01.png

DNS over QUIC Comparision

dns-over-quic.png

Figure 12: Source: https://datatracker.ietf.org/meeting/99/materials/slides-99-dprive-dns-over-quic

Was ist dnsdist

  • dnsdist ist ein Open-Source DNS load-balancer
  • dnsdist wird von PowerDNS.COM B.V erstellt und betreut
    • dnsdist ist unabhängig vom PowerDNS autoritativen DNS server und vom PowerDNS Recursor (die Produkte teilen sich Quellcode)
    • dnsdist kann zusammen mit anderen DNS Servern benutzt werden (BIND 9, NSD, Windows DNS, Unbound …)

dnsdist Besonderheiten (1)

  • dnsdist empfängt DNS Anfragen und leitet diese an nachfolgende DNS Resolver oder autoritative DNS Server weiter
    • fail-over oder load-balancing Regeln steuern diese Weiterleitung
  • Antworten können im dnsdist gecached werden
  • dnsdist kann Angriffe und DNS-Missbrauch erkennen und abwehren
  • DNS-over-TLS und DNS-over-HTTPS Unterstützung
  • DNScrypt Unterstützung

dnsdist Besonderheiten (2)

  • eBPF Socket Filter (Linux)
  • Einfache aber mächtige Konfigurations-Möglichkeiten mit der Programmiersprache Lua
  • Kann im Betrieb dynamisch umkonfiguriert werden (ohne Neustart)
  • Remote HTTP API
  • Eingebauter Web-Server für API-Zugriffe, Monitoring und Statistiken

Anwendungsszenarien für dnsdist

Fail-Over

  • dnsdist kann DNS Anfragen basierend auf der Verfügbarkeit von Backend-Servern im Pool verteilen
    • Hierzu wird die Policy firstAvailable benutzt
    • Bei dieser Policy haben die Server im Pool eine Reihenfolge: der erste verfügbare Server in der Reihenfolge bekommt alle Anfragen
    • Diese Policy kann zusätzlich mit einem "Anfragen pro Sekunde" Limit konfiguriert werden
      • Wird dieses Limit überschritten, so werden die überzähligen Anfragen an den nächsten DNS Server in der Reihe geleitet

Fail-Over

dnsdist-failover.png

Load-Balancing

  • dnsdist kann DNS Anfragen auf verschiedene Back-End-Server (oder Back-End-Server Pools) verteilen. Hierbei gibt es verschiedene Load-Balancing Konfigurationen:

  • leastOutstanding: benutze den/die Server mit den wenigsten noch ausstehenden Anfragen
  • chashed: verteile die DNS Anfragen basierend auf dem Hash des Domain-Namens der Anfrage
  • whashed: verteile die DNS Anfragen basierend auf dem Hash des Domain-Namens der Anfrage, aber mit einer Gewichtung der Back-End-Server
  • wrandom: zufällige Verteilung der Anfragen, jedoch mit einer Gewichtung der Back-End-Server (die Back-End-Server bekommen einen Anteil der Anfragen basierend auf der Gewichtung)
  • roundrobin: Anfragen werden auf Basis eines Round-Robin Algorithmus verteilt

Load-Balancing

  • Die Load-Balancing Regeln können durch eigene, in der Programmiersprache Lua (https://www.lua.org/) programmierten, Regeln erweitert werden
    • Beispiel einer einfachen Round-Robin Policy:
counter=0
function luaroundrobin(servers, dq)
     counter=counter+1
     return servers[1+(counter % #servers)]
end

setServerPolicyLua("luaroundrobin", luaroundrobin)

Load-Balancing

dnsdist-loadbalance.png

DoH/DoT Proxy, DDoS und Malware Absicherung

  • dnsdist kann neue Funktionen zu bestehenden autoritativen DNS Server und DNS Resolvern hinzufügen, ohne das Änderungen an diesen Backend-Servern notwendig sind
    • Schutz vor Denial-of-Service Angriffen
    • Filtern von bekannten Malware-Domains (aka DNS-Firewall)
    • DNS Transport-Verschlüsselung (DNS-over-TLS und DNS-over-HTTPS)

DoH/DoT Transport Verschlüsselung

dnsdist-dohproxy.png

Messdaten in einem DNS-Server-Cluster zusammenführen

  • Da dnsdist als zentrales System die Anfragen an die Server eines DNS-Clusters weiterleitet, kann dnsdist ein Monitoring für einen DNS-Cluster bereitstellen
    • für mehrere DNS Resolver
    • für mehrere autoritative DNS Server

Messdaten zusammenführen

dnsdist-metrics.png

Zentraler DNS Cache

  • dnsdist ist kein DNS-Resolver, es kann keine DNS-Delegationen verfolgen und DNS Namen selbstständig auflösen
    • dnsdist kann jedoch die Antworten von DNS-Resolvern im Cache speichern und von dort beantworten
    • dnsdist kann optional abgelaufene DNS-Informationen senden (TTL expired), wenn keiner der konfigurierten Back-End-Server erreichbar ist
> getPool(""):getCache():printStats()
Entries: 122/10000
Hits: 9147
Misses: 10147
Deferred inserts: 1
Deferred lookups: 0
Lookup Collisions: 0
Insert Collisions: 0
TTL Too Shorts: 0

Zentraler DNS Cache

dnsdist-shared-cache.png

Schutz von autoritativen DNS Servern

  • dnsdist kann als front-end Load-Balancer vor autoritativen DNS Servern eingesetzt werden
    • Mittels spezieller Regeln kann dnsdist die autoritativen DNS Server vor bestimmen bösartigen DNS Anfragen schützen
    • Back-End Server können aus dem Cluster genommen werden (für Wartung oder zur Analyse von Vorfällen), ohne das der DNS-Dienst beeinträchtigt wird

Schutz von autoritativen DNS Servern

dnsdist-authlb1.png

Schutz von autoritativen DNS Servern

dnsdist-authlb2.png

DoH/DoT Termination

  • dnsdist kann DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) Verbindungen terminieren
    • dnsdist erstellt einen DoH/DoT "proxy", welcher DoH/DoT Anfragen von DNS Clients annimmt und via klassischem DNS (UDP/TCP Port 53) an einen Back-End-Resolver weiterleitet

DoH/DoT Proxy

dnsdist-dohproxy.png

Motivation für einen DoH/DoT Proxy?

  • Einfache Installation
  • Die existierenden DNS-Resolver müssen nicht geändert werden
  • Über separate Hardware/Server lässt sich diese Lösung einfach skalieren

Questions?

Links 1

Links 2

Links 3

Links 4

Links 5