Quel est mon DNS

Qu'est-ce que le DNS, réellement ?

Le DNS (Domain Name System) est l'annuaire téléphonique de l'internet qui traduit des noms d'hôte lisibles par l'homme comme example.com en adresses IP auxquelles les logiciels peuvent se connecter. Il a été défini dans la RFC 1034 et la RFC 1035 en 1987. Le protocole de base est resté inchangé, bien que l'écosystème qui l'entoure ait considérablement évolué.

La chaîne de recherche fait intervenir trois acteurs. Un serveur de noms faisant autorité (authoritative name server) détient les données de zone réelles d'un domaine, définies par l'administrateur du domaine. Un résolveur récursif (recursive resolver) (aussi appelé résolveur complet) interroge les serveurs faisant autorité en votre nom, met en cache les réponses et renvoie les résultats aux clients. Un résolveur stub (stub resolver) est le minuscule client DNS intégré à votre système d'exploitation ; il se contente de relayer les requêtes vers un résolveur récursif. Lorsque vous saisissez une URL, votre résolveur stub interroge votre résolveur récursif configuré. Celui-ci renvoie la réponse s'il l'a en cache, ou parcourt l'arborescence DNS à partir des serveurs racines jusqu'à trouver le serveur faisant autorité pour ce domaine.

Les types d'enregistrements les plus courants sont :

• A associe un nom à une adresse IPv4. La plupart des sites web en publient au moins un.
• AAAA associe un nom à une adresse IPv6. Publié aux côtés des enregistrements A sur les sites en double pile.
• CNAMEest un alias pointant un nom vers un autre. Il ne peut pas coexister avec d'autres enregistrements à la racine de la zone (le domaine nu comme example.com), c'est pourquoi les CDN utilisent des extensions propriétaires ALIAS ou ANAME pour les domaines racines.
• MXspécifie les serveurs de messagerie responsables d'un domaine, avec des valeurs de priorité pour gérer l'ordre de secours.
• TXTcontient du texte arbitraire, le plus souvent des enregistrements SPF pour l'authentification des e-mails, des clés publiques DKIM et des preuves de propriété de domaine pour des services comme Google Search Console.

Chaque enregistrement possède un TTL (Time To Live) en secondes. Les résolveurs récursifs conservent la réponse en cache pendant cette durée avant d'en récupérer une nouvelle. Un TTL de 300 signifie que les résolveurs se mettent à jour toutes les 5 minutes ; un TTL de 86400 signifie une fois par jour. C'est pourquoi la "propagation DNS" prend du temps après une modification : chaque résolveur sur internet ayant mis en cache l'ancien enregistrement doit attendre l'expiration de son TTL avant de voir le nouveau. Abaisser votre TTL à 300 avant une migration planifiée et le remonter ensuite est une pratique courante.

Comment cette page détecte votre résolveur DNS

Cet outil ne détecte pas directement votre résolveur configuré. À la place, il envoie une requête DNS depuis votre navigateur à l'API DoH de Cloudflare à l'adresse cloudflare-dns.com/dns-query au format application/dns-json et affiche les enregistrements A et AAAA renvoyés par Cloudflare pour le nom d'hôte que vous avez saisi. Le résultat vous indique ce que voit le résolveur 1.1.1.1 de Cloudflare, qui est généralement la réponse faisant autorité sans aucun filtrage local.

Les quatre principaux résolveurs publics ont chacun leur propre empreinte réseau et politique. J'utilise Cloudflare ici car il est régulièrement parmi les plus rapides lors des tests de latence indépendants et publie une politique de confidentialité claire. Les autres :

• Google 8.8.8.8 / 8.8.4.4 est le plus grand résolveur public par volume de requêtes. Google enregistre les requêtes et les anonymise après 24 à 48 heures. Pas de filtrage des logiciels malveillants par défaut.
• Quad9 9.9.9.9 / 149.112.112.112bloque les domaines associés aux logiciels malveillants et au phishing en utilisant les données de plus de 20 partenaires de sécurité. Il n'enregistre aucune information d'identification personnelle et est géré par une organisation suisse à but non lucratif.
• OpenDNS 208.67.222.222 / 208.67.220.220 (désormais Cisco) propose des catégories de filtrage configurables. Il enregistre les requêtes ; les abonnements familiaux et professionnels ajoutent des redirections vers des pages de blocage.

