Le système de noms de domaine Domain Name System (DNS) a été initialement conçu en 1983 comme un protocole en texte clair, sans authentification intégrée, fonctionnant sur le port UDP 53. Durant plusieurs décennies, cette architecture sans état Stateless a permis des résolutions très rapides avec une consommation minimale de ressources. Cependant, face aux écoutes passives des fournisseurs d'accès (FAI) et aux risques d'empoisonnement de cache Man-in-the-Middle (MitM), le DNS en clair constitue l'une des failles de confidentialité les plus critiques d'Internet.

Afin de sécuriser le premier tronçon entre les terminaux et les résolveurs récursifs, l'Internet Engineering Task Force (IETF) a standardisé DNS-over-TLS (DoT, RFC 7858) en 2016, puis DNS-over-HTTPS (DoH, RFC 8484) en 2018. Bien que ces technologies assurent une confidentialité robuste via Transport Layer Security (TLS), elles ont toutes deux hérité d'une limite structurelle majeure : la dépendance envers Transmission Control Protocol (TCP).

En environnement réseau dégradé—comme une couverture mobile 4G/5G instable ou un réseau Wi-Fi public saturé—le DNS chiffré sur TCP subit un blocage de tête de ligne (Head-of-Line Blocking, HoL), des délais de négociation multi-RTT et des coupures lors des changements de réseau.

En mai 2022, l'IETF a finalisé la spécification RFC 9250 : DNS over Dedicated QUIC Connections (DoQ). En transposant les requêtes DNS sur le protocole de transport QUIC (RFC 9000), DoQ élimine le blocage de tête de ligne, permet la reprise de session en 0-RTT, gère la migration fluide de connexion et supprime les en-têtes HTTP superflus.

[Transport DNS basé sur TCP : DoT et DoH (RFC 7858 / RFC 8484)]
Tuyau TCP sérialisé : [Requête 1] [Requête 2] [Requête 3] [Requête 4]
                                                 ▲ (Perte de paquet !)
Conséquence : Les requêtes 4, 5 et 6 sont BLOQUÉES dans le tampon du noyau jusqu'à retransmission de la 3 !
Pénalité de latence majeure sur les liaisons sans fil et mobiles.

─────────────────────────────────────────────────────────────────────────────────────────────

[Transport DNS basé sur QUIC : DoQ (RFC 9250)]
Flux UDP indépendants :
Flux 0  : [Requête 1 ──> Délivrée avec succès]
Flux 4  : [Requête 2 ──> Délivrée avec succès]
Flux 8  : [Requête 3 ──X Paquet perdu] ──> Retransmission isolée
Flux 12 : [Requête 4 ──> Délivrée IMMÉDIATEMENT !]
Résultat : Zéro blocage de tête de ligne ! Traitement asynchrone sans gel d'application.

Les contraintes architecturales de DoT et DoH

Pour comprendre l'intérêt de la RFC 9250, il convient d'analyser les limites physiques rencontrées par les protocoles précédents.

1. Le blocage de tête de ligne au niveau transport (TCP HoL)

DoT et DoH multiplexent l'ensemble des requêtes DNS concurrentes au sein d'un flux d'octets TCP unique. Le protocole TCP impose une livraison strictement ordonnée (In-Order Delivery) à la couche applicative.

Lorsqu'un navigateur Web moderne charge une application complexe, il émet simultanément plusieurs dizaines de requêtes DNS (domaine principal, réseaux de diffusion de contenu CDN, passerelles d'authentification et API). Si un paquet intermédiaire est perdu en raison d'interférences radio, le noyau du système d'exploitation suspend le traitement de tous les paquets suivants. Même si les réponses DNS des autres requêtes sont déjà parvenues à la carte réseau, l'application ne peut pas les lire tant que le paquet manquant n'a pas été acquitté et retransmis.

2. Le coût des négociations multi-RTT

L'initialisation d'une connexion chiffrée sur TCP accumule plusieurs allers-retours Round-Trip Time (RTT) :

  • Établissement de la liaison TCP en trois étapes : 1 RTT (SYN $\to$ SYN-ACK $\to$ ACK).
  • Négociation cryptographique TLS 1.3 : 1 RTT supplémentaire (ClientHello $\to$ ServerHello).
  • Délai total avant l'envoi de la première requête DNS : 2 RTT complets (ou 3 RTT avec TLS 1.2).

Pour un appareil mobile présentant un RTT de 70 ms, le terminal attend 140 à 210 ms uniquement pour établir la liaison avant d'émettre la première résolution.

