Vergelijkende analyse van de technologieën DoH en DoT

DNS over HTTPS (DoH) en DNS over TLS (DoT) zijn twee veelvoorkomende manieren voor versleutelde DNS-overdracht. Ze gebruiken verschillende protocolstapels om de veilige overdracht van DNS-query’s te realiseren. De standaard voor DoT is gedefinieerd in RFC 7858, terwijl DoH is gestandaardiseerd in DNS Queries over HTTPS (DoH). Om de essentiële verschillen tussen deze twee technologieën te begrijpen, moet men starten met een analyse van de hiërarchische structuur van netwerkprotocollen.

Hiërarchische structuur van netwerkprotocollen

Moderne netwerkprotocolstapels maken gebruik van een gelaagd ontwerp, waarbij elke laag verschillende functies biedt. DNS, als een applicatielaagprotocol, is zelf niet gebonden aan een specifieke transportmethode en kan op verschillende dragende protocollen worden uitgevoerd.

De applicatielaag (L7) bevat protocollen zoals HTTP/1.1, HTTP/2, HTTP/3, FTP en DNS. Het is vermeldenswaard dat de semantiek van HTTP/ zich nog steeds in de applicatielaag bevindt, waarbij QUIC fungeert als transportdrager. De beveiligingslaag bevindt zich tussen de applicatielaag en de transportlaag en omvat voornamelijk TLS en zijn varianten. TLS draait doorgaans op TCP, zoals bij HTTPS en DoT. DTLS is de datagram-versie van TLS en kan op UDP draaien. Het QUIC-protocol is bijzonder: het integreert de TLS 1.3-handshake en sleutelafleiding direct in het protocol.

QUIC kan worden gezien als een L4.5-laagprotocol; het is gebaseerd op UDP-extensies en biedt de capaciteiten van de traditionele transportlaag. De transportlaag (L4) omvat TCP, UDP en QUIC. Hoewel QUIC vanuit het oogpunt van de technische implementatie gebaseerd is op UDP, wordt het in de praktijk als een onafhankelijk transportlaagprotocol beschouwd omdat het beschikt over betrouwbaarheid, congestiebeheersing, multiplexing en versleutelingshandshakes. De netwerklaag (L3) gebruikt het IP-protocol (IPv4/IPv6) verantwoordelijk voor het routeren en doorsturen van datapakketten. De datalinklaag (L2) omvat technologieën zoals Ethernet en Wi-Fi (802.11).

TLS werkt als versleutelingsmethode tussen de applicatielaag en de transportlaag. Als de TLS-versleuteling uit DoT wordt verwijderd, wordt DoT in wezen DNS over TCP. Dit gelaagde ontwerp maakt versleuteling tot een optie, geen dwingende beperking van het protocol zelf.

Kenmerken van Plain DNS

De meest gangbare DNS wordt Plain DNS genoemd; deze kan op UDP of TCP worden uitgevoerd. UDP is de meest voorkomende drager omdat de verbinding eenvoudig tot stand komt en de eerste query snel is. Het zwakke punt van UDP is echter de onbetrouwbaarheid; datapakketten raken in het netwerk snel verloren. Hoewel TCP meer handshakes vereist en de eerste verbinding ongeveer 30% langzamer is dan UDP, is de reactiesnelheid na het tot stand brengen van een lange verbinding gelijk aan die van UDP.

Providers kiezen er tijdens drukte op het netwerk voor om UDP-pakketten te laten vallen om de druk op apparaten te verlichten. Voor gebieden waar bepaalde providers veel UDP-pakketten laten vallen, kan het voordeliger zijn om TCP op te geven voor DNS-query’s. TCP heeft een mechanisme voor herdistributie; zelfs als pakketten verloren gaan, wordt gegarandeerd dat gegevens betrouwbaar aankomen. Het laten vallen van UDP-pakketten vermindert de belasting van apparaten van kleine providers niet; het introduceert eerder meer onzekerheid door nieuwe pogingen.

Nesting van de applicatielaag

Zowel DNS als HTTP behoren tot de applicatielaagprotocollen; DoH is in wezen een applicatielaagprotocol dat een ander applicatielaagprotocol nest. DoH is niet noodzakelijkerwijs DNS over HTTPS; het gebruik van gewone HTTP is ook mogelijk, maar onversleutelde DoH is een verzoek in klare tekst. Dit biedt geen voordelen ten opzichte van Plain DNS en wordt alleen in zeer weinige speciale scenario’s gebruikt.

Theoretisch kan DNS op elk applicatielaagprotocol worden gedragen; bijvoorbeeld DNS over FTP is ook te implementeren, zolang men de bijbehorende server- en clientsoftware ontwikkelt. Deze flexibiliteit weerspiegelt de mogelijkheden van het combineren van applicatielaagprotocollen.

