DNS over HTTPS : fonctionnement, activation et compatibilité avec les proxies

DNS over HTTPS chiffre les requêtes et les réponses DNS échangées entre votre client et un résolveur DNS grâce à HTTPS. Il protège cette connexion, mais il ne rend pas la navigation anonyme et ne masque pas les requêtes au résolveur.

La vraie question pratique est de savoir où la résolution a lieu, qui peut l’observer et ce qui se passe lorsque le chiffrement échoue. Notre petit échantillon Linux apporte des éléments concrets sur le comportement des points de terminaison et sur la compatibilité avec les proxies.

Points clés

• DoH chiffre les échanges DNS entre un client et son résolveur HTTPS.
• Le résolveur choisi peut toujours lire les questions DNS auxquelles il répond.
• DNSSEC authentifie les données DNS ; il ne chiffre pas les requêtes.
• La connexion HTTPS d’un site web ne prouve pas que sa résolution DNS a été chiffrée.
• Notre échantillon de dix requêtes curl a obtenu des réponses pour les dix requêtes.
• Les 48 requêtes DoH passées par proxy dans notre échantillon Python ont toutes obtenu une réponse.

Qu’est-ce que DNS over HTTPS et comment fonctionne-t-il ?

DoH transporte les messages DNS à l’intérieur d’échanges HTTPS. La RFC 8484 définit le protocole entre un client DNS et un résolveur HTTPS.

Le chemin est le suivant : le navigateur ou le client, puis le résolveur HTTPS, puis l’infrastructure DNS selon les besoins. La connexion chiffrée s’arrête au résolveur ; elle ne chiffre pas automatiquement tous les échanges DNS suivants.

Le format normalisé est un message DNS binaire. Les requêtes GET l’encodent dans un paramètre dns ; les requêtes POST le transportent dans le corps. Les interfaces JSON propres à chaque fournisseur sont pratiques pour les tests, mais elles ne sont pas interchangeables avec le modèle DoH d’un navigateur.

Un résolveur répond aux requêtes de noms. Un serveur proxy transmet le trafic. Gardez ces deux rôles distincts lorsque vous configurez l’un ou l’autre.

DNS over HTTPS masque-t-il votre navigation à votre FAI ?

DoH masque le contenu de cette connexion DNS aux observateurs passifs situés sur son chemin réseau. Il ne peut pas masquer toute l’activité de navigation.

Votre résolveur voit les questions ainsi que l’adresse source qui s’y connecte. Votre FAI peut toujours observer les adresses IP de destination et les schémas de trafic lorsque les connexions aux sites web passent directement. Les considérations sur la confidentialité de la RFC 8484 expliquent pourquoi un transport chiffré n’élimine pas la nécessité de faire confiance au résolveur.

Le Server Name Indication non chiffré peut également exposer un nom d’hôte pendant l’établissement de la session TLS. ECH protège le ClientHello interne, y compris ce nom d’hôte, lorsqu’il est négocié avec succès ; il ne dissimule pas les adresses IP de destination. Consultez l’explication de Mozilla sur ECH.

Quelles différences entre DoH, DoT, DNSSEC, les VPN et WARP ?

DoH et DoT protègent le transport DNS ; DNSSEC authentifie les données DNS. Un VPN modifie le chemin du trafic qui traverse son tunnel.

Les normes concernées sont la RFC 7858 pour DoT et la RFC 4033 pour DNSSEC. Ni DNSSEC ni DoH ne promettent une protection universelle contre les réponses malveillantes.

Les modes WARP documentés distinguent le chiffrement du DNS seul du tunnel pour le trafic et le DNS. Pour approfondir ces distinctions, consultez proxy ou VPN et Smart DNS, proxies et VPN.

DoQ est un autre transport DNS chiffré. La RFC 9250 fait correspondre DNS directement à QUIC ; il se distingue de DoH transporté sur HTTP/3.

Faut-il activer ou désactiver DoH ?

Activez DoH lorsque la politique de son résolveur et son comportement en cas d’échec conviennent à votre réseau. Veillez à ce que le DNS imposé par l’organisation, les noms locaux et le filtrage continuent de fonctionner.

Appliquez la vérification de confidentialité DNS en 3 étapes avant de modifier vos paramètres :

• Étape 1 : localiser la résolution. Déterminez si c’est le navigateur, le système d’exploitation ou le proxy qui résout la destination.
• Étape 2 : identifier les observateurs. Retracez le client, le résolveur HTTPS et l’infrastructure DNS ; incluez un proxy le cas échéant.
• Étape 3 : vérifier le repli. Contrôlez si un échec interrompt la résolution ou autorise un autre transport.

Quel fournisseur et quelle URL DoH choisir ?