3. Rupture de session lors du changement de réseau

Un socket TCP est lié de manière immuable à un quadruplet d'identification : adresse IP source, port source, adresse IP destination et port destination. Lorsqu'un utilisateur quitte son réseau Wi-Fi pour basculer sur le réseau mobile 4G/5G, l'adresse IP locale change. Le socket TCP est immédiatement détruit par un paquet RST, contraignant le système à réexécuter l'intégralité des poignées de main TCP et TLS.

4. La surcharge de la couche HTTP dans DoH

Si DoH traverse aisément les filtrages de ports en se dissimulant dans le trafic HTTPS standard sur le port 443, il introduit une charge protocolaire notable. Chaque requête DNS est enveloppée dans des trames HTTP/2 ou HTTP/3, requérant des pseudo-en-têtes (:method, :path), un en-tête Content-Type (application/dns-message) et des tables de compression HPACK. Une implémentation imparfaite risque en outre de transmettre des métadonnées de navigation telles que l'User-Agent ou des cookies.

Les innovations fondamentales de DNS-over-QUIC (RFC 9250)

DNS-over-QUIC écarte les couches intermédiaires TCP et HTTP pour transmettre les messages DNS directement sur le protocole QUIC.

L'indépendance des flux élimine le blocage de tête de ligne

Selon la RFC 9250, chaque transaction DNS (la requête et sa réponse associée) est assignée à un flux bidirectionnel dédié initié par le client (Client-Initiated Bidirectional Stream).

Le client attribue un identifiant de flux incrémental (Stream ID 0, 4, 8, 12) et transmet la longueur du message sur deux octets suivie de la charge binaire DNS standard. Le résolveur récursif renvoie la réponse sur ce même flux, puis ferme son sens d'émission au moyen du bit FIN.

Les flux QUIC étant des canaux logiques isolés multiplexés sur UDP, la perte d'un paquet appartenant au flux 8 n'a aucun impact sur le flux 12. L'application traite immédiatement la réponse du flux 12 sans attendre la reprise du flux 8.

Initialisation en 1 RTT et reprise en 0-RTT

QUIC fusionne l'échange de clés cryptographiques TLS 1.3 directement avec sa propre négociation de transport :

  • Première connexion : la synchronisation conjointe du transport et de la sécurité s'effectue en 1 RTT unique.
  • Reprise de session (0-RTT) : les clients ayant déjà communiqué avec le résolveur utilisent une clé pré-partagée Pre-Shared Key (PSK). La requête DNS chiffrée est transmise dès le tout premier paquet QUIC Initial, réalisant une résolution instantanée en 0-RTT.
Client                                                      Résolveur récursif
  │                                                                 │
  ├── 1. QUIC Initial [TLS ClientHello + Requête DNS 0-RTT chiffrée] ─>│
  │                                                                 │
  │<── 2. QUIC Handshake [ServerHello] + Réponse DNS (Flux 0) ──────┤
  │                                                                 │
  ▼  [Résolution DNS accomplie SANS aucun aller-retour additionnel !] ▼

Migration transparente de connexion (Connection Migration)

QUIC dissocie la session réseau des adresses IP physiques grâce aux identifiants de connexion (Connection ID).

Lorsqu'un terminal passe du Wi-Fi au réseau cellulaire, il continue d'émettre des paquets munis du Connection ID déjà établi depuis sa nouvelle interface. Le serveur DoQ authentifie cryptographiquement les paquets et met à jour sa table de routage instantanément, sans coupure de session ni réinitialisation.

Sécurité et confidentialité : protection contre l'analyse de trafic (Padding)

Si le chiffrement protège les noms de domaine contre la lecture directe, un observateur passif peut tenter d'identifier les sites consultés par analyse statistique du trafic (Traffic Analysis).

Neutralisation des empreintes de longueur par le bourrage EDNS(0) (RFC 8467)

La longueur des noms de domaine engendre des tailles de paquets caractéristiques. Un observateur placé sur le réseau peut comparer la taille des messages chiffrés avec les signatures des sites Web les plus visités.

La RFC 9250 rend obligatoire l'usage des politiques de bourrage définies dans les RFC 7830 et RFC 8467 :

  • Politique de bourrage par blocs (Block-Padding) : le client et le résolveur complètent les messages DNS jusqu'à des frontières prédéterminées à l'aide de l'option EDNS(0) Padding (code 12).
  • Selon les recommandations en vigueur, le client arrondit les requêtes à des multiples de 128 octets, et le résolveur arrondit les réponses à des multiples de 468 octets.
  • Les paquets en transit présentent ainsi des dimensions homogènes, privant les outils d'analyse de toute surface de corrélation statistique.

