Aller au contenu

AWS Mis à jour le 2026-07-04

Échecs de résolution DNS dans un VPC : Route 53 Resolver, enableDnsHostnames et DNS hybride

Le DNS dans un VPC échoue pour une courte liste de raisons : attributs VPC désactivés, zones privées non associées, points de terminaison Resolver manquants en hybride, ou la limite de requêtes par ENI. Voici le chemin de diagnostic.

Le DNS à l’intérieur d’un VPC est servi par le Route 53 Resolver à l’adresse de base du VPC plus deux (un VPC en 10.0.0.0/16 résout contre 10.0.0.2), et quand il déraille, la cause est presque toujours l’une de ces cinq choses : les attributs enableDnsSupport ou enableDnsHostnames du VPC sont désactivés, une zone hébergée privée n’est pas associée au VPC qui interroge, les requêtes hybrides n’ont aucun point de terminaison Resolver pour circuler, une règle de résolution transfère un domaine vers un endroit inattendu, ou une instance frappe la limite de 1 024 paquets DNS par seconde par ENI. Le correctif commence par savoir laquelle de ces couches échoue.

Ce qui se passe

Chaque VPC reçoit gratuitement le résolveur fourni par Amazon — joignable à la base du CIDR du VPC +2 et à 169.254.169.253 depuis toute instance. Deux attributs du VPC conditionnent son comportement. enableDnsSupport active la résolution tout court; désactivé, les requêtes vers l’adresse +2 échouent, point. enableDnsHostnames contrôle l’attribution de noms DNS aux instances et — c’est crucial — est requis avec enableDnsSupport pour que le DNS privé des points de terminaison d’interface fonctionne : désactivé, sqs.ca-central-1.amazonaws.com continue de résoudre vers des IP publiques même si vous payez pour un point de terminaison.

Les zones hébergées privées ajoutent la couche suivante : une zone ne répond qu’aux requêtes des VPC auxquels elle est explicitement associée. L’association est par VPC et ne traverse pas l’appairage — chaque VPC interroge son propre résolveur +2, donc une zone privée associée au VPC A est invisible depuis le VPC appairé B tant que vous ne l’associez pas aussi à B.

Les montages hybrides ajoutent la dernière couche. Le résolveur +2 ne répond que de l’intérieur du VPC. Les serveurs sur site ne peuvent pas l’interroger, et les instances ne peuvent pas joindre le DNS sur site, à moins de déployer des points de terminaison Route 53 Resolver : un point de terminaison entrant donne à votre centre de données des IP interrogeables pour les noms hébergés dans AWS; un point de terminaison sortant plus des règles de résolution transfèrent les domaines choisis (corp.example.com) du VPC vers vos serveurs DNS sur site. Oubliez une moitié et une direction de la résolution hybride casse en silence.

Quoi vérifier en premier

  • Les deux attributs du VPC : enableDnsSupport et enableDnsHostnames. Les VPC non par défaut arrivent avec enableDnsHostnames désactivé.
  • L’instance utilise-t-elle vraiment le résolveur du VPC? Un jeu d’options DHCP personnalisé ou un /etc/resolv.conf modifié à la main peut pointer ailleurs.
  • La zone privée est-elle associée à ce VPC-ci? Pas au VPC où elle a été créée — à celui d’où part la requête.
  • Les règles de résolution couvrent-elles le domaine? Une règle de transfert pour example.com capture aussi les sous-domaines, sauf règle plus spécifique.
  • Groupes de sécurité des points de terminaison Resolver : TCP et UDP 53 doivent être ouverts vers les CIDR concernés.

Comment vérifier

# Attributs du VPC (lancer les deux)
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc123 --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc123 --attribute enableDnsHostnames

# Associations de la zone hébergée privée
aws route53 list-hosted-zones-by-vpc \
  --vpc-id vpc-0abc123 --vpc-region ca-central-1

# Règles de résolution et leurs cibles de transfert
aws route53resolver list-resolver-rules \
  --query 'ResolverRules[].{Domain:DomainName,Type:RuleType,Targets:TargetIps}'

Depuis une instance, isolez quel résolveur échoue :

# Interroger directement le résolveur du VPC
dig internal.example.com @169.254.169.253 +short
# Interroger ce que pointe resolv.conf
dig internal.example.com +short
# Hybride : le DNS sur site est-il seulement joignable?
dig corp.example.com @10.50.0.10 +short

