Préparer les noms DNS et leur bascule

Avant de basculer un nom de service vers une nouvelle origine, il faut savoir distinguer ce que répond l'autorité d'un domaine de ce que répond le résolveur réellement utilisé par un client, et prévoir l'effet des caches et d'une adresse IPv6 oubliée. Cette leçon suit Lire HTTP avant de configurer un proxy et ouvre le module « Noms et exposition » de ce socle. Le mécanisme complet du DNS (résolution en cinq étapes, types d'enregistrements, dig, diagnostic NXDOMAIN et SERVFAIL) est déjà couvert par Comprendre le DNS, l'annuaire d'Internet : cette leçon s'appuie dessus et se concentre sur un seul geste, préparer une bascule qui ne ment pas sur ce qu'elle prouve.

Ce que vous allez apprendre

• Vérifier la réponse autoritaire d'une zone et celle du résolveur réellement utilisé par un client, et dire ce que chacune prouve
• Préparer une bascule de nom en tenant compte des caches et de la double pile IPv4/IPv6
• Expliquer pourquoi le DNS ne choisit jamais le chemin HTTP, et pourquoi tester avec --resolve ne valide pas une publication

Prérequis

Cette leçon suppose Lire HTTP avant de configurer un proxy et les bases du DNS couvertes par Comprendre le DNS, l'annuaire d'Internet (zone, délégation, serveur autoritaire, résolveur récursif, cache, enregistrements A, AAAA et CNAME) : cette leçon ne les réexplique pas, elle rappelle seulement en une phrase les deux rôles dont elle se sert le plus, juste ci-dessous.

Que prouve une réponse autoritaire, que ne prouve pas une réponse en cache ?

La réponse d'un serveur autoritaire dit ce qui est réellement publié maintenant ; la réponse d'un résolveur en cache dit seulement ce qu'il a retenu lors de sa dernière question, qui peut être périmé. Une bascule réussie du point de vue de l'autorité (la nouvelle valeur y apparaît) peut rester invisible pour une partie des utilisateurs tant que leurs résolveurs n'ont pas revérifié la zone, ce que le TTL (Time To Live) de l'enregistrement détermine : plus il est bas, plus vite les caches reviennent interroger l'autorité.

Rappel des deux rôles : le serveur autoritaire d'une zone détient la source des enregistrements (c'est lui qui fait foi pour ce nom) ; le résolveur est le serveur que le poste du client interroge à sa place, et qui garde en cache les réponses déjà obtenues.

Préparer une bascule demande donc de vérifier les deux niveaux séparément : l'autorité (avec dig +trace, détaillé dans le guide DNS cité plus haut) confirme que la nouvelle valeur est bien publiée ; un résolveur public, puis le résolveur réellement configuré sur un poste client, confirment que ce client verra la nouvelle valeur. Un plan de bascule complet abaisse le TTL, attend l'expiration de l'ancien TTL, change la valeur, vérifie l'autorité, puis attend le nouveau TTL (court) avant de considérer la bascule acquise pour tous les clients ; la section « Comment abaisser le TTL avant une bascule » plus bas détaille cet ordre. Le retour arrière suit la même logique en sens inverse : republier l'ancienne valeur ne la rend disponible à tous qu'après un nouveau délai de TTL, jamais immédiatement.

Que montre dig quand on interroge l'autorité, puis un résolveur ?

Le drapeau aa (authoritative answer) de la réponse dig distingue les deux cas : il est présent quand l'autorité répond, absent quand un résolveur répond depuis son cache. Le serveur autoritaire se trouve en interrogeant les enregistrements NS de la zone, puis en lui posant la question directement. Relevé réel du 2026-10-25 sur la zone stephane-robert.info :

dig +noall +answer NS stephane-robert.info @1.1.1.1

