La résolution DNS expliquée : étapes, serveurs, cache et défaillances

Quand votre navigateur a besoin d’une adresse pour un nom comme pudgycat.io, le DNS l’aide à la trouver. Parfois, la réponse est déjà en cache ; parfois, un résolveur doit interroger d’autres serveurs. Ce guide explique ce processus, pourquoi les réponses peuvent changer et comment distinguer un problème de résolution d’un site web qui passe une mauvaise journée. Le carnet d’adresses d’internet est étonnamment occupé pour quelque chose que personne ne se souvient avoir ouvert.

Sommaire

• Qu’est-ce que le DNS et pourquoi en avons-nous besoin ?
• Le fonctionnement de la résolution DNS, étape par étape
• Les quatre types de serveurs DNS
• Les types d’enregistrements DNS à connaître
• Cache DNS et TTL
• Requêtes DNS récursives et itératives
• Sécurité DNS : DNSSEC, DoH et DoT
• Quand le DNS tombe en panne : défaillances courantes
• Questions fréquentes

Qu’est-ce que le DNS et pourquoi en avons-nous besoin ?

Le système de noms de domaine associe des noms à des enregistrements typés, notamment des adresses IP. Un navigateur peut utiliser une adresse pour contacter un service, mais le DNS sert aussi au routage du courrier et à d’autres usages. Il ne récupère pas lui-même la page web. Pensez « trouver la destination », puis « établir la connexion » : deux tâches liées qui peuvent échouer indépendamment.

Les premières correspondances entre noms d’hôtes et adresses sur internet étaient distribuées dans un fichier central HOSTS.TXT. La spécification DNS de Paul Mockapetris explique pourquoi cette approche devenait difficile à faire évoluer à grande échelle. Le DNS répartit plutôt les responsabilités dans une hiérarchie. Son histoire est celle d’un déploiement et d’une évolution progressifs, pas d’un jour unique où le monde entier aurait changé ses réglages.

Noms et adresses IP

L’adresse d’un service peut changer sans que son nom change. Un nom peut aussi posséder plusieurs enregistrements d’adresse. Cette souplesse sépare le nom retenu par les visiteurs des machines ou des emplacements réseau qui les servent. Le DNS ne garantit pas un numéro permanent pour chaque site web.

Le fonctionnement de la résolution DNS, étape par étape

Voici un parcours de résolution simplifié, conforme à l’explication du DNS par Cloudflare. Les paramètres du navigateur, du système d’exploitation et du réseau peuvent le modifier ; ce n’est pas un voyage en huit étapes répété à chaque chargement de page.

1. Recherche locale. Le navigateur ou le système d’exploitation possède peut-être déjà une réponse utilisable en cache.
2. Configuration locale. Les fichiers hosts et les réglages des applications peuvent influencer la résolution des noms. Leur priorité exacte dépend du système.
3. Choisir un résolveur. L’appareil peut utiliser celui de son réseau, un service public configuré ou le fournisseur de DNS chiffré du navigateur.
4. Demander une réponse. Un résolveur récursif peut répondre depuis son cache ou poursuivre la recherche.
5. Trouver la délégation pertinente. Si nécessaire, le résolveur demande à un serveur racine où trouver les serveurs du domaine de premier niveau.
6. Suivre l’indication suivante. Un serveur TLD peut le diriger vers les serveurs faisant autorité pour le domaine.
7. Obtenir l’enregistrement. Une réponse faisant autorité peut contenir une adresse, un alias nécessitant une autre recherche ou un résultat négatif.
8. Renvoyer le résultat. Le résolveur répond, et les enregistrements admissibles peuvent être mis en cache. Le navigateur peut alors tenter une connexion.

Il n’existe pas de durée universelle de résolution. L’état du cache, la distance réseau, les nouvelles tentatives, la charge des serveurs et la configuration comptent tous. Le DNS n’est aussi qu’une partie du chargement d’une page : une réponse rapide ne peut pas faire accélérer un serveur d’application lent.

Les quatre types de serveurs DNS

Ce sont des rôles utiles à reconnaître. Les serveurs racine et TLD font eux-mêmes autorité pour leurs zones respectives ; les catégories décrivent la place du serveur et le service qu’il fournit, pas quatre espèces de machines sans rapport entre elles.

1. Résolveur récursif

Un résolveur récursif cherche des réponses pour le compte d’un client, souvent à partir d’informations en cache et parfois en passant par un autre résolveur en amont. Un routeur domestique peut transmettre les requêtes plutôt que d’effectuer tout le travail lui-même. Les fournisseurs de résolveurs publics ont aussi des politiques différentes de filtrage et de conservation ; « DNS public » n’est pas une promesse uniforme de vitesse ou de confidentialité.

2. Serveur de noms racine

Il existe 13 identités nommées de serveurs racine, de A à M, exploitées par 12 organisations à travers de nombreuses instances distribuées. Le site des opérateurs de serveurs racine décrit ce système. Ces serveurs servent la zone racine, dont les délégations des TLD. « Treize racines » ne signifie pas treize ordinateurs physiques devant lesquels tout internet fait la queue.

