Qu'est-ce que le DNS et Comment Fonctionne la Résolution

Ce que le DNS fait vraiment à chaque requête

Chaque requête vers example.com commence par une recherche qui n’a rien à voir avec votre application : il faut d’abord transformer ce nom en adresse IP avant qu’un seul paquet TCP ne quitte la machine. Cette traduction, c’est le DNS, le Domain Name System, et elle intervient à chaque requête, que le client soit un navigateur, curl, ou un service backend qui en appelle un autre par son hostname.

Il n’y a pas de table unique derrière tout ça. Le DNS est une hiérarchie de serveurs, chacun responsable d’une tranche du namespace, interrogés les uns après les autres jusqu’à obtenir la réponse. Connaître cette chaîne, c’est ce qui transforme “le site est en panne” en “le certificat a expiré” ou “l’enregistrement pointe encore vers l’ancienne IP” : deux problèmes très différents qui, depuis un onglet de navigateur, se ressemblent en tout point.

Comment un resolver récursif parcourt la hiérarchie DNS

Deux types de serveurs font le travail, avec des rôles distincts. Le resolver récursif est celui que votre machine interroge : celui de votre fournisseur d’accès, ou un resolver public comme 1.1.1.1 ou 8.8.8.8. Il fait le trajet à votre place et renvoie une seule réponse finale. Les serveurs faisant autorité détiennent les enregistrements réels d’un domaine, répartis sur une hiérarchie qui reflète les niveaux du nom, séparés par des points.

1
2
3
4
5
6
7
8

client   ->  resolver                             une requête, une réponse
             resolver -> serveur racine           "qui gère .com ?"
                      <- nameservers pour .com
             resolver -> serveur TLD .com         "qui gère example.com ?"
                      <- nameservers pour example.com
             resolver -> nameserver example.com   "enregistrement A pour example.com ?"
                      <- 93.184.216.34
client   <-  resolver                             93.184.216.34

Les serveurs racine ne savent rien de example.com. Ils savent seulement quels serveurs gèrent .com. Le serveur TLD (top-level domain) .com ne détient pas non plus l’enregistrement ; il sait seulement quels nameservers font autorité pour example.com, ceux que votre registrar renseigne quand vous configurez le domaine. Seul ce dernier serveur détient l’enregistrement A et renvoie une IP. Trois allers-retours, pour que votre machine n’ait jamais à connaître cette hiérarchie.

La majeure partie de ce parcours n’a jamais lieu lors d’une requête réelle. Les resolvers mettent en cache les réponses des serveurs racine et TLD pendant des heures voire des jours, car elles changent rarement, si bien qu’une requête réelle démarre généralement déjà au serveur faisant autorité pour l’enregistrement concerné. Souvent, elle n’y arrive même pas : la réponse est déjà en cache.

Les types d’enregistrements DNS à connaître

Le serveur faisant autorité d’un domaine détient un ensemble d’enregistrements, chacun répondant à une question différente :

Le CNAME est celui qui piège tout le monde. Il ne pointe pas vers une IP ; il pointe vers un autre nom, et le resolver doit aussi chercher celui-là, en suivant la chaîne jusqu’à tomber sur un enregistrement A ou AAAA. Une CDN ou une plateforme SaaS vous donne un hostname comme abcd123.cloudfront.net précisément pour ça : elle peut changer les IP derrière ce nom quand elle le souhaite, et en renvoyer une différente selon d’où vient la requête, sans que vous ayez à toucher votre enregistrement DNS.

Une restriction piège quiconque configure un domaine nu : un CNAME ne peut pas coexister avec d’autres enregistrements sur le même nom, et l’apex de la zone (example.com sans sous-domaine) a toujours besoin d’enregistrements NS et SOA. Vous ne pouvez donc pas mettre un CNAME de l’apex vers le hostname d’une CDN, seulement un sous-domaine comme www. Les fournisseurs contournent ça avec ce qu’ils appellent ALIAS, ANAME, ou le CNAME flattening : le serveur faisant autorité résout lui-même la cible et renvoie un enregistrement A, si bien que l’apex ressemble à un enregistrement d’adresse ordinaire pour chaque client tout en suivant les IP changeantes de la CDN en arrière-plan.

Comment interroger le DNS avec dig

dig pose ces questions directement, sans le cache d’un navigateur qui s’interpose.

1

dig example.com

La partie qui compte, c’est la ANSWER SECTION :

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Cinq champs, dans l’ordre : le nom interrogé, le TTL en secondes (combien de temps cette réponse peut rester en cache), la classe (IN pour internet, en pratique toujours celle-ci), le type d’enregistrement et la valeur. Un TTL de 300 signifie que tout resolver détenant cette réponse la réinterroge dans les cinq minutes.