Choisissez en fonction de la politique de confidentialité, des besoins de filtrage et de la compatibilité du client, avant de comparer les temps de réponse. Adaptez le format du point de terminaison à l’application.

Consultez la documentation DoH de Cloudflare et la documentation DoH de Google. Un champ de modèle et un champ de point de terminaison simple peuvent exiger une syntaxe différente ; ne collez pas d’URL de requête JSON dans l’un ou l’autre sans vérifier.

Comparez la politique de confidentialité du résolveur de Cloudflare avec la politique de confidentialité DNS de Google, exceptions de journalisation comprises. Traitez le blocage des logiciels malveillants et le contrôle parental comme des exigences distinctes : le chiffrement seul n’apporte ni l’un ni l’autre.

Comment activer DoH dans les navigateurs et les systèmes d’exploitation ?

Configurez le composant qui effectue réellement vos résolutions, puis vérifiez son état actif et son comportement de repli. Les paramètres du navigateur et ceux du système d’exploitation couvrent des chemins différents.

• Chrome : ouvrez Paramètres, Confidentialité et sécurité, Sécurité, puis Utiliser un DNS sécurisé. Vérifiez le choix du résolveur et le comportement de repli automatique dans les conseils de Chrome sur les paramètres de sécurité.
• Firefox : ouvrez Paramètres, Vie privée et sécurité, DNS over HTTPS, puis Paramètres avancés. Choisissez un niveau de protection et contrôlez son état. La protection par défaut peut se replier ; la protection maximale affiche un avertissement lorsque la résolution sécurisée échoue, avec une option d’exception. Suivez les instructions de Mozilla sur les niveaux de protection.
• Windows 11 : ouvrez la connexion active sous Réseau et Internet, puis modifiez ses paramètres DNS. Sélectionnez un modèle DoH automatique ou manuel et définissez délibérément le repli en clair. Consultez les instructions de Microsoft sur les paramètres réseau.
• Android : ne supposez pas que le DNS privé correspond à un champ d’URL DoH comme dans un navigateur. Les conseils de configuration Android de Google utilisent un nom d’hôte de fournisseur pour le DNS privé.

Microsoft documente également la différence entre exiger et demander une résolution chiffrée dans ses conseils sur le client DNS de Windows. Vérifiez à nouveau le fonctionnement après un changement de réseau ou l’activation d’un VPN.

DoH fonctionne-t-il avec les proxies ?

DoH peut passer par un proxy, mais cela ne détermine pas qui résout les noms d’hôte des sites web. Envoyer des requêtes HTTPS à un résolveur et déléguer la résolution de la destination sont deux opérations distinctes.

La documentation de Chromium sur les proxies décrit la résolution de la destination côté proxy pour les proxies HTTP et SOCKS5. Les heuristiques de Mozilla décrivent des cas où la détection d’un proxy empêche l’activation automatique de DoH ; sa politique DNSOverHTTPS contrôle séparément le repli. Ces comportements dépendent de la configuration.

Le manuel de curl distingue la résolution SOCKS5 locale de la résolution du nom d’hôte côté proxy et documente l’option --doh-url. Cette option n’oblige pas un proxy distant à utiliser le résolveur que vous avez choisi ; même la résolution initiale du serveur DoH passe par un chemin d’amorçage distinct.

Notre échantillon SOCKS a identifié le résolveur de l’hébergeur avec des requêtes directes et en socks5://. Avec socks5h://, deux exécutions ont signalé des résolveurs Google aux États-Unis ou au Canada. Les deux routes SOCKS utilisaient des adresses de sortie résidentielles. Consultez HTTP ou SOCKS5 pour le contexte des protocoles.

Oblivious DoH ajoute des messages DNS chiffrés et une architecture de relais distincte pour séparer l’identité du client de ses requêtes. Un simple passage par un proxy n’est pas automatiquement de l’ODoH.

Pour voir quel côté résout le DNS derrière un proxy SOCKS, notre test a utilisé ce court script. Avec socks5://, la résolution est restée sur le résolveur de notre serveur ; avec socks5h://, elle est passée côté proxy.

"""Who resolves the hostname: socks5:// (your machine) or socks5h:// (the proxy)?

pip install "requests[socks]"
edns.ip-api.com answers with the DNS resolver that looked up its hostname.
"""
import os
import requests

SOCKS = os.environ.get("SOCKS_URL")  # e.g. socks5://USER__cr.us:[email protected]:824
host_part = SOCKS.split("://", 1)[1]

