Ce que votre résolveur DNS sait de vous

Il existe une couche du réseau dont presque personne ne parle et que tout le monde traverse des milliers de fois par jour. Elle précède le chiffrement, elle précède l'authentification, elle précède la connexion elle-même. C'est le DNS.

Le raisonnement courant est le suivant : « mes connexions sont en HTTPS, donc mon activité est protégée. » C'est vrai du contenu. Ça ne l'est pas du fait de la connexion. Et dans beaucoup de situations, le fait suffit.

Le mécanisme

Quand vous ouvrez une page, votre appareil ne sait pas où joindre le serveur. Il connaît un nom, pas une adresse. Il pose donc une question à un résolveur DNS : quelle est l'adresse de ce nom ?

Cette question part en clair, en UDP, sur le port 53. Elle contient le nom demandé. Elle est visible de tout équipement situé sur le chemin : le point d'accès Wi-Fi, le fournisseur d'accès, l'opérateur de transit, et le résolveur lui-même.

Le résolveur, par défaut, est celui que votre box a annoncé, c'est-à-dire celui de votre fournisseur d'accès. Vous ne l'avez pas choisi. Dans la plupart des cas, vous ne savez pas lequel c'est.

Ce que cette question révèle

L'objection est connue : « ce n'est qu'un nom de domaine, pas une URL. » C'est exact, et c'est insuffisant.

Un nom de domaine n'est pas une donnée neutre. Certains noms sont des déclarations en soi :

• un domaine d'application de rencontre, de santé mentale, de traitement médical, de syndicat, de culte ;
• le domaine d'un cabinet d'avocats spécialisé, celui d'un service d'aide aux victimes, celui d'un employeur concurrent ;
• les domaines de mise à jour d'un logiciel, qui donnent l'inventaire de votre parc, et donc la liste des vulnérabilités applicables.

Et la séquence en dit encore plus que les noms pris isolément. L'ordre et l'horaire des requêtes dessinent un rythme de vie : l'heure du réveil, le trajet, l'employeur, les pauses, l'heure du coucher. Ce n'est pas une inférence théorique, c'est la matière première ordinaire du profilage.

Enfin, la résolution DNS est un signal de présence. Elle indique qu'un appareil donné était actif à un instant donné sur un réseau donné. Pour quiconque cherche à corréler, c'est plus utile que le contenu.

L'aggravation discrète : EDNS Client Subnet

Une extension du protocole, EDNS Client Subnet, permet au résolveur de transmettre au serveur interrogé une partie de l'adresse IP du client, pour qu'il réponde avec un serveur géographiquement proche.

L'intention est légitime : optimiser l'acheminement. La conséquence l'est moins. Elle signifie que votre localisation approximative est transmise non seulement à votre résolveur, mais à chaque service que vous interrogez, y compris ceux dont vous ignorez l'existence, parce qu'ils sont appelés par une page que vous consultez.

Beaucoup de résolveurs publics l'activent. Peu le mentionnent.

Le chiffrement ne suffit pas, et le filtrage non plus

Deux réponses partielles circulent, souvent présentées comme suffisantes.

Chiffrer le transport (DNS over TLS, DNS over HTTPS, DNS over QUIC) résout un problème réel : le fournisseur d'accès et le point d'accès ne voient plus les noms demandés. Mais cela ne fait que déplacer la confiance. Le résolveur chiffré, lui, voit tout. Un service gratuit, financé par la publicité, qui vous propose de chiffrer vos requêtes DNS, vous propose surtout de les lui confier plutôt qu'à votre opérateur. Ce n'est pas nécessairement un mauvais échange, mais c'est un échange, et il faut le nommer.

Filtrer, c'est-à-dire bloquer publicité, traqueurs et domaines malveillants, réduit le nombre de tiers qui vous observent. C'est efficace. Mais un Pi-hole ou un AdGuard Home qui interroge en clair un résolveur amont a supprimé les traqueurs sans supprimer l'observation : la liste de ce que vous consultez part toujours en clair.

