Analyse comparative des technologies DoH et DoT

DNS over HTTPS (DoH) et DNS over TLS (DoT) sont deux méthodes courantes de transport DNS chiffré. Elles utilisent différentes piles de protocoles pour réaliser la transmission sécurisée des requêtes DNS. Le standard DoT est défini par la RFC 7858, tandis que DoH est normalisé par le standard DNS Queries over HTTPS (DoH). Pour comprendre les différences fondamentales entre ces deux technologies, il faut analyser la structure en couches des protocoles réseau.

Structure en couches des protocoles réseau

Les piles de protocoles réseau modernes adoptent une conception en couches, chaque couche offrant des fonctionnalités différentes. DNS, en tant que protocole de la couche application, n’est pas lié à un mode de transport spécifique et peut fonctionner sur divers protocoles de support.

La couche application (L7) comprend les protocoles HTTP/1.1, HTTP/2, HTTP/3, FTP et DNS. Il convient de noter que la sémantique d’HTTP/3 réside toujours dans la couche application, QUIC servant simplement de support de transport. La couche de sécurité, située entre la couche application et la couche transport, comprend principalement TLS et ses variantes. TLS s’exécute généralement sur TCP, comme pour HTTPS et DoT. DTLS est la version datagramme de TLS et peut fonctionner sur UDP. Le protocole QUIC est assez particulier ; il intègre directement l’établissement de liaison (handshake) et la dérivation de clés de TLS 1.3 dans le protocole lui-même.

QUIC peut être considéré comme un protocole de couche L4.5. Basé sur une extension d’UDP, il fournit les capacités de la couche transport traditionnelle. La couche transport (L4) comprend TCP, UDP et QUIC. Bien que, d’un point de vue d’ingénierie, QUIC soit basé sur UDP, il intègre nativement la fiabilité, le contrôle de congestion, le multiplexage et l’établissement de liaison chiffré, et est donc traité comme un protocole de transport indépendant en ingénierie. La couche réseau (L3) utilise le protocole IP (IPv4/IPv6) pour le routage et le transfert des paquets. La couche liaison de données (L2) comprend des technologies telles qu’Ethernet et Wi-Fi (802.11).

TLS, en tant que moyen de chiffrement, fonctionne entre la couche application et la couche transport. Si le chiffrement TLS est retiré de DoT, DoT devient essentiellement DNS over TCP. Cette conception en couches rend le chiffrement optionnel, plutôt qu’une contrainte obligatoire du protocole lui-même.

Caractéristiques du Plain DNS

Le DNS le plus courant est appelé Plain DNS ; il peut fonctionner sur UDP ou TCP. UDP est le mode de transport le plus fréquent car l’établissement de la connexion est simple et la première requête est rapide. Cependant, la faiblesse d’UDP est son manque de fiabilité ; les paquets sont facilement perdus dans le réseau. Bien que TCP nécessite davantage de poignées de main et que la vitesse de première connexion soit environ 30 % plus lente qu’UDP, une fois la connexion longue établie, sa vitesse de réponse est identique à celle d’UDP.

Les opérateurs choisissent de supprimer les paquets UDP lorsque le réseau est encombré afin de soulager la pression sur les équipements. Dans les régions où la perte de paquets UDP est sévère pour certains opérateurs, il peut être plus avantageux de spécifier l’utilisation de TCP pour les requêtes DNS. TCP possède un mécanisme de retransmission qui garantit une arrivée fiable des données même en cas de perte de paquets, alors que la perte de paquets UDP ne réduit pas la charge des équipements des petits opérateurs et introduit au contraire plus d’incertitude en raison des nouvelles tentatives.

Imbrication de la couche application

DNS et HTTP appartiennent tous deux à la couche application ; DoH est essentiellement un protocole de couche application imbriquant un autre protocole de couche application. DoH n’est pas nécessairement DNS over HTTPS ; l’utilisation du HTTP standard est également possible, mais un DoH non chiffré est une requête en texte clair qui n’offre aucun avantage par rapport au Plain DNS. Il n’y a que très peu de scénarios à besoins spécifiques qui l’utilisent.

Théoriquement, il est possible de faire passer DNS sur n’importe quel protocole de couche application. Par exemple, DNS over FTP est également réalisable, il suffit de développer le serveur et le client correspondants. Cette flexibilité illustre les possibilités de combinaison des protocoles de la couche application.

