dns

DNS outils

Une référence pratique des types d'enregistrements DNS, du TTL et du calendrier de bascule, de la délégation et des enregistrements TXT liés au courriel — avec l'outil de recherche à saisir quand un nom refuse de se résoudre.

1 outils

§01 GUIDE DU DOMAINE

Le DNS est une hiérarchie de caches, pas une base de données

Quand vous « changez un enregistrement DNS », vous modifiez une zone sur un jeu de serveurs de noms autoritaires — et presque personne ne lit cette zone. Les réponses de vos utilisateurs viennent de résolveurs récursifs (celui d’un FAI, 8.8.8.8, un résolveur d’entreprise, le point de terminaison DoH propre à un navigateur), chacun détenant une copie qui expire selon son propre calendrier. Il y a une réponse autoritaire et N approximations en cache de celle-ci — plus votre propre portable, dont le cache système et le /etc/hosts supplantent tout le reste.

La résolution démarre à la racine : un résolveur froid interroge un serveur racine au sujet de www.example.com, est renvoyé vers les serveurs de noms de .com, puis vers les enregistrements NS que le registraire a publiés pour example.com. Chaque maillon de cette chaîne de délégation est lui-même un enregistrement en cache avec son propre TTL, et le jeu NS au niveau du TLD est généralement mis en cache 1 à 2 jours — ce qui explique pourquoi changer de fournisseur DNS ne ressemble en rien à changer un enregistrement A.

La « propagation » est donc un abus de langage : rien n’est poussé, les anciennes réponses expirent simplement — y compris les négatives. NXDOMAIN est mis en cache pendant l’intervalle dérivé du SOA de la zone (couramment 300–3600 s) : un nom peut donc sembler manquant plusieurs minutes après sa création.

Les types d’enregistrements que vous manipulez réellement

Type	Contient	Usage typique	À surveiller
`A`	une adresse IPv4	nom → hôte	plusieurs `A` = répartition en tourniquet, pas du basculement
`AAAA`	une adresse IPv6	double pile	un `AAAA` cassé casse les clients qui préfèrent IPv6
`CNAME`	un autre nom	CDN, points de terminaison SaaS	illégal à l’apex ; exclut les autres enregistrements
`MX`	hôte de messagerie + priorité	courriel entrant	le plus petit nombre gagne ; un hôte, jamais une IP
`TXT`	chaînes libres	SPF, DKIM, DMARC, vérification	255 caractères par chaîne ; les longues clés sont découpées
`NS`	serveurs de noms délégués	délégation de zone	c’est le jeu chez le parent qui compte
`SOA`	minuteurs de zone, numéro de série	TTL du cache négatif	`MINIMUM` fixe la durée de vie du `NXDOMAIN`
`PTR`	nom associé à une adresse	DNS inverse, réputation d’expéditeur	`in-addr.arpa` (IPv4) / `ip6.arpa` (IPv6) ; propriété du détenteur de l’IP
`CAA`	AC autorisées	contrôle de l’émission	vérifié à l’émission, pas à la poignée de main TLS
`DS` / `DNSKEY`	ancres DNSSEC	délégation signée	un `DS` périmé après une rotation de clé = échec total

TTL, bascules et fenêtres de retour arrière

Choisissez les TTL selon la vitesse à laquelle vous pourriez devoir bouger : 60 pour un enregistrement que vous pourriez repointer en quelques minutes, 300–900 pendant une migration, 3600 en régime stable, 86400 pour les NS et MX que vous ne touchez jamais. Les TTL courts ne sont pas gratuits — ils multiplient le volume de requêtes et réduisent le tampon qui vous protège si les serveurs autoritaires deviennent injoignables.

Le retour arrière compte autant que la bascule : un TTL en cache est un plancher sur la récupération, si bien qu’un TTL de 300 s maintient les derniers résolveurs pointés vers un point de terminaison mort pendant cinq minutes après votre publication. Deux événements de ce type par mois représentent environ 10 minutes d’indisponibilité, et le Calculateur SLA montre si cela tient — 99,99 % autorise 4,3 minutes par mois de 30 jours. Davantage de budgétisation sur la page outils SRE.

