DoH3, DoQ et DoT : tout ce qui change fin 2025

Par CaptainDNS
Publié le 1 décembre 2025

#DNS
#DoH
#DoT
#DoQ
#Sécurité

Schéma comparant DoH3, DoQ et DoT dans une architecture DNS moderne

TL;DR

DoT est devenu le socle largement déployé du DNS chiffré, tandis que DoH3 et DoQ généralisent QUIC pour le transport des requêtes.
Fin 2025, de plus en plus d'OS, de navigateurs et de résolveurs activent le DNS chiffré par défaut, ce qui réduit la visibilité sur le port 53 classique.
Ces évolutions ont un impact direct sur l'architecture DNS d'entreprise : résolveurs, firewalls, proxies, observabilité et conformité doivent être adaptés.
La bonne approche n'est pas de "choisir un vainqueur", mais de définir une stratégie multi-transports : DoT en socle, DoH3 et DoQ pour les cas où latence, résilience et mobilité sont critiques.

Contexte : du DNS en clair au DNS chiffré

Pendant des décennies, la résolution DNS s'est faite majoritairement en clair, sur UDP/TCP 53. Cela simplifiait le debug et le filtrage réseau, mais laissait la porte ouverte à l'écoute, à l'injection de réponses et au profilage massif du trafic.

Avec l'essor de la confidentialité et la généralisation de TLS sur le Web, le DNS a progressivement suivi la même trajectoire : chiffrement du "dernier mile" entre le client (stub resolver) et le résolveur récursif, puis, plus récemment, adoption de transports modernes comme QUIC.

Fin 2025, trois briques structurent le paysage du DNS chiffré côté client → résolveur : DoT, DoH (dont DoH3) et DoQ. Comprendre leurs différences est essentiel pour anticiper les effets sur vos architectures.

Rappel rapide : DoT, DoH, DoH3 et DoQ

DNS classique (UDP/TCP 53)

Le DNS historique s'appuie sur UDP 53 pour la majorité des requêtes, avec un fallback TCP 53 pour les transferts de zone (XFR) et les réponses volumineuses. C'est simple, rapide, mais totalement en clair : un observateur réseau peut voir les noms de domaine résolus, injecter de fausses réponses ou bloquer certaines requêtes.

DNS over TLS (DoT)

DoT encapsule le DNS dans un flux TLS (généralement sur TCP 853) entre le client et le résolveur. Le protocole est normalisé par le RFC 7858 et vise à empêcher l'écoute et la manipulation des requêtes sur le chemin réseau.

En pratique, DoT :

utilise un canal TCP/TLS dédié (port 853) ;
offre des propriétés de confidentialité proches de celles d'un HTTPS "classique" ;
est largement supporté par les grands résolveurs publics et de nombreux résolveurs récursifs open source.

DoT est aujourd'hui le socle le plus mature pour le DNS chiffré côté infra, notamment parce qu'il reste conceptuellement proche du couple DNS + TLS déjà bien maîtrisé.

DNS over HTTPS (DoH) et DoH3

DoH transporte les requêtes DNS au-dessus de HTTPS (RFC 8484), donc sur le port 443, dans un canal HTTP/2 ou HTTP/3. Le message DNS est encapsulé dans un corps de requête HTTP, ce qui permet de profiter de toute la stack web : proxies HTTP, authentification, CDN, etc.

Lorsque DoH est utilisé au-dessus d'HTTP/3 (qui lui-même s'appuie sur QUIC), on parle souvent de "DoH3" :

même sémantique DNS que DoH ;
même port 443 que le trafic web, ce qui rend le filtrage plus complexe ;
mêmes bénéfices que QUIC : 0-RTT possible, meilleure gestion des pertes, multiplexage efficace.

DoH3 intéresse particulièrement les navigateurs et certaines applications, car il leur permet de masquer le DNS dans le flux HTTPS existant, tout en profitant de QUIC.

DNS over QUIC (DoQ)

DoQ utilise directement QUIC comme transport pour le DNS, sans passer par HTTP. Le protocole est défini par le RFC 9250 et vise à combiner :

les propriétés de confidentialité d'un canal TLS (comme DoT) ;
les performances et la résilience de QUIC : pas de head-of-line blocking au niveau transport, meilleure récupération en cas de perte de paquets, support natif de 0-RTT et de la mobilité de connexion.

En pratique :

