Vous créez un nouveau sous-domaine. L’interface de gestion affiche l’enregistrement, un collègue peut accéder au site, mais votre ordinateur signale toujours NXDOMAIN. La modification a-t-elle échoué ? Pas nécessairement. Un résolveur peut aussi se souvenir qu’un nom n’existait pas auparavant. Cette réponse négative stockée est un état à part entière.
Le guide de dépannage DNS de Cloudflare, mis à jour le 21 octobre 2026, décrit exactement ce cas. Il s’agit d’une explication technique actuelle, et non du lancement d’un nouveau produit DNS. La distinction mérite d’être faite, car plusieurs mémoires totalement différentes disparaissent derrière le mot courant « cache » : réponses DNS, contenus du navigateur et fichiers web mis en cache.
L’inexistence antérieure peut encore être stockée
Un résolveur récursif recherche le nom pour vous. S’il a auparavant reçu une réponse négative, il peut réutiliser cette réponse pendant une durée limitée. Si l’enregistrement est créé entre-temps sur le serveur de noms faisant autorité, le résolveur ne l’apprend pas nécessairement au même moment.
Le nouveau TTL de l’enregistrement A que vous venez de créer ne raccourcit pas rétroactivement cet état négatif existant. Pour la mise en cache négative, les informations SOA de la zone jouent un rôle. La RFC2308 décrit la valeur de départ comme la plus petite entre le TTL du SOA et SOA.MINIMUM. Le temps réellement restant pour une réponse stockée est encore une autre chose.
Notre propre exemple chiffré n’utilise que des valeurs inventées : une entrée négative peut initialement être valide pendant 300 secondes. Au bout de 120 secondes, le véritable enregistrement DNS est créé. Un résolveur pourrait alors encore disposer de 180 secondes de son ancienne réponse. Cela illustre la relation temporelle ; il ne s’agit pas d’une durée mesurée pour Cloudflare ou pour votre domaine.
Deux requêtes en lecture seule séparent source et cache
La première question est : que dit le serveur de noms faisant autorité responsable ? La seconde : que dit le résolveur récursif que votre appareil utilise réellement ? Des réponses différentes peuvent aider à cerner l’erreur. Elles ne prouvent pas automatiquement une mise en cache négative ; les fautes de frappe ou une délégation incorrecte doivent aussi être écartées.
dig @YOUR-AUTHORITATIVE-NAMESERVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A +noall +authorityRemplacez les espaces réservés par les serveurs que vous avez réellement identifiés. Les commandes sont des modèles en lecture seule et n’ont pas été exécutées ici. Examinez ensemble le code de réponse, le nom, le type d’enregistrement et, le cas échéant, les détails SOA. Une réponse pour un hôte à l’orthographe similaire ne constituerait pas une comparaison pertinente.
Notez également l’heure et le résolveur utilisé. Sinon, vous risquez de comparer des chemins différents sans vous en rendre compte. Vider le cache DNS local ne supprime pas automatiquement la réponse stockée d’un résolveur en amont. C’est précisément pourquoi redémarrer le navigateur peut ne pas atteindre l’état que vous observez.
DNS et CDN répondent à des questions différentes
Le DNS aide à résoudre un nom. Un cache CDN, en revanche, garde certains contenus HTTP à disposition. Purger des images ou des feuilles de style mises en cache n’indique pas à un résolveur DNS qu’un nom auparavant inconnu existe désormais. La mesure ne correspond alors tout simplement pas à la couche où se situe le problème.
Le guide de démarrage de Cloudflare pour Cache, mis à jour pour la dernière fois le 12 octobre 2026, décrit également la différence entre proxied et DNS-only : le contenu d’un hôte DNS-only ne passe pas par le cache Cloudflare du seul fait que son DNS y est géré. Un enregistrement DNS existant ne prouve donc pas que du contenu est activement mis en cache.
De DomainStudio à la réponse réelle
Dans KENJTEC DomainStudio ai, vous pouvez gérer vos propres enregistrements DNS avec type, cible et TTL. La solution mise en œuvre utilise Cloudflare pour la gestion de zone. Après une modification, vous devez tout de même juger la résolution d’après les réponses DNS réelles ; « sauvegardé » et « déjà visible auprès de chaque résolveur » sont des affirmations différentes.
Les temps d’attente ne peuvent donc pas être remplacés par une promesse générale de réussite. Vérifiez d’abord l’orthographe, les serveurs de noms responsables et la réponse faisant autorité. Ce n’est qu’ensuite que le temps de cache restant constitue une explication utile. « Le DNS prend juste du temps » devient ainsi un diagnostic traçable, dans lequel chaque observation appartient à la bonne couche technique.
Sources et état
Recherche et documentation à jour au 25 octobre 2026. Problèmes DNS généraux · Premiers pas avec Cache · RFC2308 — Mise en cache négative des requêtes DNS.