flowchart TD
    subgraph L7["Couche Application"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["Couche Sécurité"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["Couche Transport"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["Couche Réseau"]
        I[IP]
    end
    
    subgraph L2["Couche Liaison"]
        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

Imbrication de la couche transport

Le protocole QUIC est basé sur UDP tout en fournissant un service orienté connexion au niveau de la couche transport. QUIC implémente des capacités de couche transport telles que la connexion orientée, le contrôle de congestion, la retransmission, le contrôle de flux, la fragmentation et le réassemblage, que TCP possédait déjà. Par rapport à TCP, QUIC a une latence plus faible. Par rapport à UDP, QUIC est plus avancé et fiable.

Relations de combinaison des protocoles

Il n’y a pas de relation de contrainte nécessaire entre la couche application et la couche transport ; le chiffrement peut être ajouté ou non. HTTP peut fonctionner sur TCP, ou sur QUIC. DNS peut fonctionner sur TCP, sur UDP, ou sur QUIC.

Sur la base de ces possibilités, les relations de combinaison suivantes peuvent être résumées. Plain DNS équivaut à UDP ou TCP combiné au protocole DNS. HTTP/2 équivaut à TCP combiné à TLS 1.2 ou TLS 1.3 puis au protocole HTTP. HTTP/3 équivaut à QUIC combiné à TLS 1.3 puis au protocole HTTP.

DoH (DNS over HTTPS) équivaut à HTTP/2 ou HTTP/3 combiné au protocole DNS. DoT (DNS over TLS) équivaut à TCP combiné à TLS 1.2 ou TLS 1.3 puis au protocole DNS. DoQ (DNS over QUIC) équivaut à QUIC combiné à TLS 1.3 puis au protocole DNS.

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

Analyse des performances et de la compatibilité

Après avoir compris la structure en couches des protocoles, nous pouvons analyser les avantages et inconvénients de DoH et DoT.

La comparaison entre TCP et QUIC doit être discutée en combinant l’environnement réseau réel des opérateurs. QUIC est un protocole plus récent qui résout certains problèmes de réseau anciens, mais il est tout de même basé sur UDP. D’un point de vue de latence réseau, les protocoles basés sur QUIC ont une latence environ 35 % plus faible que TCP ; par conséquent, DNS over HTTP/3 et DoQ (DNS over QUIC) sont théoriquement plus performants que DNS over HTTP/2 et DoT.

Cependant, dans l’environnement réseau réel, il existe des problèmes de latence de retransmission causés par la perte de paquets. Les opérateurs choisissent de supprimer les paquets UDP lorsque le réseau est encombré, et QUIC sera identifié comme UDP et supprimé. Bien que QUIC prenne en charge la retransmission, la latence introduite par celle-ci peut faire que la latence réelle de QUIC est plus élevée que celle de TCP.

En termes de confidentialité et de sécurité, DoH et DoT sont tous deux des flux chiffrés qui ne peuvent être ni interceptés ni falsifiés. Concernant le problème du blocage de DoH après son identification, il est principalement dû au fait que les paramètres DNS chiffré du système Android utilisent par défaut le port 853, ce qui en fait un port sensible. DoT lui-même est un flux chiffré courant et ne sera pas identifié comme un trafic spécifique au DNS. En réalité, n’importe quel port peut fournir un service DoT ; cela nécessite une application tierce sur Android, tandis qu’iOS supporte nativement DoT sur n’importe quel port.

L’extensibilité est un avantage important de DoH. Par rapport au DNS encapsulé dans HTTP et au Plain DNS, HTTP a une extensibilité nettement supérieure. Les fournisseurs de services peuvent proposer d’innombrables services sur le port 443, y compris DoH, et étendre facilement les fonctionnalités. DoT et DoQ nécessitent généralement un port dédié et leurs capacités d’extension sont entièrement basées sur Plain DNS. C’est une différence du point de vue du fournisseur de services ; pour l’utilisateur moyen, il n’y a pour l’instant aucune différence perceptible évidente.

En ce qui concerne la vitesse de traitement des requêtes DNS, le traitement HTTP peut en effet être plus lent de quelques cycles CPU que le Plain DNS, mais cette différence est négligeable dans une utilisation réelle. En termes de compatibilité, DoH pourrait devenir plus dominant car il offre une meilleure extensibilité pour les fournisseurs de services.

Le support actuel des plateformes principales pour le DNS chiffré varie. Les navigateurs basés sur le noyau Chromium prennent en charge DoH. Le système Windows 11 prend en charge DoH nativement. Les systèmes Android 8 et versions ultérieures prennent en charge DoT nativement. Les systèmes Android 11 et versions ultérieures prennent en charge DoT et DoH nativement. Le système macOS prend en charge DoT et DoH nativement. Le système iOS prend en charge DoT et DoH nativement.

Recommandations de choix pratiques

Pour l’utilisateur moyen, l’utilisation de DoH sera plus “sans souci” que DoT. Par rapport à DoT, DoH fournit une latence meilleure la plupart du temps et une latence similaire le reste du temps. Par rapport à DoQ, DoH a une latence similaire la plupart du temps et une latence meilleure le reste du temps.

Cette conclusion suppose que le fournisseur de services propose un service DNS over HTTP/3. Si le fournisseur n’offre pas HTTP/3, il n’y a pas de différence notable entre DoH et DoT. DoH utilisera automatiquement DoH/3 pour obtenir une latence plus faible lorsque la qualité du réseau est bonne, et rétrogradera automatiquement en HTTP/2 lorsque la qualité du réseau est mauvaise. Cette capacité adaptative doit être mise en œuvre par le fournisseur, mais les principaux fournisseurs l’ont généralement fait.

Je recommande d’essayer NullPrivate, qui prend en charge DoT et DoH/3, et intègre nativement le blocage des publicités et la fonction de division DNS (split DNS). Si vous avez besoin d’un déploiement autonome, vous pouvez utiliser sa bibliothèque open source.

Le choix du protocole réseau nécessite de prendre en compte plusieurs facteurs, notamment la qualité du réseau de l’opérateur, le support du fournisseur de services et la compatibilité des appareils. Pour la plupart des utilisateurs, DoH est un excellent choix qui équilibre performance, compatibilité et protection de la vie privée.

• ←Précédent
• Suivant→