stephane-robert.info.  172800  IN  NS  ns-1524.awsdns-62.org.
stephane-robert.info.  172800  IN  NS  ns-1661.awsdns-15.co.uk.
stephane-robert.info.  172800  IN  NS  ns-216.awsdns-27.com.
stephane-robert.info.  172800  IN  NS  ns-984.awsdns-59.net.

Le TTL de 172800 s (48 heures) est celui de la délégation (les enregistrements NS, qui désignent les serveurs autoritaires de la zone) : il est long, et ce n'est pas celui de l'enregistrement A. On interroge ensuite le premier serveur autoritaire avec @, puis on compare les drapeaux de la réponse avec ceux d'un résolveur public :

dig @ns-1524.awsdns-62.org. www.stephane-robert.info A | grep '^;; flags'
dig @1.1.1.1 www.stephane-robert.info A | grep '^;; flags'

;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

Sur la première ligne, aa signale que le serveur interrogé détient la zone ; sur la seconde, ra (recursion available) signale un serveur qui propose la récursion, donc un résolveur. Ne le confondez pas avec rd (recursion desired), que le client pose dans sa question et qui figure dans les deux réponses. L'autorité publie un TTL de 60 s pour l'enregistrement A (les résolveurs en servent un égal ou inférieur, 39 s dans un de mes relevés), mais les adresses diffèrent : l'autorité a répondu 18.165.201.x et les résolveurs 18.155.129.x, avec un ordre qui change d'un appel à l'autre. Les deux plages appartiennent à Amazon CloudFront (relevé whois), mais la cause de cet écart n'a pas été établie : c'est une observation, pas une explication. La leçon reste valable : deux réponses ne se comparent pas par égalité d'adresses, mais par ce qu'elles disent de la publication. Le test juste est de vérifier que la valeur attendue figure dans l'ensemble renvoyé, pas qu'elle arrive en première position.

Toutes les valeurs de ces captures (adresses, TTL, ordre des réponses, noms des serveurs) sont celles du relevé du 2026-10-25 : les vôtres différeront, et c'est normal. Ce qui doit se reproduire chez vous, c'est la présence ou l'absence des drapeaux aa et ra. Pour refaire la mesure sur votre propre domaine, remplacez stephane-robert.info et le serveur @ns-... par les vôtres.

Comment le TTL décroît-il dans un résolveur ?

Un résolveur qui a mis une réponse en cache la resserve avec un TTL décroissant : le nombre affiché est le temps restant avant que le résolveur revienne interroger l'autorité. Relevé réel, une question toutes les cinq secondes à deux résolveurs, le résolveur local du poste (127.0.0.53) puis la box du réseau local (192.168.1.1, le routeur qui fait résolveur) :

### resolveur 127.0.0.53
t=00s  TTL 60 18.155.129.9
t=05s  TTL 54 18.155.129.43
t=10s  TTL 49 18.155.129.49
t=15s  TTL 44 18.155.129.43
### resolveur 192.168.1.1
t=00s  TTL 40 18.155.129.9
t=05s  TTL 35 18.155.129.43
t=10s  TTL 30 18.155.129.23
t=15s  TTL 25 18.155.129.49

Le premier résolveur partait d'un cache vide : sa première réponse venait de l'autorité avec le TTL plein de 60 s, puis le compte à rebours a démarré. Le second avait déjà la réponse en cache, d'où un départ à 40 s. À ce rythme, chacun relirait la zone à l'expiration, et un changement de valeur n'y serait visible qu'à ce moment-là.

Un résolveur public ne décroît pas toujours proprement

