Pourquoi une zone privée Route 53 renvoie NXDOMAIN pour des noms publics

Les zones privées Route 53 remplacent la réponse d’un nom au lieu de fusionner avec l’enregistrement public, et cela surprend les gens au pire moment. Ajoutez un enregistrement interne pour api.example.net dans une zone privée pour example.net, associez-la à un VPC, et tous les autres noms sous ce parent répondent désormais uniquement depuis la zone privée. Un client qui pouvait joindre www.example.net hier reçoit aujourd’hui une réponse négative. Le parcours ci-dessous part de cette requête échouée et remonte vers la zone qui y a répondu.

Partez de la requête, pas de la console

Reproduisez la panne sur le client qui l’a signalée et notez le nom exact et le type d’enregistrement. Un nom qui échoue pour A peut encore se résoudre pour AAAA, et un navigateur qui retente un nom mis en cache masque lequel des deux est cassé. Exécutez la requête deux fois : une fois via le résolveur que le client utilise réellement, et une fois avec un traçage qui le contourne.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

La deuxième commande est la plus importante. Sa ligne d’état et sa section d’autorité nomment la zone qui a produit la réponse, ce qui permet de distinguer une réponse négative de la zone privée d’un délai d’attente, d’un port bloqué ou d’un résolveur qui n’a jamais reçu la requête. resolvectl indique quel serveur amont a été interrogé, et ce n’est souvent pas le résolveur que vous supposiez poussé par le VPN.

Si la requête tracée renvoie l’adresse publique et que la requête normale ne le fait pas, l’enregistrement public est intact et la vue privée répond. Cette seule comparaison décide quelle moitié du reste de cette page vous concerne.

Lisez quelle zone a répondu

Une réponse portant NXDOMAIN avec le SOA de la zone privée dans la section d’autorité est une réponse définitive de cette zone, pas un échec de recherche. Route 53 Resolver a choisi la zone hébergée privée parce que le nom correspondait, n’a ensuite trouvé aucun enregistrement du type demandé, et le comportement documenté est de renvoyer la réponse négative plutôt que de transmettre la question au DNS public.

La sélection suit la spécificité. Avec plusieurs espaces de noms privés qui se chevauchent, la zone correspondante la plus spécifique gagne, et un parent privé plus large n’a pas de seconde chance pour un nom absent de la zone enfant sélectionnée. Les règles de transfert ajoutent une couche, car une règle de résolveur propre à un domaine peut l’emporter sur l’association de la zone hébergée privée. Énumérez les associations et les règles avant de conclure qu’une zone est vide.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Les deux commandes demandent des identifiants pour le compte qui possède la zone, et la seconde a besoin de l’identifiant de zone issu de la première. Remplacez-le par le vôtre ; l’espace réservé ci-dessus n’est volontairement pas réel.

Pourquoi la zone privée gagne

C’est l’association qui rend la zone visible pour un VPC, et c’est le résolveur de ce VPC qui l’applique. Une zone privée non associée au VPC d’où vient le trafic du client n’a aucun effet, tandis qu’une association au mauvais VPC produit une réponse privée pour la mauvaise population. Vérifiez la liste des associations avant de modifier des enregistrements, car une zone peut être correcte et rester invisible.

Les espaces de noms qui se chevauchent sont la deuxième source de confusion. Une zone privée pour example.net et une zone privée pour api.example.net correspondent toutes deux à une requête API, et la plus spécifique répond. C’est utile quand vous voulez un espace de noms interne étroit, et dangereux quand la zone étroite manque un enregistrement que la plus large possède. Les considérations sur les zones hébergées privées dans la documentation Route 53 décrivent à la fois le comportement de repli et la priorité des règles, et elles valent la lecture avant d’ajouter une deuxième zone qui se chevauche.

Rien de tout cela ne change la zone publique. Les résolveurs publics continuent de répondre correctement aux enregistrements publics, et c’est pourquoi la panne ressemble à un problème de client pour tous ceux qui sont hors du VPC.

Choisissez l’espace de noms avant d’ajouter des enregistrements

Si seule une nouvelle famille de services internes a besoin de noms privés, donnez-lui un sous-domaine privé dédié et laissez le parent public tranquille. Un nom comme internal.example.net ne peut pas masquer www.example.net, et le rayon d’impact d’un enregistrement absent se limite aux noms que vous avez inventés pour la circonstance. Le coût est que les URL et les certificats existants peuvent ne pas correspondre au nouveau nom.

Lorsque les utilisateurs publics et privés doivent conserver le même nom d’hôte, le DNS à vue scindée est la conception prise en charge et il exige de maintenir les enregistrements dans chaque vue de façon explicite. Une zone privée large avec un seul enregistrement ne préserve pas les dépendances publiques sous cette zone ; elle les remplace par une zone qui a un enregistrement.

Inventoriez les noms qu’une application appelle réellement avant de diriger une population de clients vers la vue privée. Les hôtes de connexion, les hôtes de ressources statiques, les cibles de redirection et les points de terminaison API sont les premiers à casser, et ils sont généralement répartis entre les enregistrements de plusieurs équipes.

Suivez le chemin du résolveur, puis la route

Un ordinateur portable ne voit la vue privée que si ses requêtes atteignent le résolveur qui porte l’association. Modifier un fichier hosts sur le serveur VPN ne publie rien pour les clients connectés, et un client configuré avec un résolveur public continuera de recevoir des réponses publiques tant que le tunnel est monté. Confirmez l’adresse du résolveur reçue par le client, puis répétez la requête depuis le client plutôt que depuis le serveur.

Une fois le nom résolu, testez le chemin vers l’adresse renvoyée comme une étape distincte, par exemple avec ip route get contre l’adresse renvoyée par la requête. Une réponse privée correcte sans route vers l’adresse est un problème de routage, et une réponse d’enregistrement absent est un problème de vue DNS ; les traiter comme un seul sujet produit des correctifs qui ne tiennent pas. Laissez les vérifications du nom d’hôte TLS et du certificat inchangées, car une adresse privée change où va la connexion et rien sur quel certificat est valide.

Terminez en consignant dans la note de changement la zone, l’association, le résolveur et les noms que vous avez vérifiés. La prochaine personne qui ajoute un enregistrement saura alors quel espace de noms fait autorité pour cette population de clients.