DNS Route 53 et Resolver

Une fonction Lambda dans votre VPC appelle payments.corp.internal et reçoit NXDOMAIN. Le même nom résout en 30 millisecondes depuis votre poste, à travers le VPN d'entreprise. Rien n'a changé dans l'application, l'enregistrement existe, et le DNS « fonctionne » selon tous les tests que vous pouvez imaginer.

L'enregistrement va très bien. Ce qui a changé, c'est le resolver qui a répondu. À l'intérieur d'un VPC, un nom peut être résolu par 3 choses différentes, et elles ne se consultent pas entre elles. Savoir où part une requête, c'est l'essentiel du dépannage Route 53, et c'est ce que l'examen teste vraiment sur ce sujet.

Les hosted zones : le conteneur depuis lequel Route 53 répond

Une hosted zone contient les enregistrements d'un domaine et de ses sous-domaines. Créez une hosted zone pour example.com et vous obtenez un conteneur depuis lequel Route 53 répondra aux requêtes, ainsi que les serveurs de noms qui rendent cette réponse officielle.

Il en existe 2 sortes, et la différence porte sur qui a le droit de demander :

• Une hosted zone publique répond aux requêtes venues d'internet. Route 53 attribue 4 serveurs de noms, et vous pointez votre registrar vers eux avec des enregistrements NS. Cette délégation est ce qui rend Route 53 autoritaire pour le domaine.
• Une private hosted zone ne répond qu'aux requêtes des VPC que vous lui associez. Elle n'est pas joignable depuis internet, et ses enregistrements n'apparaissent jamais dans le DNS public.

Les private hosted zones reçoivent quand même des enregistrements NS, parce que le protocole DNS exige que toute zone en possède, et ce sont toujours les 4 mêmes noms réservés :

ns-0.awsdns-00.com
ns-512.awsdns-00.net
ns-1024.awsdns-00.org
ns-1536.awsdns-00.co.uk

Ces noms sont visibles depuis internet, mais les interroger directement ne renvoie rien sur votre zone. Le VPC Resolver ne les contacte pas davantage. Il reconnaît qu'une requête tombe dans un espace de noms privé grâce à l'association entre le VPC et la hosted zone, et il atteint les données privées directement. Donc « les serveurs de noms sont publics » est à la fois vrai et sans conséquence.

Enregistrements, TTL et la requête que vous ne voyez jamais

Un enregistrement associe un nom et un type à une valeur : www.example.com de type A vers 203.0.113.10. Chaque enregistrement porte un TTL, le nombre de secondes pendant lesquelles un resolver DNS a le droit de garder la réponse en cache avant de redemander.

Le TTL est le champ le plus important d'un enregistrement au quotidien, et on le sous-estime facilement. Mettez-le à 300 et un resolver qui a répondu à un client à 10:00:00 servira la même réponse jusqu'à 10:05:00 sans jamais contacter Route 53. Cela a 3 conséquences que vous retrouverez dans ce sujet :

• Un basculement ou une modification d'enregistrement ne prend effet pour les clients existants qu'à l'expiration de leur copie en cache.
• Les query logs sous-comptent le trafic réel, parfois d'un ordre de grandeur, parce que les réponses servies depuis un cache n'atteignent jamais Route 53.
• Baisser le TTL avant une bascule planifiée, puis le remonter ensuite, est la technique de migration standard.

Les alias records : le raccourci réservé à AWS

Vous voulez que example.com mène à un Application Load Balancer. Le load balancer a un nom DNS, pas une adresse IP stable, donc un enregistrement A avec une adresse figée devient faux le jour où AWS remplace un nœud. La réponse évidente serait un CNAME, et le protocole DNS l'interdit : on ne peut pas créer de CNAME à l'apex de la zone, le nœud le plus haut de l'espace de noms.

L'alias record est l'extension de Route 53 qui comble ce manque. Il ressemble à un enregistrement A ou AAAA pour n'importe quel client, mais sa cible est une ressource AWS que Route 53 résout au moment de la requête.

Les cibles d'alias à reconnaître : les load balancers Elastic Load Balancing (Application, Network et Classic), les distributions CloudFront, les buckets S3 configurés en site statique, les API API Gateway, les VPC interface endpoints, les accélérateurs Global Accelerator, les environnements Elastic Beanstalk, les services App Runner, les noms de domaine AppSync, les domaines OpenSearch Service, et un autre enregistrement du même type dans la même hosted zone.

Deux points pratiques. Les alias records suivent la ressource tout seuls, donc si les adresses du load balancer changent, Route 53 répond avec les nouvelles sans que vous touchiez à quoi que ce soit. Et un alias record peut activer Evaluate Target Health, ce qui apprend à une configuration de failover qu'un load balancer est tombé sans que vous ayez à créer un health check pour lui.

Private hosted zones et les 2 attributs de VPC dont elles dépendent

Créez une private hosted zone, associez un VPC, ajoutez des enregistrements. Les instances de ce VPC résolvent désormais ces noms vers des adresses privées.

