Enregistrements Route 53 qui ne résolvent pas : propagation, serveurs NS et ordre de débogage

Quand un enregistrement fraîchement créé dans Route 53 refuse de résoudre, « attendre la propagation » est presque toujours le mauvais diagnostic. Route 53 pousse les changements vers ses serveurs de noms autoritaires en moins d’une minute — dès que le statut du changement affiche INSYNC, l’enregistrement est en ligne à la source. S’il ne résout toujours pas après ça, la cause est presque toujours structurelle : le registraire délègue vers d’autres serveurs de noms que ceux de la zone hébergée que vous avez modifiée, une zone hébergée en double existe, ou un résolveur a mis en cache une réponse négative avant la création de l’enregistrement.

Ce qui se passe

La résolution DNS de votre domaine est une chaîne de délégation : le registraire indique au monde quels serveurs de noms font autorité (les enregistrements NS au registre), et Route 53 ne répond aux requêtes que si ces NS pointent vers les quatre serveurs awsdns assignés à votre zone hébergée. Chaque zone hébergée reçoit son propre ensemble de quatre serveurs à sa création. Supprimez une zone et recréez-la — ou créez une deuxième zone du même nom dans un autre compte — et vous obtenez un ensemble différent. Les enregistrements ajoutés dans une zone que le registre ne délègue pas sont invisibles pour Internet, peu importe combien de temps vous attendez.

Deux autres mécanismes produisent le fameux « ça devrait marcher mais ça ne marche pas ». D’abord, le cache négatif : si un résolveur a demandé le nom avant que vous créiez l’enregistrement, il a mis en cache la réponse NXDOMAIN pour la durée du TTL minimum du SOA de la zone, et continue de servir « n’existe pas » jusqu’à expiration. Ensuite, les zones hébergées privées : une zone privée portant le même nom de domaine, associée à votre VPC, remplace la résolution publique à l’intérieur de ce VPC. Un enregistrement peut donc résoudre depuis votre portable mais pas depuis vos instances EC2 — ou l’inverse.

Le vrai délai de propagation existe, mais dans une seule direction : quand vous modifiez un enregistrement existant, les résolveurs distants continuent de servir l’ancienne valeur jusqu’à expiration de son TTL. C’est du cache de leur côté, et rien du côté AWS ne peut le vider.

Quoi vérifier en premier

Le changement est-il vraiment appliqué? La console montre l’enregistrement; get-change montre INSYNC. Si c’est PENDING, attendez soixante secondes, pas une journée.
Les NS du registre correspondent-ils à ceux de la zone hébergée? C’est la cause numéro un, surtout après une migration ou une recréation de zone.
Y a-t-il plus d’une zone hébergée avec ce nom? Vérifiez chaque compte de l’organisation, et cherchez une zone privée du même nom.
L’échec dépend-il de l’endroit d’où vous testez? Ça fonctionne dans le VPC mais pas dehors (ou l’inverse)? Ça pointe vers une zone privée ou un cache de résolveur, pas vers l’enregistrement.

Comment vérifier

Commencez au registre, puis interrogez directement les serveurs de Route 53, en contournant tous les caches :

# Vers quoi le monde est délégué
dig +short NS example.com @8.8.8.8

# Ce que la zone hébergée pense être ses serveurs de noms
aws route53 list-hosted-zones-by-name --dns-name example.com
aws route53 get-hosted-zone --id Z0123456789ABC \
  --query 'DelegationSet.NameServers'

Si les deux listes diffèrent, arrêtez — vous avez trouvé. Si elles concordent, interrogez un serveur autoritaire directement :

# Contourner tout le cache : demander au serveur assigné de Route 53, sans récursion
dig @ns-123.awsdns-45.com app.example.com A +norec

# Simuler la réponse depuis l'intérieur de Route 53
aws route53 test-dns-answer --hosted-zone-id Z0123456789ABC \
  --record-name app.example.com --record-type A