Si le résolveur +2 répond mais que la requête par défaut échoue, le problème est la configuration du résolveur de l’instance, pas le VPC. Chemins console : VPC > Your VPCs > Actions > Edit VPC settings pour les attributs, Route 53 > Resolver > Endpoints / Rules pour la plomberie hybride. La journalisation des requêtes du Resolver (Route 53 > Resolver > Query logging) montre chaque requête et la règle appliquée — c’est le flow log du DNS. Référence complète : la documentation Route 53.

Le correctif

  1. Activez les deux attributs du VPC. aws ec2 modify-vpc-attribute --vpc-id vpc-0abc123 --enable-dns-support puis la même commande avec --enable-dns-hostnames. Cela règle à lui seul la plupart des cas de « DNS privé du point de terminaison d’interface qui ne fonctionne pas ».
  2. Associez la zone privée à chaque VPC qui l’interroge. Même compte : Route 53 > Hosted zones > zone > Edit, ou create-vpc-association-authorization plus associate-vpc-with-hosted-zone entre comptes. Rappel : l’appairage ne transporte pas le DNS.
  3. Déployez des points de terminaison Resolver pour l’hybride, dans les deux directions. Point de terminaison entrant (deux IP dans des AZ différentes) pour les requêtes du site vers AWS; point de terminaison sortant plus une règle de transfert par domaine corporatif pour AWS vers le site. Pointez les redirecteurs conditionnels sur site vers les IP du point de terminaison entrant, jamais vers l’adresse +2.
  4. Corrigez la préséance des règles de résolution. Le domaine le plus spécifique gagne; une règle périmée qui transfère example.com vers un serveur de centre de données déclassé bat la zone publique. Supprimez-la ou reciblez-la, et ajoutez une règle plus spécifique de type SYSTEM si un sous-domaine doit résoudre normalement.
  5. Répartissez la charge DNS si vous frappez la limite par ENI. 1 024 paquets par seconde par ENI est une limite ferme; le symptôme, ce sont des délais intermittents sous charge. Mettez en cache localement (systemd-resolved, dnsmasq, ou NodeLocal DNSCache sur Kubernetes) plutôt que d’augmenter les tentatives.

Quand c’est la mauvaise approche

Si deux services dans des VPC différents n’arrivent pas à se résoudre, la réponse n’est peut-être pas du tout le partage de zones privées — un point de terminaison PrivateLink publie un service avec son propre nom DNS et évite l’étalement des associations de zones; lisez appairage VPC vs PrivateLink avant de bâtir une toile d’associations. Et ne déployez pas de points de terminaison Resolver quand tout est dans AWS — ils coûtent à l’heure par ENI et ne se justifient que lorsque les requêtes traversent réellement la frontière hybride.

Erreurs fréquentes

  • Tester le DNS depuis le VPC où la zone a été créée et le déclarer sain, pendant que la charge en échec vit dans un VPC non associé.
  • Pointer les redirecteurs sur site vers l’adresse +2 du VPC, injoignable de l’extérieur du VPC.
  • Des jeux d’options DHCP personnalisés restés d’une migration, envoyant chaque instance vers un serveur DNS mort.
  • Blâmer Route 53 pour ce qui est un cache au niveau de l’OS : resolvectl flush-caches avant d’escalader.

Prévention

  • Intégrez enableDnsSupport et enableDnsHostnames aux valeurs par défaut de votre module VPC et laissez la détection de dérive IaC attraper les changements.
  • Activez la journalisation des requêtes du Resolver dans les VPC de production — le premier incident DNS hybride rembourse le temps d’installation.
  • Tenez une carte d’une page : quelles zones privées sont associées à quels VPC, et quels domaines chaque règle transfère où.
  • Surveillez les taux de délais DNS dans les métriques applicatives; la limite par ENI s’y manifeste bien avant qu’on soupçonne le DNS.
  • Revoyez les règles de résolution chaque fois qu’un centre de données ou un serveur DNS est déclassé.

Les échecs DNS dans un VPC semblent aléatoires jusqu’à ce qu’on les découpe par couche — attributs, association de zone, points de terminaison hybrides, règles, limitation — et qu’on teste chacune avec dig contre un résolveur précis. 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.