Cela échoue en silence si le VPC n'est pas configuré pour. Ces 2 attributs de VPC doivent valoir true :

• enableDnsSupport
• enableDnsHostnames

aws ec2 describe-vpc-attribute --vpc-id vpc-0a1b2c3d --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0a1b2c3d --attribute enableDnsHostnames

aws ec2 modify-vpc-attribute --vpc-id vpc-0a1b2c3d --enable-dns-hostnames

Une private hosted zone accepte jusqu'à 300 VPC associés, y compris depuis d'autres comptes (l'association depuis un autre compte est un flux en 2 temps : autorisation puis association). Au-delà de 300, l'outil prévu est Route 53 Profiles plutôt qu'une augmentation de quota.

Les health checks se comportent différemment ici. Dans une private hosted zone, vous ne pouvez attacher un health check qu'aux enregistrements failover, multivalue answer, weighted, latency, geolocation et geoproximity. Le routage IP-based n'est pas pris en charge du tout dans une private hosted zone.

Le split-view DNS et le piège NXDOMAIN

Le split-view DNS (ou split-horizon) est le modèle où le même nom de domaine résout différemment à l'intérieur et à l'extérieur de votre réseau. Vous créez une hosted zone publique et une private hosted zone du même nom, vous associez la privée à vos VPC, et vous remplissez chacune avec les enregistrements adaptés à son public. Les appelants internes atteignent 10.0.5.20 ; internet atteint votre distribution CloudFront.

Voici la partie qui surprend. Supposons que votre private hosted zone soit example.com et qu'elle contienne des enregistrements pour db.example.com et cache.example.com, mais rien pour reports.example.com, qui existe bel et bien dans le DNS public.

Le VPC Resolver évalue dans cet ordre :

1. Une private hosted zone associée à ce VPC correspond-elle au nom interrogé ? Correspondre veut dire un nom identique, ou un nom parent de la requête. example.com est parent de reports.example.com, donc oui.
2. Chercher dans cette zone un enregistrement correspondant au nom et au type.
3. Aucune correspondance. Renvoyer NXDOMAIN.

Il ne retombe pas sur le DNS public. Dès qu'une zone privée revendique l'espace de noms, elle possède tout cet espace à l'intérieur du VPC. C'est le deuxième incident le plus fréquent sur les private hosted zones après les attributs de VPC manquants, et le symptôme est toujours le même : un nom qui marche partout sauf dans le VPC.

Quand 2 private hosted zones se recouvrent, la correspondance la plus spécifique gagne. Avec des zones example.com et accounting.example.com toutes deux associées, une requête pour seattle.accounting.example.com est servie par accounting.example.com, et uniquement par elle.

Le VPC Resolver en VPC+2

Chaque VPC dispose d'un resolver à la base de son CIDR plus deux. Un VPC en 10.20.0.0/16 a son resolver en 10.20.0.2. Cette adresse fait partie des 5 qu'AWS réserve dans chaque sous-réseau, et c'est là que les instances envoient leurs requêtes DNS, sauf si un DHCP options set en décide autrement.

Le VPC Resolver répond à 3 catégories :

• Les noms d'hôtes EC2 internes comme ip-10-20-1-15.ec2.internal
• Les enregistrements des private hosted zones associées au VPC
• Les noms publics, en effectuant pour vous des recherches récursives auprès des serveurs de noms publics

Ce troisième point compte : les instances ne parlent pas au DNS public elles-mêmes, c'est le VPC Resolver qui fait la récursion. Il peut aussi valider DNSSEC sur ces réponses récursives si vous activez la validation DNSSEC.

Si vous faites tourner vos propres serveurs DNS sur des instances EC2, ils doivent transmettre vers VPC+2 pour atteindre les données des private hosted zones. Les pointer vers le routeur du VPC (.1) ne marche pas.

La documentation AWS appelle désormais ce composant Route 53 VPC Resolver ; les supports plus anciens et le guide de l'examen disent Route 53 Resolver. C'est la même chose.

DNS hybride : endpoints entrants et sortants

Le VPC Resolver ne sait rien de corp.internal qui tourne sur vos serveurs Active Directory on-premises, et votre resolver on-premises ne sait rien de vos private hosted zones. Les endpoints Resolver font le pont entre les 2, et leurs noms forment la paire de termes la plus souvent inversée de ce domaine.

Les 2 noms s'écrivent du point de vue du VPC :

• Un outbound endpoint envoie les requêtes hors du VPC vers votre réseau. Vous l'associez à des règles de forwarding, une par nom de domaine, qui disent « les requêtes pour corp.internal vont vers ces adresses IP cibles ».
• Un inbound endpoint accepte les requêtes qui entrent dans le VPC depuis votre réseau. Vous donnez ses adresses IP à votre resolver on-premises comme conditional forwarder.

Un endpoint est un ensemble d'interfaces réseau élastiques placées dans des sous-réseaux que vous choisissez, donc il consomme des adresses privées de votre VPC. Deux conséquences suivent :

• Les adresses IP d'un outbound endpoint sont privées, donc la requête ne peut atteindre votre datacenter que par Direct Connect, un Site-to-Site VPN ou un NAT gateway. Il n'existe aucun chemin public.
• Chaque adresse IP cible d'une règle doit être joignable depuis les sous-réseaux de l'endpoint. Quand Resolver transmet une requête, il choisit une adresse cible au hasard, sans préférence, et réessaie sur une autre cible tirée au hasard si la première ne répond pas. Une seule cible injoignable sur une liste de 3 produit donc une résolution lente par intermittence plutôt qu'une panne franche.

aws route53resolver create-resolver-endpoint \
  --name outbound-to-datacenter \
  --direction OUTBOUND \
  --security-group-ids sg-0a1b2c3d4e5f6a7b8 \
  --ip-addresses SubnetId=subnet-0aaa,SubnetId=subnet-0bbb

aws route53resolver create-resolver-rule \
  --name forward-corp-internal \
  --rule-type FORWARD \
  --domain-name corp.internal \
  --resolver-endpoint-id rslvr-out-0123456789abcdef0 \
  --target-ips Ip=192.168.10.53,Port=53 Ip=192.168.20.53,Port=53

Une règle ne sert à rien tant que vous ne l'associez pas à un VPC. Les règles sont des ressources régionales et se partagent avec d'autres comptes via AWS RAM, ce qui donne le modèle standard : un compte réseau possède l'outbound endpoint et les règles, et chaque compte applicatif associe les règles partagées à ses VPC.

Quand une règle et une private hosted zone se contredisent

Vous avez une private hosted zone pour corp.internal et quelqu'un ajoute une règle de forwarding pour corp.internal sur le même VPC. Qui répond ?

La règle Resolver gagne. Les requêtes partent vers votre réseau, et les enregistrements posés dans la private hosted zone ne sont jamais consultés.

Cela mérite d'être dit à voix haute parce que la panne est invisible depuis la console Route 53 : la zone est là, les enregistrements sont là, l'association est là, et rien de tout cela ne sert. S'il vous faut les 2, limitez la règle à un nom plus étroit que la zone, ou retirez l'association.

Query logging : 2 journaux différents

La compétence 5.2.2 nomme explicitement le query logging, et il existe 2 fonctionnalités distinctes qui portent le même mot dans leur nom. Prendre la mauvaise fait perdre une investigation.

Une entrée de log public ressemble à ceci :

1.0 2026-08-11T08:16:02.130Z Z123412341234 example.com A NOERROR UDP DFW3 192.0.2.10 198.51.100.0/24

Version, horodatage, ID de hosted zone, nom interrogé, type interrogé, code de réponse, protocole de couche 4, edge location, IP du resolver, EDNS client subnet.

Les 2 journaux sont façonnés par le cache, et tous 2 sous-comptent pour la même raison. Les logs publics ratent tout ce qu'un resolver en aval a servi depuis son propre cache. Les logs Resolver n'enregistrent que les requêtes uniques : si une instance demande accounting.example.com deux fois pendant le TTL de cache du VPC Resolver, la seconde recherche n'apparaît jamais. Lire l'un ou l'autre comme un compteur de requêtes vous induira en erreur.

Quotas à retenir

Conseils pour l'examen

• « Pointer l'apex vers un load balancer, une distribution CloudFront ou un bucket S3 en site statique » est toujours un alias record. Un CNAME à l'apex n'est jamais une bonne réponse.
• Les requêtes alias vers des ressources AWS sont gratuites ; les requêtes CNAME sont facturées, et un CNAME pointant vers un autre enregistrement Route 53 est facturé double. Les questions DNS teintées de coût aboutissent en général à l'alias.
• Une private hosted zone qui ne résout rien veut dire enableDnsSupport et enableDnsHostnames. Vérifiez-les avant tout le reste.
• « Ça marche partout sauf dans le VPC, et le nom est un sous-domaine d'une private hosted zone » est le piège NXDOMAIN. Il n'y a aucun repli vers le DNS public.
• Inbound et outbound se lisent du point de vue du VPC. Des clients on-premises qui résolvent des noms AWS réclament un endpoint entrant. Des instances AWS qui résolvent des noms on-premises réclament un endpoint sortant plus une règle de forwarding.
• Une règle Resolver bat une private hosted zone pour le même nom de domaine.
• Le query logging public est limité à us-east-1 et ne couvre que les hosted zones publiques. Attribuer une recherche à une instance réclame le query logging Resolver.
• VPC+2 est l'adresse du resolver. VPC+1 est le routeur. Les serveurs DNS personnalisés transmettent vers +2.

La règle à emporter : avant de déboguer un enregistrement, déterminez quel resolver a répondu. Une private hosted zone, une règle Resolver et le DNS public revendiquent tous des noms, ils gagnent dans cet ordre inverse (règle, puis zone, puis public), et aucun ne repasse la main au suivant une fois qu'il a revendiqué l'espace de noms. Ce point réglé, la leçon suivante ne demande plus qui répond mais laquelle de plusieurs réponses vous recevez, ce que décident les politiques de routage.