Le même test contre 1.1.1.1, une question toutes les dix secondes pendant une minute, a renvoyé TTL 60 à chaque fois : un résolveur public à grande échelle répartit en général les questions sur de nombreux caches (la cause exacte n'a pas été isolée sur ce relevé). Pour observer un compte à rebours, interrogez un résolveur unique (celui de votre poste ou de votre réseau), pas un service anycast, c'est-à-dire une même adresse servie par de nombreuses machines réparties dans le monde.

Comment abaisser le TTL avant une bascule, et que subit-on malgré tout ?

On abaisse le TTL au moins la durée de l'ancien TTL avant de changer la valeur, parce que seuls les caches qui ont déjà relu la zone avec le TTL court expireront vite. La RFC 1034 (section 3.6) définit le TTL comme la durée pendant laquelle un enregistrement peut être conservé en cache, et indique qu'on peut l'abaisser avant un changement prévu pour réduire l'incohérence (la RFC 1035, section 4.1.3, donne le format du champ) : un cache qui a stocké la valeur avec 3600 s la gardera jusqu'à 3600 s, quoi que vous publiiez ensuite. Sans l'attente, le pire cas d'une bascule est donc la valeur de l'ancien TTL ; avec elle, il tombe au nouveau.

Le schéma suivant montre la chronologie. Regardez les deux attentes : la première (②) est celle qu'on oublie, alors que c'est elle qui rend la seconde (④) courte.

Étape ② : on attend l'ancien TTL. Étape ④ : on attend le nouveau, court. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

À quoi ressemble une bascule avec un cache, relevée pas à pas ?

Avec un serveur autoritaire et un résolveur de test, on voit le cache resservir l'ancienne valeur après le changement, puis basculer à l'expiration du TTL. Ce banc ne demande aucun droit particulier : deux instances de dnsmasq sur le poste, l'une jouant l'autorité du nom de test boutique.test (TTL de 20 s), l'autre jouant le résolveur à cache. C'est un modèle réduit pour voir le mécanisme du TTL, pas une mesure d'Internet : ce relevé avant/après vient d'un banc local et n'est pas transposable tel quel à une bascule publique (voir la section suivante) :

dnsmasq --no-daemon --no-resolv --no-hosts --port=5353 \
  --listen-address=127.0.0.1 --bind-interfaces \
  --address=/boutique.test/192.0.2.10 --local-ttl=20 &
dnsmasq --no-daemon --no-resolv --no-hosts --port=5354 \
  --listen-address=127.0.0.1 --bind-interfaces \
  --server=127.0.0.1#5353 --cache-size=100 &

Le port 5353 est l'autorité, le 5354 le résolveur à cache. Version mesurée : dnsmasq 2.90. Par défaut, dnsmasq répond à une entrée --address avec un TTL de 0 ; --local-ttl=20 fixe les 20 s. --cache-size règle la taille du cache (150 noms par défaut, 0 le désactive). On interroge les deux, on change la valeur côté autorité (en arrêtant la première instance, par kill %1 dans le même terminal, puis en la relançant avec --address=/boutique.test/192.0.2.20), puis on réinterroge. Voici le relevé réel ; les durées exactes varieront un peu chez vous :

--- t=0  autorite (5353) :
boutique.test.    20  IN  A  192.0.2.10
--- t=0  resolveur (5354), premiere question :
boutique.test.    20  IN  A  192.0.2.10
--- zone modifiee. autorite (5353) :
boutique.test.    20  IN  A  192.0.2.20
--- resolveur (5354), juste apres :
boutique.test.    19  IN  A  192.0.2.10
--- resolveur, +9 s :
boutique.test.    11  IN  A  192.0.2.10
--- resolveur, +23 s :
boutique.test.    20  IN  A  192.0.2.20

Lisez les lignes dans l'ordre. Juste après le changement, l'autorité dit 192.0.2.20 et le résolveur dit encore 192.0.2.10 avec 19 s restantes : la nouvelle valeur est publiée, mais invisible pour qui passe par ce cache. À +9 s il reste 11 s, la valeur est toujours l'ancienne. À +23 s le cache a expiré, il a relu l'autorité et sert 192.0.2.20 avec un TTL de nouveau plein. La fenêtre d'incohérence a duré exactement le TTL restant, pas une seconde de plus.

Que maîtrise-t-on dans un cache administré, et que subit-on sur Internet ?

Dans un cache que vous administrez, vous pouvez le vider ; sur Internet, vous ne pouvez que choisir le TTL, et attendre. Le banc ci-dessus est un cache administré : une commande de purge ferait basculer immédiatement, ce qui est utile en test, mais ne prouve rien sur une bascule publique. Les résolveurs des fournisseurs d'accès, des entreprises et des navigateurs de vos utilisateurs échappent à tout contrôle.

Situation	Ce que vous maîtrisez	Ce que vous subissez
Cache administré (votre résolveur, un banc de test)	Vider le cache, forcer la relecture	Rien : la bascule est visible à la demande
Résolveurs d'Internet (FAI, entreprises, navigateurs)	Le TTL publié, et le moment où vous l'abaissez	Le moment où chaque cache relit la zone, et les caches qui gardent plus longtemps que le TTL

Glissez pour voir

Un TTL court ne garantit donc pas une bascule instantanée pour tous : certains équipements gardent une valeur plus longtemps que demandée. La parade est la préparation (abaisser tôt, laisser l'ancienne origine fonctionnelle pendant toute la fenêtre), pas la promesse d'une coupure nette.

Retenez donc la limite du banc : il montre comment un TTL se comporte, pas combien de temps une vraie bascule mettra à être vue par tous vos utilisateurs. Cette durée-là dépend des caches que vous ne contrôlez pas.

Pourquoi un AAAA oublié peut-il casser une bascule qui semble réussie ?

Un client qui a reçu une adresse AAAA (IPv6) pour un nom tentera cette adresse en premier, même si seule l'adresse A (IPv4) a été mise à jour vers la nouvelle origine. La plupart des piles réseau modernes préfèrent IPv6 quand les deux familles répondent : si l'ancienne origine garde un enregistrement AAAA actif pendant qu'un nouvel enregistrement A pointe vers la nouvelle origine, une partie des clients continue de joindre l'ancienne machine par IPv6, sans qu'aucune erreur ne le signale.

Un nom publié à la fois en A et en AAAA est dit en double pile (IPv4 et IPv6 ensemble). Une bascule complète vérifie donc les deux familles d'adresses avant et après le changement, pas seulement celle qu'on a modifiée en premier. Une requête par famille suffit, en interrogeant l'autorité (A puis AAAA) :

dig +noall +answer @ns-1524.awsdns-62.org. www.stephane-robert.info AAAA | head -2

www.stephane-robert.info.  60  IN  AAAA  2600:9000:23d3:a000:12:8443:85c0:93a1
www.stephane-robert.info.  60  IN  AAAA  2600:9000:23d3:d600:12:8443:85c0:93a1

La réponse comptait huit adresses IPv6 ; seules les deux premières sont montrées. Si dig ... AAAA renvoie des lignes alors que vous n'avez préparé que l'A, le nom reste joignable en IPv6 vers l'ancienne origine. Si le service ne doit plus être joignable en IPv6 sur l'ancienne origine, retirer l'enregistrement AAAA fait partie de la bascule, au même titre que modifier l'enregistrement A : oublier l'un des deux revient à ne basculer qu'une moitié du trafic.

Pourquoi le DNS ne choisit-il jamais le chemin HTTP ?

Le DNS répond à une seule question, quelle adresse IP correspond à ce nom ; il ne sait rien du chemin que suivra ensuite la requête HTTP, ni du certificat qui sera présenté, ni de la route choisie derrière cette adresse. C'est la première erreur à écarter avant de préparer une bascule : changer un enregistrement DNS change la destination réseau d'une requête, pas la façon dont un éventuel reverse proxy choisira ensuite son certificat par le SNI (le nom demandé, annoncé au début de la connexion TLS) ou sa route par l'en-tête Host (le nom demandé, écrit dans la requête HTTP), deux décisions détaillées dans Lire HTTP avant de configurer un proxy et dans Publier un service web. Un nom qui résout vers la bonne adresse peut très bien aboutir à une erreur de certificat ou de routage une fois la connexion ouverte : ce sont deux diagnostics distincts, et confondre les deux fait chercher du côté du DNS un problème qui vit une étape plus loin.

Un enregistrement CAA, qui restreint les autorités de certification autorisées à émettre pour un domaine, vit dans la zone DNS mais concerne l'émission de certificat, pas la résolution elle-même : Certificats automatiques en détaille le fonctionnement et les pièges associés.

Pourquoi un test avec --resolve ne valide-t-il pas une publication ?

L'option --resolve d'un client comme curl force manuellement l'association entre un nom et une adresse IP, en court-circuitant totalement le DNS : elle prouve qu'une machine répond à cette adresse, pas qu'un client réel atteindra la bonne adresse en résolvant le nom lui-même. C'est la seconde erreur à écarter : un test qui passe avec --resolve pendant qu'un enregistrement DNS n'est pas encore publié, ou pointe encore vers l'ancienne origine, donne une fausse confiance. Il confirme seulement que le serveur de destination répond correctement une fois qu'on y arrive, ce qui est utile pour isoler un problème, mais il ne dit rien du chemin que prend réellement un client qui, lui, commence toujours par interroger son résolveur.

Le contraste se voit avec un nom inexistant dans tout DNS (le suffixe .invalid est réservé par la RFC 2606 pour cela) et un serveur local sur le port 18105. Voici le relevé réel :

curl -s -o /dev/null -w 'code %{http_code}\n' \
  --resolve boutique.invalid:18105:127.0.0.1 http://boutique.invalid:18105/
curl -sS -o /dev/null -w 'code %{http_code}\n' http://boutique.invalid:18105/
dig @1.1.1.1 boutique.invalid A | grep 'HEADER'

code 200
curl: (6) Could not resolve host: boutique.invalid
code 000
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52492

Avec --resolve, le test réussit (200) alors que le nom n'est publié nulle part ; sans, le client réel échoue (curl code 6, NXDOMAIN côté résolveur, c'est-à-dire « ce nom n'existe pas »). Un test qui n'a qu'une de ces deux lignes ne dit pas la même chose que l'autre. (Le id de la dernière ligne change à chaque appel.)

Valider une bascule exige donc, à un moment du processus, un test qui laisse le client résoudre le nom lui-même, sans --resolve ni fichier hosts modifié : c'est la seule façon de constater ce qu'un utilisateur réel obtiendra, caches de résolveur compris.

Le lab vous fait diagnostiquer un enregistrement, puis le basculer sans interrompre le service, en vérifiant ce que voit un client qui résout lui-même.

Lab guidé Pratique

Apprendre à faire

Diagnostiquer et basculer un enregistrement DNS

$ dsoxlab run pub-socle-dns

Environnement : VM·Durée : ~30 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start pub-socle-dns vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/publier-service-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run pub-socle-dns
dsoxlab check pub-socle-dns

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• Une réponse autoritaire confirme ce qui est publié ; une réponse de résolveur en cache ne confirme que ce qu'il a retenu, sous réserve du TTL.
• Un plan de bascule abaisse le TTL, attend l'expiration de l'ancien TTL, change la valeur, vérifie l'autorité, puis attend le nouveau TTL court ; le retour arrière suit la même logique.
• Dans un cache que vous administrez vous pouvez purger ; sur Internet vous ne pouvez que choisir le TTL, et attendre. Le banc dnsmasq de la leçon montre le mécanisme, pas la durée d'une bascule publique.
• Un enregistrement AAAA oublié peut laisser une partie des clients joindre l'ancienne origine en IPv6 pendant que l'enregistrement A pointe vers la nouvelle.
• Le DNS choisit une adresse IP, jamais un chemin HTTP, un certificat ou une route derrière cette adresse.
• Un test avec --resolve contourne le DNS : il ne prouve jamais qu'une publication est correcte pour un client réel.

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →