Diagnostiquer le détournement DNS par les FAI lorsque les résolveurs standards échouent

Karthikey Hegde a découvert que son conteneur Podman ne pouvait pas atteindre un site web spécifique, malgré les étapes de dépannage standard. Les requêtes envoyées aux grands résolveurs publics comme Google et Cloudflare retournaient toutes une adresse IP appartenant à son fournisseur d'accès Internet (FAI), tandis que le DNS chiffré révélait la destination correcte. Cet incident met en évidence une faille critique pour les auto-hébergeurs : modifier les paramètres du serveur DNS n'offre souvent aucune protection si votre FAI intercepte le trafic sur le port 53.

Ce qui s'est passé

L'enquête de Hegde a commencé lorsqu'un service dans son environnement local n'a pas réussi à résoudre un nom de domaine. Il a testé plusieurs résolveurs DNS publics, notamment 1.1.1.1, 8.8.8.8 et 9.9.9.9. Surprenamment, chaque requête en texte clair retournait la même adresse IP, dont une recherche WHOIS a confirmé qu'elle appartenait à son FAI. Lorsqu'il a utilisé le point de terminaison DNS over HTTPS (DoH) de Cloudflare, la requête a renvoyé l'adresse IP légitime du site cible. Cette divergence a prouvé que son FAI interceptait activement et réécrivait les paquets DNS UDP sur le port 53, indépendamment de l'adresse du résolveur spécifiée.

Ce comportement rend inefficaces les conseils courants. Demander aux utilisateurs de passer à 1.1.1.1 ou 8.8.8.8 suppose que le FAI transmettra fidèlement ces paquets. En réalité, le trafic UDP non authentifié sur le port 53 peut être intercepté par tout équipement réseau situé sur le chemin. Comme noté dans les discussions techniques entourant cet incident, l'interception DNS via UDP est triviale pour les opérateurs réseau. L'équipement du FAI capture simplement le paquet et répond avec une réponse falsifiée, donnant l'impression que le résolveur demandé a fourni des données incorrectes.

Détails clés

• Les requêtes DNS en texte clair sur le port 53 manquent d'authentification, permettant aux FAI d'intercepter et de réécrire facilement les réponses.
• Le fait que plusieurs résolveurs publics retournent la même adresse IP incorrecte suggère un point d'interception unique, et non des erreurs indépendantes des résolveurs.
• DNS over HTTPS (DoH) et DNS over TLS (DoT) chiffrent les requêtes, empêchant leur modification en transit par les réseaux intermédiaires.
• Une divergence entre les résultats DNS en texte clair et chiffrés nécessite une vérification via WHOIS pour distinguer la manipulation de la géolocalisation CDN.
• Seuls environ 7,1 % des domaines évalués étaient signés et validés par DNSSEC en novembre 2026, limitant la couverture de détection.
• Les résolveurs récursifs auto-hébergés comme Unbound sont également vulnérables s'ils transmettent les requêtes via UDP en texte clair sur le port 53.

Contexte

La résolution DNS repose traditionnellement sur le port UDP 53, un protocole conçu pour la rapidité plutôt que pour la sécurité. Il ne vérifie ni l'identité du répondant ni l'intégrité des données. Lorsque vous configurez un appareil pour utiliser un serveur DNS spécifique, votre système d'exploitation envoie une requête à cette adresse IP. Cependant, sans chiffrement, tout routeur ou pare-feu situé entre votre appareil et le résolveur prévu peut lire la requête et injecter une fausse réponse. C'est ce qu'on appelle le détournement ou l'usurpation DNS.

Les protocoles DNS chiffrés comme DoH et DoT enveloppent ces requêtes dans TLS, similaire à la façon dont HTTPS sécurise la navigation web. Cela empêche les opérateurs réseau de voir ou d'altérer le contenu de la requête. Toutefois, l'adoption n'est pas universelle. De nombreuses configurations auto-hébergées reposent encore sur la transmission en texte clair pour des raisons de simplicité ou de compatibilité. De plus, DNSSEC ajoute une couche de validation cryptographique pour garantir l'intégrité des données, mais il exige que le propriétaire du domaine signe les enregistrements et que le résolveur les valide. Avec seulement une petite fraction des domaines supportant DNSSEC, cela reste une protection incomplète contre le détournement.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés, une résolution DNS fiable est fondamentale. Si votre FAI détourne le DNS, vos services internes peuvent échouer à se connecter aux API externes, aux dépôts de paquets ou aux serveurs de mise à jour. Plus critique encore, vous pourriez être dirigé vers des serveurs malveillants contrôlés par l'intercepteur. Bien que les FAI affirment souvent que cela sert au filtrage ou à la mise en cache, le manque de transparence signifie que vous ne pouvez pas faire confiance au routage. Les outils de surveillance standard peuvent signaler les services comme "hors ligne" alors qu'ils sont simplement injoignables en raison d'une résolution DNS incorrecte, entraînant une perte de temps lors du dépannage.

De plus, compter sur des résolveurs publics sans chiffrement donne un faux sentiment de sécurité. Les administrateurs système supposent souvent que diriger leur pare-feu ou routeur vers 1.1.1.1 sécurise leur trafic DNS. Cet incident prouve que cette hypothèse est erronée. Si votre FAI est assez agressif pour intercepter le trafic du port 53 globalement, votre choix de résolveur amont est irrelevant sauf si vous imposez le chiffrement à la périphérie de votre réseau. Cela affecte tout, de l'orchestration de conteneurs aux simples tâches cron qui récupèrent des données externes.

Que pouvez-vous faire

• Testez le détournement en comparant les résultats dig en texte clair avec un point de terminaison DoH comme celui de Cloudflare pour un domaine défaillant.
• Vérifiez la propriété des adresses IP suspectes en utilisant des recherches WHOIS pour confirmer si elles appartiennent à votre FAI.
• Implémentez DNS over HTTPS ou DNS over TLS sur votre résolveur local, par exemple en configurant AdGuard Home avec dnscrypt-proxy.
• Évitez d'utiliser le port 5353 pour les proxys DNS chiffrés afin de prévenir les conflits avec les services mDNS comme Avahi.
• Configurez Unbound pour transmettre les requêtes via TLS en spécifiant forward-tls-upstream: yes et en fournissant un bundle CA.
• Utilisez des outils comme OONI pour effectuer des mesures indépendantes si vous soupçonnez une interférence réseau plus large au-delà du DNS.