DoQ utilise typiquement le port UDP 853, déjà associé historiquement à DNS-over-TLS/DTLS ;
chaque connexion QUIC peut transporter plusieurs requêtes DNS multiplexées ;
le protocole est particulièrement adapté aux environnements à latence variable (wifi dense, mobile, etc.).

Ce qui change réellement fin 2025

Fin 2025, la nouveauté n'est pas l'existence de DoT, DoH ou DoQ, tous sont standardisés depuis plusieurs années, mais leur niveau de déploiement et d'activation par défaut.

En résumé :

DoT est la brique "de base" du DNS chiffré côté résolveurs récursifs et services managés.
DoH est largement supporté par les navigateurs, les OS et les librairies applicatives, avec une montée en puissance du mode HTTP/3 (DoH3).
DoQ sort progressivement du domaine expérimental pour devenir une option sérieuse sur plusieurs serveurs récursifs modernes, notamment pour les environnements sensibles à la latence et à la résilience.

Ces tendances ont plusieurs conséquences concrètes pour les équipes réseau/DNS.

1. QUIC devient un transport DNS de premier plan (DoH3 et DoQ)

L'adoption de QUIC ne concerne plus uniquement le trafic web : une part croissante des résolutions DNS entre clients et résolveurs passe désormais par HTTP/3 (DoH3) ou par DoQ.

Impacts clés :

Latence : la combinaison 0-RTT + absence de head-of-line blocking au niveau transport améliore le temps de résolution perçu, surtout sur des réseaux avec perte ou latence variable.
Stabilité : QUIC gère mieux le changement d'adresse IP (roaming wifi ↔ 4G/5G) en conservant la connexion logique.
Surface de filtrage : bloquer "le DNS" ne revient plus à inspecter UDP/TCP 53 ; il faut également prendre en compte QUIC sur 443 (DoH3) et UDP 853 (DoQ).

Pour une architecture d'entreprise, cela signifie que les décisions de filtrage DNS doivent considérer les transports, pas uniquement les ports historiques.

2. Généralisation du DNS chiffré côté OS et navigateurs

Les OS modernes (desktop, mobile, serveur) exposent désormais des options natives pour activer DoT ou DoH, parfois au niveau système, parfois par application (navigateur, client VPN, agent de sécurité).

Conséquences :

Certains postes clients peuvent commencer à bypasser le résolveur d'entreprise pour interroger directement un résolveur public en DoH3/DoT.
Selon les politiques, cela peut entrer en conflit avec les exigences de journalisation, de conformité ou de filtrage (proxy de sécurité, DLP, etc.).
Les équipes IT doivent donc décider clairement : quels flux sont autorisés vers des résolveurs externes, sur quels transports, et dans quels cas ?

3. Observabilité et débogage plus complexes

Avec le DNS chiffré, il n'est plus possible d'inspecter le contenu des requêtes au niveau réseau entre client et résolveur sans terminaison TLS/QUIC contrôlée.

Cela impacte :

les outils de capture et d'analyse de trafic (tcpdump, Wireshark, sondes NDR) ;
les processus de debug "en urgence" (ex. filtrage inattendu, TTL incohérents, décalage de cache entre résolveurs internes et externes) ;
la corrélation entre logs DNS et logs applicatifs.

L'approche recommandée : déplacer une partie de l'observabilité au niveau du résolveur (logs structurés, métriques, traces) plutôt qu'au seul niveau des paquets réseau.

4. Maturité croissante des implémentations côté serveur

Les grands résolveurs récursifs open source (et commerciaux) ont désormais des implémentations stables de DoT, souvent de DoH, et, de plus en plus, de DoQ. Cela permet :

de déployer un résolveur interne ou "split-horizon" qui accepte plusieurs transports (UDP/TCP 53, DoT, éventuellement DoH/DoQ) ;
de séparer la façon dont les clients se connectent du mode utilisé pour interroger les serveurs faisant autorité ;
de faire évoluer progressivement les postes clients sans casser l'architecture DNS globale.

Comparatif rapide DoT / DoH3 / DoQ

Voici un tableau synthétique pour positionner ces trois transports dans votre design.

Protocole	Transport sous-jacent	Port typique	Multiplexage	Masqué dans le trafic web	Cas d'usage typiques
DoT	TLS sur TCP	853/TCP	Limité au flux TCP unique	Non	Baseline DNS chiffré entre clients/forwarders et résolveurs d'entreprise ou publics
DoH3	HTTP/3 (QUIC) sur UDP	443/UDP	Oui, via HTTP/3	Oui (difficile à distinguer du HTTPS)	Navigateurs, applications qui veulent s'intégrer dans la pile HTTP existante
DoQ	QUIC natif sur UDP	853/UDP	Oui, multiplexage QUIC	Non (mais ressemble à du QUIC générique)	Résolveurs récursifs modernes, environnements sensibles à la latence et à la résilience