3. Serveur de noms TLD

Les serveurs faisant autorité pour un TLD servent sa zone, notamment les délégations des noms situés en dessous. Ils ne conservent pas un annuaire vivant de tous les domaines jamais enregistrés et ne contiennent pas nécessairement l’adresse finale de chaque site. Une indication de délégation dit au résolveur où interroger ensuite.

4. Serveur de noms faisant autorité

Un serveur faisant autorité fournit les données d’une zone. Les administrateurs de domaines publient leurs modifications par l’intermédiaire de leur fournisseur DNS ou de leur propre système ; des serveurs redondants peuvent servir la même zone. « Faisant autorité » décrit la responsabilité sur ces données, pas la propriété du site web ni une garantie de bonne configuration par l’opérateur.

Les types d’enregistrements DNS à connaître

Le DNS utilise différents types d’enregistrements selon les besoins. Le registre de l’IANA les répertorie avec leurs spécifications. Parmi les exemples courants :

• Enregistrement A : associe un nom à une adresse IPv4.
• Enregistrement AAAA : associe un nom à une adresse IPv6. Se prononce « quadruple A ».
• Enregistrement CNAME : un alias. Fait pointer un nom vers un autre, par exemple www.example.com comme alias de example.com.
• Enregistrement MX : échange de courrier. Indique aux serveurs de messagerie où livrer les messages destinés au domaine.
• Enregistrement TXT : texte arbitraire. Utilisé pour SPF, DKIM, la vérification de propriété du domaine et, dans le Far West de la plomberie d’internet, parfois pour configurer des services.
• Enregistrement NS : serveur de noms. Liste les serveurs DNS faisant autorité pour un domaine.
• Enregistrement PTR : pointe vers un autre nom de domaine ; les zones DNS inverses l’utilisent pour associer une adresse à un nom. Il n’inverse pas nécessairement exactement l’enregistrement A d’un site web.
• Enregistrement SRV : emplacement d’un service. Définit le nom d’hôte et le port d’un service particulier, utilisé notamment par SIP, XMPP et Minecraft.
• Enregistrement CAA : autorisation d’autorité de certification. Indique quelles autorités sont autorisées à émettre des certificats HTTPS pour le domaine.

Vous pouvez examiner ces enregistrements depuis un terminal. Sous Linux et macOS, dig pudgycat.io renvoie l’enregistrement A. dig -t MX pudgycat.io renvoie les enregistrements de courrier. Sous Windows, nslookup remplit le même rôle.

Cache DNS et TTL

Les enregistrements de ressources DNS portent un TTL, mesuré en secondes, qui limite normalement la durée de leur réutilisation depuis un cache. La RFC 1035 définit ce champ. Ces durées illustrent les compromis possibles, sans constituer des réglages obligatoires :

• 300 secondes : cinq minutes.
• 3600 secondes : une heure.
• 86400 secondes : un jour.

Modifier un enregistrement faisant autorité n’efface pas immédiatement les copies en cache. Réduire le TTL à l’avance peut faciliter un changement prévu, mais les copies enregistrées avec l’ancien TTL doivent encore avoir le temps d’expirer. Les réponses négatives peuvent aussi être mises en cache, comme l’explique la RFC 2308. Certains résolveurs peuvent servir des données expirées dans des conditions de défaillance définies : le TTL n’est donc pas un chronomètre universel pour tous les résultats observables.

Requêtes DNS récursives et itératives

On confond souvent ces deux termes. Ils décrivent des rôles différents dans la même chaîne.

Une requête récursive demande à un résolveur d’obtenir la réponse au lieu de laisser le client suivre les délégations. Le petit résolveur côté client est souvent appelé stub resolver. « Résolveur » ne désigne donc pas toujours un service récursif public.

Avec les requêtes itératives, le résolveur qui interroge peut suivre lui-même les délégations. Il possède peut-être déjà assez d’informations de délégation en cache pour sauter l’étape racine ou TLD. La hiérarchie explique qui est responsable, pas un itinéraire fixe.

La délégation répartit les responsabilités ; le cache évite de refaire le travail. Voilà l’astuce architecturale, même lorsque le parcours réel est raccourci grâce à des informations déjà disponibles.

Sécurité DNS : DNSSEC, DoH et DoT

Le DNS classique a deux propriétés gênantes : il n’est pas chiffré et il n’authentifie pas les réponses. Trois protocoles modernes corrigent différentes parties du problème.

DNSSEC

DNSSEC permet à un résolveur validant de vérifier l’authenticité et l’intégrité des données DNS signées à travers une chaîne de confiance. Il ne chiffre pas les requêtes, ne certifie pas qu’un site est inoffensif et n’authentifie pas magiquement les données non signées. Une chaîne de validation rompue peut elle-même faire échouer la résolution.

DNS sur HTTPS (DoH)