flowchart TD
    subgraph L7["Applicatielaag"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["Beveiligingslaag"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["Transportlaag"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["Netwerklaag"]
        I[IP]
    end
    
    subgraph L2["Datalinklaag"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

Nesting van de transportlaag

Het QUIC-protocol is gebaseerd op UDP en biedt tegelijkertijd verbindingsgerichte diensten op de transportlaag. QUIC implementeert transportlaagcapaciteiten die TCP al heeft, zoals verbindingsgericht werken, congestiebeheersing, herdistributie, stroombeheersing, fragmentatie en assemblage. Vergeleken met TCP heeft QUIC een lagere latentie. Vergeleken met UDP is QUIC geavanceerder en betrouwbaarder.

Protocolcombinaties

Er is geen noodzakelijke beperkingsrelatie tussen de applicatielaag en de transportlaag; versleuteling kan wel of niet worden toegevoegd. HTTP kan op TCP draaien, maar ook op QUIC. DNS kan op TCP draaien, op UDP en op QUIC.

Op basis van deze mogelijkheden kunnen de volgende combinerelaties worden samengevat. Plain DNS is gelijk aan UDP of TCP plus het DNS-protocol. HTTP/2 is gelijk aan TCP plus TLS 1.2 of TLS 1.3 plus het HTTP-protocol. HTTP/3 is gelijk aan QUIC plus TLS 1.3 plus het HTTP-protocol.

DoH (DNS over HTTPS) is gelijk aan HTTP/2 of HTTP/3 plus het DNS-protocol. DoT (DNS over TLS) is gelijk aan TCP plus TLS 1.2 of TLS 1.3 plus het DNS-protocol. DoQ (DNS over QUIC) is gelijk aan QUIC plus TLS 1.3 plus het DNS-protocol.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

Prestatie- en compatibiliteitsanalyse

Na het begrijpen van de protocolhiërarchie kunnen de voor- en nadelen van DoH en DoT worden geanalyseerd.

De vergelijking tussen TCP en QUIC moet in samenhang met de daadwerkelijke netwerkomgeving van de provider worden besproken. QUIC is een nieuwer protocol dat enkele problemen met oudere netwerken oplost, maar het is tenslotte gebaseerd op UDP. Vanuit het oogpunt van netwerklatentie zijn protocollen gebaseerd op QUIC ongeveer 35% sneller dan TCP; daarom zouden DNS over HTTP/3 en DoQ (DNS over QUIC) theoretisch betere prestaties moeten leveren dan DNS over HTTP/2 en DoT.

In de daadwerkelijke netwerkomgeving bestaat echter het probleem van vertraging door herdistributie als gevolg van pakketverlies. Providers kiezen er tijdens drukte op het netwerk voor om UDP-pakketten te laten vallen; QUIC wordt geïdentificeerd als UDP en dus ook weggegooid. Hoewel QUIC herdistributie ondersteunt, kan de vertraging die hierdoor wordt geïntroduceerd ertoe leiden dat de werkelijke vertraging van QUIC hoger is dan die van TCP.

Op het gebied van privacy en veiligheid zijn zowel DoH als DoT versleuteld verkeer en kunnen ze niet worden onderschept of vervalst. Wat betreft het blokkeren van DoT na identificatie: dit is voornamelijk te wijten aan het feit dat de instellingen voor versleutelde DNS in het Android-systeem standaard poort 853 gebruiken, waardoor poort 853 een gevoelige poort wordt. DoT zelf is gewoonlijk alledaags versleuteld verkeer en wordt niet herkend als verkeer dat exclusief voor DNS is bedoeld. In feite kan elke poort DoT-diensten leveren; dit vereist op Android apps van derden, terwijl iOS DoH op elke poort ondersteunt.

Uitbreidbaarheid is een belangrijk voordeel van DoH. In vergelijking met in HTTP verpakte DNS en Plain DNS heeft HTTP duidelijk betere uitbreidingsmogelijkheden. Providers kunnen talloze diensten leveren op poort 443, waaronder DoH, en functies eenvoudig uitbreiden. DoT en DoQ hebben doorgaans een eigen poort nodig en hun uitbreidingsvermogen is volledig gebaseerd op Plain DNS. Dit is een verschil vanuit het perspectief van de provider; voor gewone gebruikers is er voorlopig geen duidelijk verschil merkbaar.

Qua verwerkingssnelheid van DNS-verzoeken kan de verwerkingssnelheid van HTTP inderdaad enkele CPU-cycli trager zijn dan Plain DNS, maar dit verschil is in de praktijk te verwaarlozen. Wat betreft compatibiliteit zal DoH waarschijnlijk mainstream worden, omdat DoH voor providers een goede uitbreidbaarheid biedt.

De ondersteuning voor versleutelde DNS door huidige mainstream-platforms verschilt per platform. Browsers met de Chromium-kernel ondersteunen DoH. Windows 11 ondersteunt DoH systeemeigen. Android 8 en hoger ondersteunen DoT systeemeigen. Android 11 en hoger ondersteunen zowel DoT als DoH systeemeigen. macOS ondersteunt zowel DoT als DoH systeemeigen. iOS ondersteunt zowel DoT als DoH systeemeigen.

Praktische adviezen voor keuze

Voor gewone gebruikers is het gebruik van DoH minder gedoe dan DoT. DoH biedt in de meeste gevallen een betere latentie dan DoT en in een minderheid van de gevallen een vergelijkbare latentie. DoH heeft in de meeste gevallen een vergelijkbare latentie als DoQ en in een minderheid van de gevallen een betere latentie.

De aanname bij deze conclusie is dat de provider DNS over HTTP/3-diensten aanbiedt. Als de provider geen HTTP/3 biedt, is er geen duidelijk verschil tussen DoH en DoT. DoH gebruikt bij een goede netwerkkwaliteit automatisch DoH/3 voor een lagere latentie en schakelt bij een slechte netwerkkwaliteit automatisch terug naar HTTP/2. Deze adaptieve capaciteit moet door de provider worden geïmplementeerd, maar de meeste mainstream providers hebben dit gerealiseerd.

We raden aan om NullPrivate te proberen; het ondersteunt DoT en DoH/3 en heeft native advertentieblokkering en DNS-splitsingsfuncties. Als u zelf wilt implementeren, kunt u de open source bibliotheek gebruiken.

De keuze voor een netwerkprotocol vereist een afweging van meerdere factoren, waaronder de netwerkkwaliteit van de provider, de ondersteuning door de provider en de apparaatcompatibiliteit. Voor de meeste gebruikers is DoH een uitstekende keuze die een balans vindt tussen prestaties, compatibiliteit en privacybescherming.

• ←Vorige
• Volgende→