Choix des ports : UDP 853 et alternatives

Par défaut, la RFC 9250 assigne le port UDP 853 aux services DoQ dédiés (partagé avec DoT). Ce choix garantit une séparation administrative claire. Cependant, certains pare-feux d'entreprise stricts filtrent le trafic UDP sortant sur ce port.

Pour préserver la continuité du service, les passerelles DoQ modernes intègrent un mécanisme de repli automatique sur les ports UDP 443 ou 784 en présence de filtrage réseau.

Caractéristique DNS classique (RFC 1035) DNS-over-TLS (RFC 7858) DNS-over-HTTPS (RFC 8484) DNS-over-QUIC (RFC 9250)
Protocole de transport UDP / TCP en clair TCP + TLS 1.3 TCP/QUIC + HTTP + TLS QUIC natif (UDP)
Port par défaut 53 853 443 853 (ou 443/784)
Blocage de tête de ligne Non applicable Sévère (flux TCP) Sévère (HTTP/2 TCP) Nul (par flux QUIC)
Latence connexion à froid 0 RTT (En clair) 2 RTT (TCP + TLS) 2 RTT (TCP + TLS) 1 RTT (Combiné)
Latence reprise de session 0 RTT 1 RTT (Session TLS) 1 RTT (Session TLS) 0 RTT (Early Data)
Migration réseau Rupture Échec (Coupure socket) Échec (Coupure socket) Fluide (Connection ID)
Surcharge de trame Minime (En-tête 12B) Modérée (Longueur 2B) Élevée (En-têtes HTTP) Minime (Longueur flux)
Bourrage cryptographique Aucun Optionnel (RFC 7830) Optionnel (RFC 8467) Obligatoire (RFC 9250)

Mise en œuvre pratique d'un résolveur DoQ

Les administrateurs système peuvent déployer et tester des résolveurs récursifs DoQ performants avec des solutions telles qu'AdGuard Home, CoreDNS muni du plugin quic, ou le client q.

Validation d'un résolveur en ligne de commande

Utilisation de l'outil q (client DNS moderne supportant nativement QUIC) :

# Émission d'une requête chiffrée en DNS-over-QUIC sur le port 853 avec bourrage
q example.com @quic://dns.adguard-dns.com:853 --quic-pad

# Inspection des métriques de connexion QUIC et des identifiants de flux
q example.com @quic://1.1.1.1:853 -v

Configuration des résolveurs amonts dans AdGuard Home

Dans le fichier de configuration (AdGuardHome.yaml), configurez des serveurs amonts DoQ pour bénéficier de l'isolation des flux :

upstream_dns:
  - 'quic://dns.adguard-dns.com:853'
  - 'quic://unfiltered.adguard-dns.com:853'

# Serveurs de secours en cas d'indisponibilité
fallback_dns:
  - 'quic://1.1.1.1:853'

# Désactivation de la transmission du sous-réseau client
edns_client_subnet:
  enable: false

En appliquant edns_client_subnet.enable: false, le résolveur local retire les informations de sous-réseau client, empêchant les serveurs faisant autorité d'établir un profilage géographique de l'adresse IP d'origine.

L'architecture DNS sécurisée de VPNRice et RiceGuard

L'utilisation de DNS-over-QUIC gagne en efficacité lorsqu'elle est intégrée au sein d'une infrastructure VPN distribuée :

  • Résolveurs Anycast internes au tunnel : Chaque point de présence de VPNRice héberge un cluster de résolution DNS récursive privée. L'ensemble des requêtes DNS des utilisateurs est intercepté et acheminé dans le tunnel chiffré RiceGuard de couche 3, interdisant toute fuite en clair sur le port 53.
  • Canaux DoQ multiplexés vers les serveurs racine : Pour les résolutions amonts entre les passerelles Anycast et les serveurs racine faisant autorité, VPNRice exploite des liaisons DoQ durcies, éliminant les latences d'attente lors des pics de trafic.
  • Bourrage de trames et neutralisation des métadonnées : RiceGuard applique automatiquement un bourrage de longueur de bloc et supprime les champs EDNS Client Subnet (ECS), garantissant aux abonnés une confidentialité totale vis-à-vis des opérateurs de transit et des régies publicitaires.