routes = {
    "direct": None,
    "socks5 (local DNS)": "socks5://" + host_part,
    "socks5h (proxy DNS)": "socks5h://" + host_part,
}
for label, proxy in routes.items():
    proxies = {"http": proxy, "https": proxy} if proxy else None
    try:
        dns = requests.get("http://edns.ip-api.com/json", proxies=proxies, timeout=20).json()["dns"]
        print(f"{label:20} resolver: {dns['geo']}")
    except requests.RequestException as exc:
        print(f"{label:20} failed: {type(exc).__name__}")

Comment tester le bon fonctionnement de DoH ?

Vérifiez séparément l’accessibilité du point de terminaison, les réponses DNS et le routage de l’application. Une requête HTTPS réussie ne suffit pas à établir la configuration du navigateur ni l’anonymat.

Lors de notre test rapide du 19 octobre 2026, un serveur Linux européen sous Ubuntu 24.04 a utilisé curl 8.5.0 et Python 3.12 avec httpx 0.28 et HTTP/2. Il s’agissait d’un petit échantillon, pas d’un benchmark : environ 130 requêtes DoH auprès de trois fournisseurs, espacées d’une seconde.

À 12:50 UTC, curl a envoyé cinq requêtes A séquentielles pour example.com par point de terminaison JSON, en ouvrant à chaque fois une connexion à froid. Les requêtes suivaient la syntaxe JSON de Google et la syntaxe JSON de Cloudflare.

Les points de terminaison étaient https://dns.google/resolve?name=example.com&type=A et https://cloudflare-dns.com/dns-query?name=example.com&type=A, ce dernier avec accept: application/dns-json. Il s’agit de durées de requêtes HTTPS, établissement de la connexion inclus, et non de la latence DNS isolée.

La mesure en Python a porté sur quatre domaines, trois exécutions par méthode et un client HTTP/2 réutilisable par exécution. Les résultats ci-dessous sont des médianes de médianes par domaine. Sources : doh_check.py, doh_results_direct.json et doh_results_proxy.json.

Chaque méthode DoH a obtenu des réponses pour 12/12 requêtes par route, dont les 48 passées par le proxy HTTP résidentiel DataImpulse. Le 1 ms du résolveur système reflète le cache local, pas une résolution réseau. La médiane d’un domaine Cloudflare JSON passé par proxy a atteint 1,4 seconde.

Les tentatives Quad9 JSON ont expiré ou renvoyé HTTP 400. Une tentative wire en HTTP/1.1 a renvoyé HTTP 505 ; HTTP/2 a fonctionné. Ce sont des résultats observés, pas des exigences universelles du protocole. Les réponses pour Wikipedia ont aussi varié entre les requêtes directes et celles passées par proxy, mais l’échantillon ne permet pas d’isoler la localisation, le routage du résolveur ou le cache comme cause.

Pour une vérification indépendante, utilisez des noms de test inoffensifs, examinez l’état de l’application et les diagnostics réseau, et testez le comportement en cas d’échec sur un réseau que vous administrez. Conservez les réponses brutes à part : les fichiers de résultats Python résument les exécutions et ne retiennent que les champs de la dernière réponse, pas chaque corps de réponse. Son compteur de succès mesure les appels sans exception ; inspectez donc aussi le statut HTTP, le statut DNS et les réponses.

Le script ci-dessous est celui de notre test rapide du 19 octobre 2026. Il envoie les mêmes requêtes à Cloudflare, Google et Quad9 via DoH (formats JSON et wire) ainsi qu’au résolveur système, directement et, si PROXY_URL est défini, via un proxy HTTP, puis affiche la latence médiane par point de terminaison. Il nécessite pip install httpx[http2] : Quad9 ne répond qu’en HTTP/2.

"""Resolve a few domains over DNS-over-HTTPS and over the system resolver.

pip install "httpx[http2]"   # Quad9 requires HTTP/2 for DoH (RFC 8484, section 5.2)
Optional: PROXY_URL to send the DoH requests through an HTTP proxy (DoH is plain HTTPS).
"""
import base64, json, os, socket, statistics, struct, time
import httpx

PROXY = os.environ.get("PROXY_URL")  # e.g. http://USER__cr.us:[email protected]:823
CLIENT = httpx.Client(http2=True, proxy=PROXY, timeout=10)  # one client = warm HTTPS connections
DOMAINS = ["example.com", "wikipedia.org", "github.com", "dataimpulse.com"]
RUNS = 3

JSON_ENDPOINTS = {
    "cloudflare-json": ("https://cloudflare-dns.com/dns-query", {"accept": "application/dns-json"}),
    "google-json": ("https://dns.google/resolve", {}),
}
WIRE_ENDPOINTS = {  # RFC 8484: binary DNS message, base64url in ?dns=
    "cloudflare-wire": "https://cloudflare-dns.com/dns-query",
    "quad9-wire": "https://dns.quad9.net/dns-query",
}


