Anatomie d’une zone DNS

La zone, pas le domaine entier

Le domaine que vous achetez est un nom. La zone est le paquet d’enregistrements servi ensemble pour ce nom et pour les étiquettes que vous ne déléguez pas. example.com, www.example.com et un éventuel mail.example.com vivent dans la même zone tant qu’aucun NS enfant ne les emporte ailleurs. Un sous-domaine délégué a sa propre zone, son propre SOA, ses propres NS.

Dans une interface d’hébergeur, cette liste apparaît comme un tableau. Dans un fichier de zone, elle apparaît comme des lignes. Sur le réseau, elle apparaît uniquement en réponse à des questions. Personne ne télécharge « la zone » en usage normal : on demande un type à la fois. C’est pour cela qu’un test DNS demande de choisir A, AAAA, MX, TXT, NS, SOA, CNAME, CAA ou SRV, et pas « tout le domaine ».

Deux zones peuvent porter le même contenu copié à la main et quand même diverger d’une minute, le temps qu’un secondaire applique le nouveau numéro de série. Le SOA est fait pour ce suivi. Le reste des types décrit le service.

SOA et NS, le cadre

Le SOA ouvre la zone. Il nomme un serveur primaire, un contact (le premier point du champ remplace l’arobase), un numéro de série, puis quatre durées en secondes : refresh, retry, expire, minimum. Le 23 octobre 2026, 1.1.1.1 renvoyait pour example.com :

example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800

Le contact se lit dns@cloudflare.com. Le série 2418004112 doit augmenter quand la zone change, sinon des secondaires peuvent garder l’ancienne copie. 10000 secondes séparent deux vérifications prévues, 2400 secondes un nouvel essai après échec, 604800 secondes (sept jours) l’expiration si le primaire reste injoignable. Le minimum, 1800 secondes, borne surtout le cache des réponses négatives.

Les NS disent quels serveurs rendent cette zone. Le même jour, la réponse était hera.ns.cloudflare.com et elliott.ns.cloudflare.com, avec un TTL long (81836 secondes vues dans le cache de 1.1.1.1, sur un enregistrement souvent publié à 86400). Le parent, au niveau du registre, publie aussi des NS : ce sont eux qui constituent la délégation. S’ils diffèrent des NS du SOA et de la zone, lisez le guide délégation et registraire.

Le SOA réapparaît dans la section authority quand la réponse est négative. Il ne faut pas le confondre avec une donnée du type demandé. Un CAA absent se présente ainsi : statut NOERROR, answer vide, SOA en authority. C’était le cas d’example.com le 23 octobre 2026.

A, AAAA et CNAME

Le A publie une IPv4. Le AAAA publie une IPv6. Un nom destiné aux humains en a souvent plusieurs, pour répartir les connexions. example.com, le 23 octobre 2026, avait deux A (104.20.23.154, 172.66.147.243) et deux AAAA (2606:4700:10::ac42:93f3, 2606:4700:10::6814:179a). Tester un seul type laisse l’autre famille dans l’ombre.

Le CNAME ne publie pas d’adresse. Il publie un autre nom. Le résolveur continue. Le même jour, www.wikipedia.org était :

www.wikipedia.org. 86400 IN CNAME dyna.wikimedia.org.

Et www.iana.org en type A montrait d’abord le CNAME vers www.iana.org.cdn.cloudflare.net, puis les A de cette cible (104.18.24.232 et 104.18.25.232). La chaîne est normale. Elle devient anormale si la cible n’a ni A ni AAAA, si elle pointe vers un nom absent, ou si l’on a aussi mis un MX sur le nom du CNAME. Ces collisions sont traitées dans le guide CNAME, MX et TXT.

MX, TXT et CAA

Le MX désigne les hôtes qui reçoivent le courrier, avec une préférence numérique. wikipedia.org, le 23 octobre 2026, publiait deux MX de préférence 10 : mx-in1001.wikimedia.org et mx-in2001.wikimedia.org. example.com publiait autre chose, volontairement : 0 ., un MX vers la racine, qui signifie « pas de courrier ». Le TXT v=spf1 -all du même domaine refuse aussi l’émission. Les deux se lisent ensemble. Un TXT SPF qui autorise des adresses alors que le MX est nul n’est pas une contradiction de syntaxe DNS, mais c’est une politique incohérente.

Les autres TXT du jour, chez wikipedia.org, mélangeaient une politique SPF (v=spf1 include:_cidrs.wikimedia.org ~all) et des preuves de propriété. Ils coexistent : le DNS ne réserve pas le type TXT à un seul usage. Effacer « les TXT » en bloc pendant une migration efface souvent une preuve encore exigée par un service.

Le CAA parle aux autorités de certification, pas aux navigateurs. wikipedia.org autorisait letsencrypt.org et pki.goog, et publiait un contact iodef vers mailto:dns-admin@wikimedia.org. Sans CAA, les AC ne sont pas limitées par le DNS. Avec un CAA trop étroit, le renouvellement automatique échoue alors que le site, lui, répond encore. C’est une panne de certificat, dont la cause est un enregistrement.

SRV, et comment lire une ligne

Le SRV localise un service : priorité, poids, port, cible. Son nom commence d’habitude par le service et le protocole, par exemple _sip._tcp. On ne le confond pas avec le A du site. Une réponse vide en SRV sur un nom qui n’a jamais annoncé ce service est un NODATA, pas une raison de supprimer les adresses web.

Chaque ligne dig se lit dans le même ordre : nom, TTL, classe, type, données. Le TTL est une durée de cache. La classe IN est celle d’Internet. Le type est celui que vous avez demandé, ou un CNAME rencontré en chemin. Les données dépendent du type : une adresse, un nom, une préférence suivie d’un nom, un texte entre guillemets, un SOA en sept champs. Le point final d’un nom dans la réponse marque la racine. Il fait partie de la notation, pas d’une faute de frappe.

Pour parcourir une zone inconnue, un ordre efficace est : NS, SOA, A et AAAA du sommet et de www, MX, TXT du sommet, CAA, puis les CNAME qui apparaissent. Le lexique reprend chaque sigle, et l’outil permet de refaire le relevé sur le nom qui vous occupe, type par type.