Les deux ensemble règlent le problème. Séparément, chacun laisse l'autre moitié ouverte.

Ce que ça implique concrètement

Un résolveur digne de confiance doit tenir quatre engagements vérifiables, pas déclaratifs.

Ne rien journaliser. Pas de « conservation limitée à 24 heures », pas de « journaux anonymisés » : rien. Une requête qui n'est jamais écrite n'est ni saisissable, ni divulgable, ni revendable. C'est une propriété de configuration, pas une promesse commerciale.

Ne pas émettre d'ECS. Votre localisation ne doit pas être transmise aux services que vous interrogez.

Valider DNSSEC. Une réponse falsifiée doit être rejetée, pas relayée. Sans validation, un résolveur qui chiffre le transport vous protège de l'observation, pas de la manipulation.

Rendre le filtrage auditable. Un résolveur qui filtre décide à votre place de ce qui est joignable. C'est un pouvoir. Il doit être exercé sous condition de transparence : quelles listes, de quelle source, avec quelle date, et selon quelle procédure de contestation. Un blocage subi et un blocage éditorial ne doivent pas être mélangés : sinon plus personne, y compris l'opérateur, ne sait plus pourquoi un domaine est bloqué.

Un cas concret

C'est ce raisonnement qui a produit Torii, un résolveur public que j'exploite sur dns.cybsec.fr.

Quelques partis pris, et ce qu'ils coûtent :

Le port 53 en clair est fermé. Pas filtré, pas restreint : fermé. Un résolveur ouvert en clair est un amplificateur d'attaque par réflexion, et une requête en clair annule l'intérêt de la démarche. La contrepartie est réelle et il faut l'assumer : les appareils anciens et la plupart des box internet ne savent pas parler chiffré, et ne peuvent donc pas s'en servir directement.

Trois zones de filtrage séparées, jamais fusionnées. Les blocages imposés, les blocages éditoriaux, les blocages parentaux vivent dans trois fichiers distincts. Un domaine bloqué reste attribuable à sa raison. La séparation est la doctrine, pas un détail d'implémentation.

Une liste d'autorisation qui ne peut pas être contournée. Environ 150 domaines (services publics, banques, chaînes d'authentification et de paiement 3-D Secure, mises à jour système, révocation de certificats, NTP) sont protégés dans le compilateur lui-même, pas dans un fichier de configuration qu'une erreur pourrait vider.

Ce dernier point n'est pas théorique. Une des listes publiques que j'utilise bloque gvt2.com. C'est le canal par lequel Chrome met à jour sa liste de certificats révoqués. Bloqué, la révocation de certificats cesse d'être mise à jour, silencieusement, indéfiniment. Personne ne s'en aperçoit, et c'est exactement le genre de dégât qu'un filtrage DNS mal tenu produit.

Ce que ça donne en fonctionnement

Quelques mesures relevées sur le nœud, à titre d'ordre de grandeur :

Les 23 % méritent un commentaire. Ce n'est pas un score de performance : c'est la proportion de requêtes qu'un appareil ordinaire émet vers des domaines de publicité et de mesure d'audience, sans que son utilisateur l'ait demandé. Près d'une requête sur quatre.

Ce qu'il faut en retenir

Le DNS est la couche la plus bavarde et la moins regardée de votre infrastructure. Elle précède tout le reste, et elle échappe à la protection que vous croyez avoir.

Trois questions, dans cet ordre :

1. Quel résolveur utilisent réellement vos appareils ? Pas celui que vous avez configuré : celui qu'ils utilisent. Sur un poste avec un VPN d'entreprise ou un client de réseau maillé, ce n'est presque jamais le même.
2. Ce résolveur chiffre-t-il, et que fait-il de vos requêtes ? Si la réponse à la seconde partie n'est pas publiquement documentée, elle est défavorable.
3. Le filtrage, s'il existe, est-il auditable ? Un filtrage opaque n'est pas une protection : c'est une dépendance de plus.

C'est peu de travail. C'est la couche la plus facile à corriger, et c'est celle qu'on corrige en dernier.