DNS sur HTTPS (DoH) transporte les messages DNS au sein d’une connexion HTTPS chiffrée. Il protège ce transport contre l’écoute et l’altération directes. Le résolveur choisi traite toujours la requête, et le DNS chiffré ne dissimule pas tous les indices concernant les sites que vous visitez. L’emballage HTTPS n’est pas une cape d’invisibilité parfaite.

DNS sur TLS (DoT)

DNS sur TLS (DoT) utilise une connexion DNS protégée par TLS, généralement sur le port 853. Ce port dédié permet de distinguer plus facilement ce trafic du HTTPS ordinaire. Comme DoH, sa protection couvre la connexion chiffrée configurée, pas toutes les étapes d’une visite sur un site.

Le transport chiffré et les données DNS signées répondent à des risques différents. Aucun des deux ne dispense de choisir un résolveur digne de confiance. En particulier, chiffrer une connexion vers un résolveur malveillant ne rend pas ses réponses honnêtes.

Quand le DNS tombe en panne : défaillances courantes

Le DNS est l’une des causes possibles d’une visite qui échoue, à côté des problèmes de réseau, TLS, hébergement, application et base de données. Vérifiez le symptôme avant de modifier les réglages. Parmi les résultats courants liés au DNS :

• NXDOMAIN : le nom demandé n’existe pas. Un nom existant sans enregistrement du type demandé constitue une autre réponse négative, souvent appelée NODATA.
• SERVFAIL : la résolution a échoué. Une erreur de validation DNSSEC est une cause possible, parmi d’autres problèmes en amont ou côté serveur.
• Ancienne réponse en cache : un enregistrement antérieur peut encore être dans sa période de TTL. Vider un cache local ne vide pas tous les résolveurs en amont.
• Réponse erronée : une mauvaise configuration ou une manipulation peut mal orienter une recherche. La validation DNSSEC et le transport chiffré ont des rôles protecteurs différents et limités.
• Panne du résolveur : un autre résolveur autorisé peut aider à diagnostiquer un problème chez le fournisseur local. Il ne peut pas réparer une zone faisant autorité mal configurée ni un serveur web en panne.

Les attaques contre Dyn d’octobre 2016 montrent qu’une perturbation chez un fournisseur DNS peut affecter l’accès à de nombreux services à la fois. L’analyse conservée de l’incident par Dyn décrit des attaques contre son infrastructure DNS gérée et précise explicitement que l’entreprise n’a pas pu vérifier les informations évoquant une ampleur de 1,2 Tb/s. La leçon n’exige pas de transformer un chiffre non confirmé en fait.

Pour la suite du parcours entre un nom et quelque chose qui se joue à l’écran, consultez notre explication du streaming vidéo (en anglais). Résoudre une adresse lance le voyage ; cela ne livre pas la vidéo à soi seul.

Questions fréquentes

Combien de temps prend la résolution DNS ?

Cela dépend du cache, des conditions réseau et de la nécessité de nouvelles tentatives. Un résultat conservé localement peut être très rapide, mais il n’existe pas de maximum universel fiable pour une résolution sans cache.

Quelle différence entre un résolveur DNS et un serveur DNS ?

Un serveur DNS répond aux requêtes DNS. Un résolveur est le composant qui obtient les réponses ; il peut s’agir d’un petit stub côté client ou d’un service récursif. Les serveurs racine et TLD fournissent généralement des données de zone faisant autorité plutôt que d’effectuer la récursion pour votre navigateur.

Comment vider mon cache DNS ?

Sous Windows, ipconfig /flushdns efface le cache du résolveur client DNS. Les autres systèmes et applications ont leurs propres procédures, variables selon les versions. Vider un cache ne modifie pas les enregistrements faisant autorité et ne vide pas celui d’un fournisseur.

Dois-je changer de résolveur DNS ?

Cela peut être utile pour le dépannage, mais les performances et la confidentialité varient selon le fournisseur et le réseau. Les appareils professionnels ou scolaires peuvent dépendre d’un résolveur particulier pour les services internes. Vérifiez les réglages et règles applicables, et notez la configuration initiale avant de la modifier. Un autre résolveur n’est pas un remède universel à une connexion lente.

Le DNS peut-il servir à bloquer des sites ?

Oui. Un résolveur peut refuser ou modifier les réponses, mais le filtrage DNS n’est qu’une méthode de blocage. Saisir directement une IP peut ne pas fonctionner avec un hébergement partagé et HTTPS. Le DNS chiffré et DNSSEC ne garantissent pas le contournement des restrictions ; d’autres contrôles réseau peuvent toujours s’appliquer.

Ce qu’il faut retenir

Il est facile d’oublier le DNS jusqu’à ce qu’un nom cesse d’être résolu. Le modèle utile est celui d’une hiérarchie de responsabilités appuyée sur des caches, pas d’une chaîne rigide exécutée à chaque visite. Quand un site tombe en panne, le DNS mérite une vérification, pas une condamnation automatique. Même le carnet d’adresses d’internet ne peut pas réparer une base de données partie déjeuner.

Traduction française de l’article original en anglais du 2026-05-26. Traduction réalisée avec l’aide de l’IA le 1 novembre 2026 ; les références temporelles restent celles de l’original.