Si le résultat de cet outil diffère de ce que renvoie dig ou nslookupsur votre machine, la cause la plus fréquente est que le résolveur de votre OS a mis en cache une ancienne réponse ou renvoie un résultat de type "split-horizon" (une IP privée pour des noms d'hôte internes).

Trouver votre DNS depuis la ligne de commande

Pour voir quel résolveur votre système d'exploitation est réellement configuré à utiliser, et non ce qu'une page web peut déduire, vous devez utiliser un terminal. Ces commandes fonctionnent sur les trois plateformes principales sans installation supplémentaire.

Windows (PowerShell)

# Afficher les adresses des serveurs DNS par carte réseau
Get-DnsClientServerAddress

# Interroger un résolveur spécifique pour le tester
nslookup example.com 1.1.1.1

# Vider le cache DNS local
ipconfig /flushdns

Get-DnsClientServerAddressrépertorie les serveurs DNS attribués à chaque interface réseau, y compris les serveurs principaux et secondaires. Si votre VPN est actif, vous verrez souvent le serveur DNS de l'entreprise sur la carte VPN et celui de votre FAI ou routeur sur la carte Wi-Fi. Le choix de Windows dépend de la métrique de l'interface.

macOS (Terminal)

# Afficher toutes les configurations de résolveur (y compris mDNS et VPN)
scutil --dns

# Interroger et afficher la réponse + le temps de réponse
dig example.com +stats

# Interroger un résolveur spécifique
dig @9.9.9.9 example.com

# Vider le cache DNS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

scutil --dns affiche la liste complète des résolveurs utilisés par macOS, y compris les redirections par domaine configurées par les profils VPN. Il révèle souvent de nombreuses entrées de résolveurs que la simple sortie de la commande digmasque. L'option +stats de dig affiche le temps de requête en millisecondes, idéal pour comparer les performances.

Linux

# Systèmes utilisant systemd-resolved (Ubuntu 18.04+, Fedora, Arch)
resolvectl status

# Solution de secours pour les systèmes minimaux ou sans systemd
cat /etc/resolv.conf

# Interroger avec mesure du temps
dig example.com +stats

# Vider le cache de systemd-resolved
sudo resolvectl flush-caches

Sur les systèmes utilisant systemd-resolved, /etc/resolv.confpointe souvent vers le résolveur stub local à l'adresse 127.0.0.53 plutôt que vers le serveur DNS réel. La commande resolvectl status affiche les serveurs réels par interface. Sur les anciens systèmes ou dans les conteneurs, /etc/resolv.conf reste la source faisant autorité.

Quand votre navigateur ignore le résolveur de votre OS

Depuis 2019 environ, Firefox et Chrome ont commencé à contourner le résolveur configuré de votre système d'exploitation pour envoyer directement les requêtes à un serveur DoH de leur choix. Il ne s'agit pas d'un bug, mais d'une fonctionnalité de confidentialité intentionnelle. Cependant, cela crée des problèmes dans certains environnements.

Firefox a les paramètres par défaut les plus stricts. Aux États-Unis, il active le DoH via Cloudflare par défaut, sauf s'il détecte un signal d'entreprise ou de contrôle parental. Le paramètre se trouve dans about:config sous la clé network.trr.mode :

• 0 — désactivé (utilisation du résolveur de l'OS)
• 2 — DoH avec repli sur l'OS (valeur par défaut de Firefox dans de nombreuses régions)
• 3 — DoH uniquement, pas de repli sur l'OS
• 5 — DoH complètement désactivé

J'ai rencontré ce cas de figure lors de la configuration d'un outil interne. L'équipe de sécurité avait configuré un serveur DNS d'entreprise "split-horizon" via l'adaptateur VPN pour que les noms d'hôte internes comme jenkins.internal se résolvent correctement. Tout fonctionnait sur Chrome et Safari. Firefox, en revanche, utilisait DoH via Cloudflare, renvoyant une erreur NXDOMAIN pour jenkins.internal alors que la résolution fonctionnait sur toutes les autres applications de la machine. La solution a été de configurer network.trr.mode = 5 dans about:config pour les utilisateurs concernés, mais la plupart des gens n'auraient jamais diagnostiqué cela sans savoir que DoH était actif.

Chrome active automatiquement le DoH si votre serveur DNS configuré le prend en charge (fonctionnalité nommée "HTTPS automatique pour le DNS"). Il passe au DoH en utilisant la même IP de serveur. Si votre routeur pointe vers 8.8.8.8, Chrome utilise le point d'accès DoH de Google. Ceci est défini dans la RFC 8484.

Le Relais privé iOS (iCloud+) et le DNS privé d'Android utilisent le DNS sur TLS (DoT, RFC 7858) pour chiffrer les requêtes au niveau de l'OS, sous le navigateur. Lorsque l'un ou l'autre est actif, chaque application de l'appareil envoie des requêtes DNS chiffrées à Apple ou au résolveur de votre choix, peu importe ce que le routeur a annoncé.

Pourquoi le choix du résolveur est réellement important

Le choix du résolveur DNS a des implications concrètes sur la confidentialité, la vitesse, le filtrage et la sécurité.

• Confidentialité.Une requête DNS sur le port 53 transite en texte clair. Votre FAI, toute personne sur le même réseau ou tout routeur sur le chemin peut lire chaque nom d'hôte que vous recherchez. Passer à un résolveur DoH ou DoT chiffre ces requêtes. Votre résolveur les voit toujours, vous transférez donc simplement la visibilité de votre FAI vers le fournisseur du résolveur.
• Vitesse.La latence DNS s'ajoute à chaque nouvelle connexion établie par votre navigateur. Un résolveur plus lent de 50 ms par rapport à la moyenne affectera visiblement le chargement des pages sur les sites comportant de nombreux noms d'hôte. Le réseau anycast de Cloudflare place 1.1.1.1 à quelques millisecondes de la plupart des utilisateurs ; les serveurs des FAI sont géographiquement proches mais souvent plus lents en raison d'infrastructures sous-dimensionnées.
• Censure.Certains FAI bloquent des domaines en renvoyant de fausses réponses DNS pour les noms d'hôte signalés. Utiliser un résolveur public qui n'applique pas ces filtres permet de contourner les blocages DNS. Notez que les FAI et les gouvernements disposent d'autres mécanismes de blocage (trous noirs BGP, filtrage SNI) que les modifications DNS ne résolvent pas.
• Fuites DNS avec VPN.Un VPN qui achemine le trafic dans un tunnel mais laisse les requêtes DNS s'échapper vers le résolveur de votre FAI présente une fuite DNS. Votre FAI voit toujours chaque nom d'hôte recherché même si votre IP semble être ailleurs. L'outil de fuite VPN vérifie spécifiquement ce point.
• Filtrage. Quad9 bloque les domaines de logiciels malveillants et de phishing. OpenDNS propose un filtrage par catégorie configurable. Ce sont deux utilisations légitimes : Quad9 pour la sécurité sans configuration, OpenDNS pour le contrôle parental ou scolaire.

Problèmes DNS courants et comment les diagnostiquer

Le site se charge sur mobile mais pas sur ordinateur portable

Il s'agit presque toujours d'un enregistrement obsolète en cache. Votre ordinateur a résolu le nom d'hôte avant une modification DNS et a conservé l'ancienne IP pendant toute la durée du TTL. Les données mobiles utilisent généralement un résolveur différent avec un cache distinct, affichant ainsi le nouvel enregistrement immédiatement. Solution : videz le cache DNS (commandes ci-dessus) et rechargez.

Le DNS se résout avec dig mais pas dans le navigateur

Votre navigateur utilise le DoH avec un résolveur différent de celui de votre système d'exploitation. Si vous êtes sur un réseau d'entreprise avec un DNS "split-horizon" (des noms d'hôte internes qui ne se résolvent que sur le résolveur d'entreprise), le résolveur DoH du navigateur renverra NXDOMAIN tandis que dig, qui interroge le résolveur système, réussira. Désactivez le DoH dans le navigateur pour l'environnement concerné.

Les pages se chargent lentement malgré une connexion rapide

Une latence élevée du résolveur peut en être la cause. Exécutez dig example.com +statset regardez la ligne "Query time" en bas. Tout temps supérieur à 100 ms est nettement plus lent qu'un résolveur public performant. Configurez le DNS de votre OS ou routeur sur 1.1.1.1 ou 8.8.8.8 pour comparer. Lors d'une nouvelle session de navigation sans cache, la latence du résolveur s'ajoute directement au temps d'accès au premier octet pour chaque nouveau domaine.

Les noms d'hôte internes échouent uniquement dans Firefox

Le DoH de Firefox est actif et écrase le résolveur de l'entreprise ou du VPN. Ouvrez about:config, recherchez network.trr.mode et réglez-le sur 5pour désactiver DoH. L'équipe informatique peut également déployer un signal via un domaine canari (renvoyant un enregistrement spécifique pour use-application-dns.net) pour indiquer à Firefox de désactiver automatiquement le DoH sur les réseaux gérés.

Comparatif des résolveurs DNS publics

Le choix d'un résolveur est un compromis entre politique de confidentialité, filtrage, vitesse et confiance envers l'opérateur.

Les chiffres de latence sont des moyennes globales approximatives issues de DNSPerf. Votre latence réelle dépend fortement de votre région et des accords d'interconnexion (peering) de votre FAI.

Foire aux questions

Quel est mon serveur DNS ?

Il y a généralement trois niveaux de réponse. Votre routeur possède un DNS configuré (souvent le résolveur de votre FAI). Il le transmet à vos appareils via DHCP. Votre OS l'enregistre comme résolveur par défaut et votre résolveur stub lui transmet les requêtes. Enfin, votre navigateur peut écraser ce paramètre en utilisant le DoH vers un résolveur public. Pour voir ce que votre OS utilise réellement, lancez Get-DnsClientServerAddress sur Windows, scutil --dns sur macOS, ou resolvectl status sur Linux.

Pourquoi mon DNS diffère-t-il de celui affiché par mon routeur ?

Votre routeur diffuse un serveur DNS via DHCP, mais votre appareil peut l'ignorer. Un client VPN configure souvent un autre serveur DNS lors de sa connexion. Un navigateur avec DoH activé contourne complètement le résolveur de l'OS pour ses propres requêtes. Les profils MDM d'entreprise sur les appareils gérés imposent souvent un résolveur spécifique. Chacun de ces niveaux peut afficher un résolveur différent de celui de votre routeur.

Est-il plus sûr de passer au DNS 1.1.1.1 ?

Pour la confidentialité vis-à-vis de votre FAI, oui. Le résolveur de Cloudflare ne vend pas vos historiques de requêtes et les supprime sous 25 heures. Le DNS de votre FAI transite en clair sur le port 53, visible par n'importe qui sur le réseau. Passer à 1.1.1.1 avec DoH empêche votre FAI de lire vos requêtes. Pour la protection contre les malwares, 1.1.1.1 ne filtre rien par défaut ; utilisez plutôt 1.1.1.2. Changer de DNS ne masque pas votre adresse IP et ne chiffre pas vos connexions en dehors des requêtes DNS.

Mon FAI peut-il voir les sites que je visite si j'utilise 1.1.1.1 ?

Pas via le DNS si vous utilisez DoH ou DoT. Mais le DNS n'est qu'un signal parmi d'autres. Votre FAI voit toujours les adresses IP de destination de vos connexions et le champ SNI (Server Name Indication) lors de l'établissement de la connexion TLS, ce qui révèle le nom d'hôte sur les sites HTTPS. Le chiffrement du SNI (ECH - Encrypted Client Hello) n'est pas encore déployé partout. Utiliser 1.1.1.1 avec DoH sécurise le DNS, mais pas les IP ou le SNI.

Comment savoir si mon DNS fuit ?

Une fuite DNS signifie que votre appareil envoie des requêtes DNS en dehors du tunnel VPN vers le résolveur de votre FAI, alors même que le VPN est connecté. Votre IP de sortie VPN est visible, mais vos requêtes DNS restent exposées. L'outil de fuite VPN vérifie cela en comparant votre IP publique, votre IP WebRTC et le résolveur répondant à vos requêtes DNS. Si les trois pointent vers le fournisseur VPN, vous êtes protégé.

Outils associés

Le DNS traduit des noms en IP, mais l'IP elle-même indique sur quel réseau vous êtes connecté. Consultez Mon IP pour voir l'adresse d'origine de vos connexions. L'organisation derrière cette IP est visible dans Mon FAI. Si vous soupçonnez votre VPN de laisser échapper le DNS en dehors du tunnel, la page de test de fuite VPN analyse votre IP publique, votre IP WebRTC et votre résolveur DNS. Pour tester la vitesse et la latence, rendez-vous sur Test de débit internet.

Sources citées ci-dessus

• RFC 1034: Domain names — concepts and facilities (1987)
• RFC 1035: Domain names — implementation and specification (1987)
• RFC 7858: DNS over TLS (DoT, 2016)
• RFC 8484: DNS over HTTPS (DoH, 2018)
• DNSPerf: bancs d'essai de latence des résolveurs publics
• Politique de confidentialité du résolveur public Cloudflare 1.1.1.1

Common questions