Bon à savoir : dans tous les cas, ces protocoles ne remplacent pas DNSSEC (qui protège l'intégrité des données DNS entre résolveurs et autorités), mais le complètent en protégeant la confidentialité et l'intégrité du transport entre le client et son résolveur.

Impacts architecturaux sur vos infrastructures DNS

Flux DNS chiffrés entre client, résolveur d'entreprise et résolveurs publics

Ce schéma illustre une architecture typique fin 2025 :

À gauche, le client (poste, mobile, serveur) dispose d'un stub resolver pouvant parler en DNS classique (UDP/TCP 53), DoT, DoH3 ou DoQ.
Au centre, un ou plusieurs résolveurs d'entreprise terminent ces transports, appliquent cache, split-horizon et filtrage.
À droite, les résolveurs publics et les serveurs faisant autorité sont joints en DNS classique ou via DNS chiffré, selon la politique retenue.

La question clé devient : quels flux client → résolveur d'entreprise → résolveurs publics sont autorisés, chiffrés et observables ?

Résolveurs publics vs résolveurs d'entreprise

Fin 2025, il devient courant qu'un même poste client puisse :

utiliser le résolveur interne d'entreprise en UDP/TCP 53 ou DoT ;
en parallèle, interroger un ou plusieurs résolveurs publics en DoH3 ou DoQ via des applications spécifiques (navigateur, agent de sécurité, client VPN).

Questions à trancher côté architecture :

Les postes doivent-ils obligatoirement utiliser les résolveurs d'entreprise pour toute résolution ?
Les résolveurs d'entreprise exposeront-ils DoT et/ou DoQ aux clients internes ?
Les flux DoH/DoH3 vers des résolveurs publics sont-ils autorisés, bloqués, ou redirigés (proxy, interception TLS maîtrisée) ?

Anycast, CDN et géolocalisation

Avec le DNS chiffré, les grands résolveurs publics utilisent massivement l'Anycast et répartissent les connexions QUIC/TLS en fonction de l'emplacement du client. Cela peut entraîner :

des variations de résolution (différents points d'entrée dans un CDN selon l'IP source vue par le résolveur) ;
des différences entre ce que voit un client en DoH3/DoQ et ce que voit un autre en UDP 53 vers un résolveur différent ;
des effets de bord lorsqu'un proxy ou un VPN modifie l'IP source.

Pour les applications sensibles à la latence ou à la géolocalisation (vidéo, jeux, API critiques), il peut être pertinent de documenter clairement quel résolveur est attendu et quel transport est recommandé.

Observabilité, logs et conformité

Dans un monde où le DNS est chiffré par défaut, la bonne pratique consiste à :

centraliser les logs au niveau des résolveurs (requêtes, réponses, codes d'erreur, temps de résolution) ;
exposer des métriques (Prometheus, OpenTelemetry, etc.) pour suivre latence, échecs et volumes par transport (UDP, DoT, DoH3, DoQ) ;
définir ce qui est journalisé pour respecter les exigences RGPD et les politiques internes de confidentialité.

Autrement dit : plutôt que de "sniffer le port 53", il faut outiller vos résolveurs.

Sécurité et contrôle d'accès

Les contrôles de sécurité doivent être repensés :

filtrage en sortie : quels ports/hosts sont autorisés pour DoT (853), DoQ (853/UDP), DoH3 (443/QUIC) ?
segmentation : quels segments réseau peuvent sortir vers des résolveurs publics, lesquels doivent obligatoirement passer par un résolveur interne ?
détection : comment repérer un poste qui envoie du DNS chiffré non autorisé directement vers Internet ?

Un design robuste combine généralement :

un ou plusieurs résolveurs internes exposant au moins DoT ;
des politiques claires (et appliquées) sur les flux DNS chiffrés sortants ;
un monitoring régulier des tentatives de résolution "hors périmètre".

Check-list technique fin 2025

Cette check-list vous aide à évaluer rapidement votre niveau de préparation.

Couche	Point de contrôle	Question à se poser
Résolveur interne	Support DoT (et éventuellement DoQ)	Mon ou mes résolveurs internes proposent-ils au moins DoT aux clients ?
Pare-feu / proxy	Politique sur 53/853/443	Ai-je des règles explicites pour le DNS chiffré (DoT, DoH3, DoQ) et pas seulement pour UDP/TCP 53 ?
Postes clients	Configuration DNS	Qui contrôle la configuration DNS des OS et des navigateurs (GPO, MDM, scripts, etc.) ?
Observabilité	Logs et métriques DNS	Suis-je capable de corréler une panne applicative avec des métriques DNS chiffrées (latence, timeouts, erreurs) ?
Conformité	Traçabilité	Ai-je une réponse claire à la question "qui a résolu quoi, quand, via quel résolveur" en respectant la confidentialité ?

Vous pouvez également télécharger le comparatif au format CSV (voir bloc de téléchargement de l'article) pour l'utiliser dans vos propres dashboards ou documents internes.

Plan d'action recommandé pour les équipes infra

Cartographier l'existant
- Quels résolveurs sont utilisés (internes, externes) ?
- Quels transports sont déjà en production (UDP/TCP 53, DoT, DoH, tunnels VPN, etc.) ?
Définir une cible claire
- DoT en socle obligatoire entre postes et résolveurs internes.
- DoH3 et/ou DoQ activés de manière contrôlée, selon les cas d'usage (mobilité, performance, contraintes applicatives).
Mettre à jour les résolveurs
- Activer DoT en priorité, avec certificats correctement gérés.
- Évaluer DoQ sur un environnement pilote (latence, stabilité, observabilité).
Ajuster le filtrage réseau
- Formaliser une politique sur les flux DNS chiffrés sortants.
- Documenter les exceptions (ex. relais DNS d'un partenaire, site distant, agent de sécurité).
Mettre en place l'observabilité
- Centraliser les logs DNS au niveau des résolveurs.
- Suivre les volumes et la latence par transport (UDP, DoT, DoH3, DoQ).
Communiquer avec les équipes applicatives
- Expliquer les changements (nouveaux ports, nouveaux résolveurs, comportements possibles des navigateurs).
- Documenter les bonnes pratiques pour le choix des résolveurs dans les applications.
Tester régulièrement
- Scripts ou jobs de monitoring qui testent la résolution via chaque transport (UDP, DoT, DoH3, DoQ) vers vos résolveurs clés.
- Analyse des écarts de latence et de comportement (timeouts, échecs sporadiques).

FAQ

Dois-je tout migrer en DoQ et abandonner DoT ?

Non. DoQ n'est pas un remplacement brutal de DoT, mais une option supplémentaire. En pratique, la plupart des architectures vont rester multi-transports : UDP/TCP 53 pour la compatibilité, DoT comme socle chiffré, DoH3 et/ou DoQ pour des périmètres ciblés (mobilité, performance, contraintes applicatives).

DoH3 et DoQ sont-ils plus sécurisés que DoT ?

Sur le plan cryptographique, les trois approches reposent sur des primitives similaires (TLS ou QUIC au-dessus de TLS) et offrent un niveau de confidentialité comparable. Les différences se situent davantage au niveau du transport : multiplexage, gestion des pertes, masquage dans le trafic web, capacité à traverser ou non certains middleboxes.

Quels ports dois-je ouvrir sur mes pare-feux pour ces protocoles ?

De manière générale : DoT utilise 853/TCP, DoQ 853/UDP, DoH/DoH3 le port 443 (TCP et/ou UDP selon HTTP/2 ou HTTP/3). La politique d'ouverture doit être réfléchie : autoriser systématiquement ces ports vers Internet revient à laisser les postes contourner vos résolveurs internes.

Le DNS chiffré casse-t-il mon filtrage DNS existant ?

Il peut le contourner si des postes clients parlent directement à des résolveurs publics en DoH3/DoT/DoQ. C'est pourquoi il est crucial de définir une politique claire : quels flux DNS chiffrés sont autorisés, lesquels doivent obligatoirement passer par un résolveur d'entreprise, et comment détecter les écarts.

Comment tester si mon résolveur supporte DoT, DoH3 ou DoQ ?

En général, chaque implémentation documente des commandes d'exemple (via kdig, drill, curl pour DoH, ou des clients spécifiques DoQ). Vous pouvez intégrer ces tests dans vos procédures de validation et vos scripts de supervision pour vous assurer que chaque transport fonctionne comme attendu.