Interrogez un type précis au lieu du A par défaut :

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Ajoutez +short quand vous ne voulez que la valeur, ce qui est utile dans un script :

1
2

dig +short example.com
93.184.216.34

Interrogez un resolver précis avec @. C’est comme ça que vous vérifiez si un changement a déjà atteint un fournisseur avant qu’il n’arrive jusqu’à vous :

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

+trace rejoue tout le parcours, du serveur racine jusqu’à la réponse faisant autorité, au lieu de faire confiance à un résultat en cache :

1

dig +trace example.com

nslookup fait le même travail de base avec une interface plus ancienne et plus verbeuse. Utile à connaître car il est présent par défaut sous Windows, où dig manque souvent.

Pourquoi un changement DNS prend du temps : TTL et cache

Vous modifiez un enregistrement et il n’apparaît pas partout instantanément. Ce délai s’appelle la “propagation”, un mot qui suggère quelque chose qui se diffuse sur internet copie après copie. Rien ne se diffuse. La nouvelle valeur est active sur le serveur faisant autorité dès l’instant où vous l’enregistrez. Ce qui prend du temps, c’est chaque resolver qui avait déjà en cache l’ancienne réponse et continue à la servir jusqu’à ce que cette copie expire.

Ça change la question à se poser. Pas “combien de temps prend la propagation”, mais “quel TTL avait l’ancien enregistrement, et combien de resolvers l’ont mis en cache”. Un TTL de 300 secondes signifie qu’un resolver ayant interrogé il y a une minute sert l’ancienne réponse pendant quatre minutes de plus au maximum. Un TTL de 86400 signifie qu’un resolver quelque part répond avec l’ancienne IP jusqu’à un jour après votre changement. Certains fournisseurs ignorent même le TTL demandé et mettent en cache plus longtemps que prévu, ce qui explique aussi pourquoi deux personnes sur des réseaux différents peuvent très bien voir des réponses différentes en plein changement.

Alors planifiez le changement au lieu d’attendre que ça passe. La veille d’une migration prévue vers un nouveau serveur ou une nouvelle CDN, baissez le TTL de l’enregistrement que vous allez modifier à 60 ou 300 secondes. Ce TTL bas doit d’abord atteindre les caches et faire expirer les copies à longue durée de vie. Faites ensuite le vrai changement : chaque resolver se rafraîchit désormais dans la nouvelle fenêtre courte au lieu de l’ancienne longue. Remontez le TTL une fois la nouvelle valeur confirmée.

Erreurs DNS courantes, et quand le problème n’est pas le DNS

Un CNAME orphelin est l’erreur la plus fréquente sur le terrain. Un sous-domaine pointe encore vers un service démantelé, un ancien bucket S3 ou une distribution CDN supprimée, et quiconque revendique ce nom de l’autre côté peut servir son propre contenu sous votre domaine. Supprimez l’enregistrement DNS le jour même où vous démantelez ce vers quoi il pointait, pas des semaines plus tard.

Des enregistrements MX manquants ou incorrects ressemblent à un problème de serveur de messagerie. Si les emails sortants fonctionnent mais que rien n’arrive jamais, vérifiez l’enregistrement MX du domaine avant de toucher à la config du serveur de messagerie ; il pointe peut-être encore vers un service que vous avez quitté il y a des mois.

Beaucoup de rapports “le DNS est cassé” n’ont rien à voir avec le DNS. Si dig example.com renvoie bien la bonne IP actuelle et que le site ne charge toujours pas, la résolution a déjà réussi et le problème est plus en aval : une règle de pare-feu, un certificat qui ne correspond pas lors du handshake TLS, ou un reverse proxy qui route selon un en-tête Host qu’il ne reconnaît pas. Vérifiez la réponse avec dig avant de tirer des conclusions de ce que montre le navigateur.

Où vérifier en premier quand un domaine ne résout pas

Lancez dig +short <domaine> contre votre resolver système et contre un resolver public (dig @1.1.1.1 +short <domaine>). S’ils ne sont pas d’accord, vous êtes en plein changement, et l’ancien TTL vous dit combien de temps attendre encore. S’ils sont d’accord et que l’IP est correcte, le DNS a fait son travail : passez à TLS, au routage ou à l’application. Si l’IP est fausse ou que rien ne revient, corrigez-le au niveau du nameserver faisant autorité. Vider votre cache local ne change rien à ce que voit qui que ce soit d’autre.

Articles associés

• Qu’est-ce qu’un CDN et Comment Il Fonctionne
• Qu’est-ce que TLS et Comment Fonctionne le Chiffrement HTTPS
• Qu’est-ce qu’un Reverse Proxy et Comment Il Fonctionne