def json_query(url, headers, name):
    r = CLIENT.get(url, params={"name": name, "type": "A"}, headers=headers)
    data = r.json()
    ips = [a["data"] for a in data.get("Answer", []) if a.get("type") == 1]
    return r.status_code, data.get("Status"), ips, len(r.content)


def build_wire_query(name):
    header = struct.pack(">HHHHHH", 0, 0x0100, 1, 0, 0, 0)  # id 0, recursion desired, 1 question
    qname = b"".join(bytes([len(p)]) + p.encode() for p in name.split(".")) + b"\0"
    return header + qname + struct.pack(">HH", 1, 1)  # type A, class IN


def wire_query(url, name):
    q = base64.urlsafe_b64encode(build_wire_query(name)).rstrip(b"=").decode()
    r = CLIENT.get(url, params={"dns": q}, headers={"accept": "application/dns-message"})
    if r.headers.get("content-type") != "application/dns-message":
        raise ValueError(f"HTTP {r.status_code}, not a DNS message")
    flags, ancount = struct.unpack(">H", r.content[2:4])[0], struct.unpack(">H", r.content[6:8])[0]
    rcode = flags & 0x000F  # 0 = NOERROR; ancount includes CNAMEs, enough for a smoke test
    return r.status_code, rcode, [f"{ancount} answer records"], len(r.content)


def system_query(name):
    infos = socket.getaddrinfo(name, 443, socket.AF_INET, socket.SOCK_STREAM)
    return None, 0, sorted({i[4][0] for i in infos}), 0


def timed(fn, *args):
    start = time.perf_counter()
    try:
        status, rcode, answers, size = fn(*args)
        error = ""
    except Exception as exc:
        status, rcode, answers, size, error = None, None, [], 0, type(exc).__name__
    return (time.perf_counter() - start) * 1000, status, rcode, answers, size, error


def main():
    rows = []
    for name in DOMAINS:
        methods = {"system": (system_query, name)}
        methods.update({k: (json_query, u, h, name) for k, (u, h) in JSON_ENDPOINTS.items()})
        methods.update({k: (wire_query, u, name) for k, u in WIRE_ENDPOINTS.items()})
        for method, (fn, *args) in methods.items():
            results = []
            for _ in range(RUNS):
                results.append(timed(fn, *args))
                time.sleep(1)
            ok = [r for r in results if not r[5]]
            rows.append({
                "domain": name, "method": method, "route": "proxy" if PROXY and method != "system" else "direct",
                "ok": f"{len(ok)}/{RUNS}",
                "median_ms": round(statistics.median(r[0] for r in ok)) if ok else None,
                "http_status": results[-1][1], "dns_rcode": results[-1][2],
                "answers": results[-1][3], "bytes": results[-1][4], "error": results[-1][5],
            })
            print(f"{name:16} {method:16} {rows[-1]['ok']}  {rows[-1]['median_ms']} ms  {rows[-1]['answers']}")
    out = "doh_results_proxy.json" if PROXY else "doh_results_direct.json"
    with open(out, "w") as f:
        json.dump(rows, f, indent=1)
    print("saved", out)


if __name__ == "__main__":
    main()
Run: pip install "httpx[http2]"; python3 doh_check.py   (through a proxy: PROXY_URL="http://USER__cr.us:[email protected]:823" python3 doh_check.py)

Pourquoi DoH échoue-t-il ou entre-t-il en conflit avec les contrôles réseau ?

Un DNS externe peut entrer en conflit avec le split DNS, le contrôle parental, les portails captifs ou le routage d’un VPN. Un chiffrement strict peut transformer l’indisponibilité du résolveur en échecs de résolution.

Identifiez d’abord la couche en cause : syntaxe du point de terminaison, connexion TLS, réponse HTTP, réponse DNS ou politique applicative. Testez à la fois des noms publics et les noms internes nécessaires. Mozilla documente les compromis entre filtrage et politiques d’entreprise.

Pour une administration autorisée, privilégiez des politiques de navigateur explicites et une configuration de résolveur approuvée. Bloquer uniquement les ports DNS traditionnels ne couvre pas la résolution via HTTPS. Évitez un blocage HTTPS large qui perturbe des applications sans rapport, et limitez les journaux de diagnostic au trafic de test.

Foire aux questions

Vérifiez le routage DNS en même temps que votre configuration de proxy

Si vous utilisez DataImpulse, vérifiez à la fois la sortie du trafic et le chemin DNS avec un petit test. DataImpulse est un fournisseur de proxies, pas un résolveur DoH, un VPN, une API de scraping ni un service de déblocage géré. Commencez par la comparaison HTTP et SOCKS5 pour choisir le bon modèle de connexion.

Dernière mise à jour : 19 octobre 2026.