Ce que SPF, DKIM et DMARC prouvent chacun

Mécanisme	Publié comme	Un succès prouve	Ne prouve pas
SPF	`TXT` au domaine, `v=spf1 …`	l’IP qui se connecte peut émettre pour le domaine d’enveloppe `MAIL FROM`	rien sur le `From:` visible ; casse lors des transferts
DKIM	`TXT` à `sélecteur._domainkey.domaine`, `v=DKIM1; p=…`	en-têtes signés et corps inaltérés depuis que `d=` les a signés	que `d=` soit votre domaine ; des en-têtes non signés peuvent être ajoutés
DMARC	`TXT` à `_dmarc.domaine`, `v=DMARC1; p=…`	SPF ou DKIM a réussi et ce domaine s’aligne avec le `From:`	l’application — `p=none` ne demande que des rapports

Des trois, seul l’enregistrement SPF à l’apex est lisible avec DNS Lookup : son onglet TXT montre la chaîne v=spf1 que vous avez publiée, mais l’outil n’accepte que des étiquettes de nom d’hôte, si bien que les noms à tiret bas comme _dmarc.example.com et selector._domainkey.example.com sont rejetés avec Invalid domain format. Lisez ceux-là avec dig TXT _dmarc.example.com ou depuis l’éditeur de zone de votre fournisseur DNS. Ce qu’un destinataire a conclu est une autre question, et Analyse d’En-têtes y répond depuis les en-têtes Authentication-Results, Received-SPF, DKIM-Signature et ARC d’un message délivré. Avant d’ajouter un mécanisme ip4:, confirmez l’adresse depuis laquelle votre trafic part réellement avec Vérifier IP plutôt que de faire confiance à un fichier de configuration. Si un enregistrement DKIM a été reconstitué depuis des chaînes découpées, collez la valeur p= dans Base64 : il rejette les caractères parasites et le remplissage cassé, ce qui attrape une clé abîmée. Plus sur les en-têtes d’authentification : le hub courriel.

Quel outil pour quel travail

Étant donné un domaine, DNS Lookup résout A, AAAA, CNAME, MX, TXT et NS en une seule requête, en imprimant TYPE / NAME / VALUE / TTL avec la priorité MX ; les onglets de type filtrent les lignes déjà récupérées côté client, si bien que passer de MX à TXT ne coûte aucune requête supplémentaire. CNAME n’a pas d’onglet propre : ces lignes — celles qui vous disent qu’un nom est un alias plutôt qu’une adresse — apparaissent dans la vue ALL. Lisez la barre d’état au pied de la lettre : SERVER est toujours api.sitekits.dev et LATENCY est l’aller-retour navigateur→API, ni le résolveur récursif qui a répondu ni le temps de requête DNS. La résolution s’exécute côté serveur via Cloudflare DoH, ce qui vous donne un point d’observation hors de votre propre cache ; pour identifier quel résolveur a répondu, interrogez-en un directement avec dig @8.8.8.8 example.com. Étant donné une URL à la place, Parseur d’URL isole hostname de host (qui inclut le port), localement, sans rien charger.

Quand les enregistrements sont corrects mais que le mauvais contenu est servi, ce n’est plus du DNS : En-têtes HTTP charge côté serveur et renvoie le statut, la chaîne de redirections et chaque en-tête de réponse — de quoi séparer « toujours l’ancienne IP » de « bonne IP, cache CDN périmé ». Il ne récupère jamais le corps et refuse les adresses privées.

Le DNS ne transporte que des étiquettes ASCII, aussi Convertisseur IDN montre la forme xn-- réellement interrogée, ce qui démasque également les sosies homographes. Des valeurs AAAA qui semblent différentes ne le sont souvent pas : Compression IPv6 normalise les deux écritures et développe les groupes dont un nom ip6.arpa a besoin. Prenez un instantané d’une zone avant une migration et comparez avant/après dans Diff de Texte.

Les pièges qui coûtent des heures

`CNAME` à l’apex de la zone

example.com doit détenir SOA et NS, et un CNAME ne peut pas coexister avec d’autres enregistrements au même nom — un CNAME à l’apex est donc invalide quoi qu’accepte le panneau de contrôle. ALIAS/ANAME et l’aplatissement sont des fonctionnalités de fournisseur, pas du protocole.

