Imaginez que l'adresse du serveur d'un domaine ait changé : le nouveau site s'ouvre chez vous, mais votre téléphone rejoint encore l'ancien serveur. Même avec le même nom, les résultats peuvent différer temporairement si les appareils passent par des caches DNS différents. Le cache HTTP qui réutilise des pages téléchargées et le cache DNS qui aide à trouver une adresse de connexion ne se vérifient pas de la même façon.
Cet article suit l'hôte fictif de bibliothèque www.library.example pour expliquer la résolution de noms et le cache. Les noms et les horaires sont des exemples pédagogiques, sans mesure d'un service réel. Il s'agit de distinguer l'obtention d'une adresse, le retard apparent d'une modification et les échecs survenant après la résolution DNS.
1. DNS fournit plusieurs types de réponses pour chaque nom
DNS fournit les informations associées aux noms de domaine sous forme d'enregistrements de différents types. A représente une adresse IPv4, AAAA une adresse IPv6, et un nom peut avoir plusieurs adresses. CNAME est un alias vers un autre nom, MX désigne un serveur destinataire du courrier et NS un serveur de noms faisant autorité pour la zone. Une requête sur le même nom peut donc recevoir une réponse différente selon le type demandé.
Comme l'explique la documentation Cloudflare sur les enregistrements DNS, la valeur d'un CNAME est un autre nom, pas une adresse IP. Obtenir une adresse peut nécessiter de résoudre aussi ce nom. Dans https://www.library.example/books, DNS traite le nom d'hôte www.library.example. Ni le chemin /books ni le contenu de la page ne sont enregistrés dans DNS. Un CNAME ne crée pas automatiquement une redirection HTTP qui modifie la barre d'adresse du navigateur.
2. Comment le résolveur récursif trouve les serveurs faisant autorité
La fonction de résolution d'un appareil interroge généralement son résolveur récursif configuré. Celui-ci utilise les informations en cache si elles sont disponibles ; sinon, il interroge d'autres serveurs DNS et renvoie la réponse finale ou une erreur. La norme de terminologie DNS RFC 9499 distingue ce travail effectué pour le client du rôle d'un serveur faisant autorité, qui détient les informations de sa zone. Il faut lire la provenance d'une réponse en fonction du rôle du serveur.
Dans un parcours simplifié sans cache ni intermédiaire, le résolveur reçoit de la racine une indication vers les serveurs du domaine de premier niveau, puis de ceux-ci une indication vers les serveurs faisant autorité pour la zone cible. Il y obtient l'enregistrement ou l'alias recherché. Un serveur racine ne conserve pas les adresses IP de tous les sites. En pratique, le parcours peut commencer par une délégation déjà en cache ou être transmis à un autre résolveur : chaque visite ne répète donc pas nécessairement toute cette séquence.
3. Le TTL est une durée de cache restante, pas une horloge mondiale
Le TTL d'un enregistrement indique sa durée de cache en secondes. Dans une réponse ordinaire issue du cache, le temps restant diminue pendant le stockage. Si un résolveur mémorise une adresse avec un TTL de 300 secondes à 10:00, le TTL restant d'une réponse utilisant cette même copie à 10:02 est d'environ 180 secondes. Le tableau suppose un résolveur unique, sans nouvelle interrogation anticipée, rafraîchissement préalable ni réponse périmée.
| Heure fictive | Adresse sur le serveur faisant autorité | Traitement de ce résolveur |
|---|---|---|
| 10:00 | Ancienne adresse | Stocke l'ancienne adresse avec un TTL de 300 secondes |
| 10:01 | Nouvelle adresse configurée | Il reste 240 secondes à la copie stockée |
| 10:03 | Nouvelle adresse | Peut réutiliser l'ancienne adresse pendant les 120 secondes restantes |
| Première requête après 10:05 | Nouvelle adresse | Nouvelle interrogation supposée à la place de la copie expirée pour obtenir la nouvelle adresse |
D'autres résolveurs peuvent avoir stocké l'enregistrement plus tard ou ne jamais l'avoir vu. Leurs rafraîchissements ne sont pas simultanés ; un TTL unique ne définit donc pas le moment où tous les utilisateurs changent d'adresse. Un cache peut aussi supprimer les données avant expiration, et actualiser une page web n'efface pas la copie d'un résolveur partagé. Le TTL aide à comprendre la réutilisation des réponses DNS, sans fixer la durée de toute une connexion web ou d'une actualisation d'écran.
4. Quand abaisser le TTL et comment une absence est mise en cache
Un cache ayant reçu l'ancienne adresse avec un TTL de 3 600 secondes n'apprend pas immédiatement que l'opérateur vient de le réduire à 60 secondes. Pour un changement prévu, ajustez le TTL à l'avance et tenez compte des réponses encore stockées avec l'ancienne durée plus longue. Un TTL réduit peut accélérer la vérification des changements, mais augmente aussi les requêtes et la dépendance aux serveurs faisant autorité. Étudiez le changement et la gestion des pannes plutôt que d'imposer la même valeur courte à tous les services.
NXDOMAIN, qui indique qu'un nom n'existe pas, et NODATA, qui indique qu'un nom existe mais sans enregistrement du type demandé, peuvent aussi être mis en cache. La norme de cache négatif RFC 2308 définit cette durée à partir du minimum entre le TTL de l'enregistrement SOA du serveur faisant autorité et le champ MINIMUM du SOA. Une ancienne réponse d'absence peut donc persister juste après l'ajout d'un hôte. Supposer qu'elle expire selon le TTL du nouvel enregistrement A peut masquer la cause.
5. Vérifier en conservant le même nom, le même type et le même serveur
Notez le nom exact interrogé, le type comme A ou AAAA, le serveur DNS interrogé et l'heure. Si dig est installé, dig example.com A permet de préciser le nom et le type. Pour un problème réel, remplacez example.com par l'hôte à vérifier. Cette commande illustre une procédure ; elle n'a pas été exécutée ni utilisée pour mesurer des temps de réponse dans cet article.
Examinez l'état de la réponse et les noms, types, valeurs et TTL présents dans ANSWER. Lorsque vous répétez la même requête au même résolveur, observez si le TTL diminue, sans considérer immédiatement une augmentation comme une erreur. Un rafraîchissement anticipé ou un autre nœud de cache peut l'expliquer. Consignez séparément les réponses A et AAAA pour distinguer la famille d'adresses concernée.
Si vous administrez la zone, comparez la réponse du résolveur récursif utilisé à celle du serveur faisant autorité, pour le même nom et le même type. En cas d'écart, vérifiez successivement la durée de cache restante, la cohérence entre serveurs faisant autorité et la délégation. Ne généralisez pas la réponse d'un résolveur public à tous les utilisateurs. Le DNS interne d'une entreprise ou les paramètres DNS propres au navigateur peuvent modifier le parcours : notez aussi l'environnement de connexion.
6. Distinguer erreurs DNS, erreurs de connexion et exceptions
NXDOMAIN indique l'absence du nom et NODATA l'absence du type d'enregistrement demandé. SERVFAIL signifie en revanche que le serveur n'a pas pu traiter la requête ; un délai d'attente dépassé signifie qu'aucune réponse n'est arrivée pendant la durée prévue. Ces situations ne veulent pas toutes dire que le domaine a été supprimé. Conservez d'abord le code éventuel et le serveur interrogé afin de choisir la vérification suivante.
Une ancienne réponse après expiration du TTL n'est pas toujours une violation. La méthode serve-stale de la RFC 8767 prévoit l'utilisation d'informations expirées pour améliorer la disponibilité lorsque le rafraîchissement auprès des serveurs faisant autorité est exceptionnellement impossible. Cela ne signifie pas que tous les résolveurs l'activent avec les mêmes réglages. Vérifiez le résolveur réellement utilisé plutôt que de déduire d'un TTL unique un délai certain de prise en compte.
Enfin, une résolution correcte ne garantit pas l'accès au site. Le réseau vers cette adresse, le certificat TLS, le serveur web et l'application sont d'autres étapes. Si DNS renvoie l'adresse attendue mais que la page ne s'ouvre pas, poursuivez l'enquête sur la connexion qui suit. Consigner séparément la réponse DNS et la réponse web aide à localiser l'échec avant d'effacer les caches de pages ou de modifier aveuglément les paramètres DNS.