DoT, DoH, DNSCrypt, DNSSEC : qui fait quoi sous Linux ?

Quand on commence à vouloir sortir du DNS de son fournisseur d’accès, on tombe rapidement sur quatre acronymes :

• DoT : DNS over TLS ;
• DoH : DNS over HTTPS ;
• DNSCrypt : un autre protocole de DNS chiffré ;
• DNSSEC : vérification cryptographique de certaines réponses DNS.

Ils ne font pas tous la même chose et, surtout, ils ne se remplacent pas les uns les autres.

DNS classique

Le DNS traditionnel utilise généralement le port 53 en clair.

Concrètement, votre machine demande :

quelle est l'adresse IP de exemple.com ?

et le résolveur lui répond.

Le problème : les requêtes sont visibles sur le réseau. Selon le fournisseur d’accès ou le pays, elles peuvent également être filtrées, modifiées ou redirigées.

Changer simplement le DNS de sa box pour mettre un autre résolveur évite éventuellement d’utiliser le résolveur du FAI, mais le trafic DNS reste en clair.

DoT : DNS over TLS

DoT chiffre les requêtes DNS dans une connexion TLS, généralement sur le port 853.

Dans le montage que j’utilise :

applications
    ↓
Pi-hole
    ↓
Unbound
    ↓
DoT
    ↓
résolveurs DNS externes

Avantages :

• les requêtes DNS ne circulent plus en clair entre votre machine et le résolveur final ;
• le protocole est simple et dédié au DNS ;
• Unbound sait très bien fonctionner comme relais DoT.

Inconvénient :

• le trafic est facilement identifiable comme du DNS chiffré, puisque le port 853 lui est dédié.

Tutoriel complet :

Installer Pi-hole et Unbound avec Docker

DoH : DNS over HTTPS

DoH transporte les requêtes DNS dans une connexion HTTPS.

Dans mon second montage :

applications
    ↓
Pi-hole
    ↓
dnscrypt-proxy
    ↓
DoH / DNSCrypt
    ↓
résolveurs DNS externes

Le trafic passe alors dans du HTTPS, comme beaucoup d’autres échanges web.

Cela le rend généralement moins trivial à bloquer qu’un protocole DNS utilisant un port dédié.

J’utilise dnscrypt-proxy, qui permet de travailler avec plusieurs résolveurs et de mélanger selon la configuration :

• DoH ;
• DNSCrypt.

Le but n’est pas d’être marié à un seul protocole ou à un seul opérateur DNS. Le but est d’avoir plusieurs chemins de résolution chiffrés et de ne plus dépendre du DNS du fournisseur d’accès.

Tutoriel complet :

Installer Pi-hole avec DoH / DNSCrypt et dnscrypt-proxy sous Docker

DNSCrypt

DNSCrypt est un autre protocole permettant de chiffrer et d’authentifier les échanges avec un résolveur DNS compatible.

Il ne passe pas nécessairement par HTTPS comme DoH.

Dans ma configuration, il est utilisé via dnscrypt-proxy en complément de DoH.

L’intérêt est surtout la résilience : si plusieurs protocoles et plusieurs résolveurs sont disponibles, une panne ou un blocage sur un chemin ne condamne pas toute la résolution DNS.

Et DNSSEC dans tout ça ?

DNSSEC ne chiffre pas les requêtes DNS.

C’est important parce qu’on voit souvent les deux sujets mélangés.

DNSSEC sert à vérifier cryptographiquement qu’une réponse DNS signée n’a pas été falsifiée entre la zone DNS et le résolveur qui la valide.

En résumé :

DoT / DoH / DNSCrypt
→ protègent le transport des requêtes DNS

DNSSEC
→ vérifie l'authenticité des réponses pour les domaines qui l'utilisent

DNSSEC ne remplace donc ni DoT ni DoH.

Et DoT ou DoH ne remplacent pas non plus DNSSEC.

Les deux protections peuvent être complémentaires.

Pourquoi garder plusieurs modes ?

Parce qu’un système DNS qui ne fonctionne que tant qu’un seul composant est disponible est un système fragile.

J’utilise donc plusieurs possibilités :

• Pi-hole + Unbound en DoT ;
• Pi-hole + dnscrypt-proxy en DoH / DNSCrypt ;
• un fallback DNS neutre en cas de panne des stacks locales ;
• un fallback filtrant externe si je veux conserver temporairement un minimum de filtrage.

Un petit switcher permet de passer d’un mode à l’autre sans démonter toute la configuration.

Basculer facilement entre DoT, DoH, fallback neutre et fallback filtrant

Attention au fallback DNS classique

Utiliser directement un résolveur public sur le port 53 permet de ne plus demander les réponses au résolveur du FAI.

Mais cela ne chiffre pas le trafic.

Le fournisseur d’accès peut toujours voir les requêtes DNS qui transitent en clair.

Dans mon installation, ce mode est donc uniquement un secours manuel :

stack DNS chiffrée fonctionnelle
→ utilisation normale

stack locale cassée
→ fallback temporaire

stack réparée
→ retour au DNS chiffré

Pas de cron qui réécrit automatiquement /etc/resolv.conf toutes les cinq minutes. Ce genre de bricolage finit surtout par se battre avec NetworkManager, systemd-resolved, Tailscale ou un autre gestionnaire réseau.

Vérifier ce qu’on utilise réellement

Pour voir quel serveur DNS répond réellement :

dig kernel.org A | grep SERVER

Pour tester directement un DNS local :

dig @127.0.0.1 kernel.org A +short

Pour voir ce que contient la configuration DNS système :

cat /etc/resolv.conf

Et pour regarder les résolveurs visibles depuis Internet :

https://www.dnsleaktest.com

Attention toutefois : un test de fuite DNS indique quels résolveurs ont traité vos requêtes. Il ne suffit pas, à lui seul, à expliquer toute la chaîne DNS locale.

En résumé

DNS classique
→ simple, mais en clair

DoT
→ DNS chiffré sur TLS, généralement port 853

DoH
→ DNS transporté dans HTTPS

DNSCrypt
→ protocole DNS chiffré supplémentaire

DNSSEC
→ authentification des réponses signées, pas chiffrement

Pour mon usage, je ne cherche pas un protocole magique.

Je préfère avoir deux stacks réellement différentes, les tester, et pouvoir basculer de l’une à l’autre quand un chemin tombe :

Pi-hole + Unbound
→ DoT

Pi-hole + dnscrypt-proxy
→ DoH / DNSCrypt

Le reste est une question de résilience, de choix des résolveurs et de contrôle réel de la configuration utilisée par le système.