Deux enregistrements SPF au lieu d’un

Un second enregistrement TXT v=spf1 au même nom produit un permerror. Fusionnez tous les mécanismes en un seul enregistrement, et comptez les recherches : include:, a, mx, ptr, exists et redirect= consomment chacun l’une des 10 recherches DNS qu’une évaluation autorise (RFC 7208 §4.6.4) — un plafond que des chaînes de prestataires empilées font sauter silencieusement.

Noms relatifs et points finaux manquants

Dans la syntaxe des fichiers de zone, une cible sans point final est relative : www.example.com devient donc www.example.com.example.com. — exactement ce qui se produit quand vous collez une cible pleinement qualifiée dans une interface qui ajoute déjà la zone.

Enregistrements orphelins pointant vers des services récupérés

Un CNAME encore dirigé vers un bucket, une plateforme applicative ou un nom d’hôte CDN décommissionné peut être revendiqué par quiconque enregistre ce nom ensuite, ce qui livre à un attaquant un sous-domaine qui est le vôtre — voyez les outils sécurité.

FAQ

Pourquoi mon changement DNS met-il des heures à apparaître ?

Parce que le TTL qui gouverne l'attente est celui déjà mis en cache, pas celui que vous venez de publier. Si l'ancien enregistrement avait un TTL de 86400 et qu'un résolveur l'a mis en cache une minute avant votre modification, ce résolveur continue de servir l'ancienne valeur pendant près de 24 heures. Abaissez le TTL à 300 au moins une période complète de l'ancien TTL avant un changement planifié, puis basculez l'enregistrement.

Pourquoi des requêtes atteignent-elles encore mon ancien fournisseur DNS des jours après avoir changé de serveurs de noms ?

Parce que la délégation elle-même est mise en cache, et son expiration ne vous appartient pas. Le jeu NS que votre registraire publie au niveau du TLD est généralement servi avec un TTL d'un à deux jours : un résolveur qui a récupéré l'ancienne délégation peu avant le changement continue donc d'interroger les anciens serveurs de noms jusqu'à ce que cette copie expire. Abaissez au préalable les TTL des enregistrements à l'intérieur de la zone — c'est la partie que vous contrôlez — et gardez l'ancienne zone en ligne et identique pendant au moins 48 heures après la bascule.

Puis-je mettre un CNAME sur mon domaine racine ?

Pas en DNS standard. Un CNAME ne peut pas coexister avec d'autres enregistrements au même nom, et l'apex de la zone doit porter des enregistrements SOA et NS : un CNAME à l'apex est donc invalide. Les fournisseurs contournent cela avec des enregistrements non standard ALIAS/ANAME ou par aplatissement de CNAME, qui résolvent la cible au moment de la requête et répondent avec des données A/AAAA.

Je viens de créer un enregistrement — pourquoi renvoie-t-il encore NXDOMAIN ?

Parce que les réponses négatives sont aussi mises en cache. Un résolveur à qui l'on a dit que le nom n'existait pas conserve ce verdict pendant l'intervalle dérivé de l'enregistrement SOA de la zone, couramment de 300 à 3600 secondes, et rien de ce que vous publiez ensuite n'efface une réponse négative déjà détenue — abaissez donc le minimum du SOA à l'avance si vous prévoyez de créer des noms un par un. Pour distinguer un cache périmé d'une véritable erreur, interrogez un résolveur qui n'a jamais vu la requête antérieure, avec dig @8.8.8.8 ou depuis un autre réseau.

Pourquoi deux vérificateurs DNS montrent-ils des résultats différents pour le même enregistrement ?

Chacun interroge un résolveur récursif différent, et chaque copie en cache expire sur sa propre horloge : un désaccord en cours de changement est donc normal jusqu'à l'expiration du TTL en cache le plus long. Un désaccord persistant signifie autre chose : du GeoDNS ou de l'EDNS Client Subnet répondant selon la localisation de la requête, du DNS à horizon partagé renvoyant des adresses internes au sein d'un réseau d'entreprise, ou un résolveur détenant encore une ancienne délégation NS.