Une bonne réponse ici, plus une mauvaise réponse de 8.8.8.8, signifie du cache — soit un TTL sur une ancienne valeur, soit un cache négatif sur un nom qui n’existait pas encore. Confirmez le contenu de l’enregistrement dans Route 53 > Hosted zones > example.com, ou :

aws route53 list-resource-record-sets --hosted-zone-id Z0123456789ABC \
  --query "ResourceRecordSets[?Name=='app.example.com.']"

Notez le point final — Route 53 stocke des noms pleinement qualifiés, et l’oublier fait retourner une liste vide.

Le correctif

NS discordants chez le registraire — copiez les quatre serveurs de noms de l’enregistrement NS de la zone hébergée et configurez-les chez le registraire. Si le domaine est enregistré chez Route 53, c’est Route 53 > Registered domains > example.com > Name servers. Les changements de NS au registre ont leur propre TTL (souvent 48 heures au parent), alors celui-là prend réellement du temps.
Zones hébergées en double — décidez quelle zone est canonique, déplacez-y les enregistrements à conserver, supprimez l’autre. Garder les deux invite le prochain ingénieur à modifier la mauvaise encore une fois.
Zone privée qui fait de l’ombre — si la résolution échoue seulement dans le VPC, cherchez une zone privée du même nom. Ajoutez-y les enregistrements manquants, ou retirez l’association au VPC si la zone privée est un vestige.
Cache négatif — rien à corriger; l’enregistrement est bon. Validez contre le serveur autoritaire et attendez l’expiration du TTL minimum du SOA. Tester depuis un résolveur qui n’a jamais vu le nom (un téléphone en cellulaire) le confirme.
Cache périmé après un changement — même histoire : l’ancien TTL doit expirer chez chaque résolveur qui l’a mis en cache. La leçon va dans la liste de prévention — baissez le TTL avant le changement, pas après.
Contenu erroné — une coquille dans le nom, un enregistrement A là où il fallait un alias, ou un enregistrement créé à l’apex au lieu de www. Si la cible est une ressource AWS, un enregistrement alias est habituellement la bonne forme.

Quand c’est la mauvaise approche

Si le domaine n’a jamais résolu du tout — même pas l’apex — vérifiez l’enregistrement du domaine avant de toucher au DNS : un domaine expiré ou un statut clientHold au registre tue la résolution au complet, et aucune modification de zone ne règle ça. Et si dig retourne la bonne réponse partout mais que le site est planté, vous avez quitté le territoire DNS; le problème est la cible, pas le nom. La documentation Route 53 couvre la délégation en détail si vous voulez la chaîne complète.

Erreurs fréquentes

Blâmer la propagation pour ce qui est en fait une discordance de NS, et attendre des jours un correctif qui n’arrivera jamais.
Recréer une zone hébergée en supposant que les anciens serveurs de noms s’appliquent encore — chaque nouvelle zone reçoit un nouvel ensemble de quatre.
Tester en boucle depuis le même résolveur qui a mis la réponse négative en cache, ce qui ne réinitialise rien et ne prouve rien.
Modifier les enregistrements dans le mauvais compte AWS parce que deux comptes détiennent chacun une zone pour le même domaine.

Prévention

Gardez exactement une zone hébergée publique par domaine, dans un seul compte, et documentez où elle vit.
Baissez les TTL à 60 secondes la veille de tout changement planifié, et remontez-les après.
Après chaque changement, confirmez INSYNC avec aws route53 get-change --id <id-du-changement> au lieu de rafraîchir un navigateur.
Après toute migration de registraire ou de zone, comparez les NS du registre avec l’ensemble de délégation de la zone comme test d’acceptation final.
Pour les montages de bascule, combinez TTL bas et vérifications de l’état plutôt que de compter sur des modifications manuelles pendant un incident.

La plupart des billets « propagation » se ferment en dix minutes quand l’ordre de débogage est le bon : délégation au registre d’abord, réponse autoritaire ensuite, caches en dernier. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.