Comment résoudre les problèmes de résolution DNS des zones hébergées privées de Route 53 ?

Résolution

Remarque : Si des erreurs surviennent lors de l’exécution des commandes de l’interface de la ligne de commande AWS CLI, vérifiez que vous utilisez la version la plus récente d’AWS CLI.

Confirmez que vous avez activé le support DNS dans le VPC

Pour autoriser la résolution des enregistrements dans une zone hébergée privée, vous devez activer le support DNS dans votre cloud privé virtuel (VPC). Vérifiez que DNSSupport et DNSHostNames sont définis sur True dans votre VPC.

Vérifiez que vous avez associé le bon ID VPC à la zone hébergée privée

Lorsque vous associez une zone hébergée privée à un VPC, Route 53 Resolver crée une règle définie automatiquement et l'associe au VPC. Les ressources de ce VPC peuvent interroger le résolveur pour résoudre les enregistrements DNS dans la zone hébergée privée.

Vérifiez que vous avez associé le bon ID VPC à votre zone hébergée privée. Assurez-vous également que vous interrogez les enregistrements de ressources du domaine depuis le même VPC.

Pour obtenir la liste des VPC associés à une zone hébergée, exécutez la commande suivante dans l'AWS CLI :

aws route53  list-hosted-zones-by-vpc --vpc-id VPC_ID --vpc-region REGION_ID

Remarque : Remplacez VPC_ID et REGION_ID par les valeurs appropriées.

Pour obtenir la liste des zones hébergées privées associées à des VPC spécifiques, exécutez la commande suivante dans l'AWS CLI :

aws route53 get-hosted-zone --id VPC_ID

Remarque : Remplacez VPC_ID par la valeur appropriée.

Vérifiez que vous avez configuré des règles de transfert pour les domaines de zone hébergée privée sur des serveurs DNS personnalisés vers le serveur DNS fourni par Amazon (CIDR+2).

Si vous avez configuré des serveurs DNS personnalisés ou des serveurs Active Directory dans les options DHCP pour le DNS de votre VPC, vérifiez les configurations suivantes :

• Dans la règle de transfert, vérifiez que vos serveurs transmettent les requêtes DNS du domaine privé à l'adresse IP des serveurs DNS fournis par Amazon pour votre VPC. Par exemple, si la plage d'adresses CIDR principale de votre VPC est 172.31.0.0/16, l'adresse IP du serveur DNS du VPC est 172.31.0.2. Il s'agit de la plage réseau VPC plus deux.
• Vérifiez que le domaine que vous avez configuré sur les serveurs personnalisés est différent de votre zone hébergée privée. Si le domaine est identique à votre zone hébergée privée, le serveur fait autorité pour ce domaine. Dans ce cas, le serveur ne contacte pas le serveur DNS fourni par Amazon pour les domaines de zone hébergée privée.

Vérifiez les paramètres personnalisés dans resolv.conf

Si vous rencontrez des problèmes de résolution ou de réponse DNS intermittents, passez en revue les paramètres de configuration de votre instance source dans resolv.conf.

Par exemple, vous configurez l'option de rotation dans resolv.conf pour équilibrer la charge des requêtes DNS entre le serveur DNS Amazon et le serveur de résolution public de Google (8.8.8.8). Dans ce cas, voici les paramètres resolv.conf :

options rotate; generated by /usr/sbin/dhclient-script
nameserver 8.8.8.8
nameserver 172.31.0.2

Lors de votre première requête auprès du résolveur public de Google (8.8.8.8), vous recevez la réponse NxDomain attendue. Vous recevez cette réponse parce que le résolveur essaie de trouver la réponse dans la zone hébergée publique plutôt que dans la zone hébergée privée :

Private hosted Zone Record - resolvconf.local\[ec2-user@ip-172-31-253-89 etc\]$ curl -vks http://resolvconf.local
\* Rebuilt URL to: http://resolvconf.local/
\* Could not resolve host: resolvconf.local

15:24:58.553320 IP ip-172-31-253-89.ap-southeast-2.compute.internal.40043 > dns.google.domain: 65053+ A? resolvconf.local. (34)
15:24:58.554814 IP dns.google.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.40043: 65053 NXDomain 0/1/0 (109)

Toutefois, la seconde requête est résolue avec succès. La deuxième requête aboutit car elle atteint le VPC DNS resolver associé à votre zone hébergée privée :

[ec2-user@ip-172-31-253-89 etc]$ curl -vks http://resolvconf.local* Rebuilt URL to: http://resolvconf.local/
*   Trying 1.1.1.1...
* TCP_NODELAY set
* Connected to resolvconf.local (1.1.1.1) port 80 (#0)

15:25:00.224761 IP ip-172-31-253-89.ap-southeast-2.compute.internal.51578 > 172.31.0.2.domain: 7806+ A? resolvconf.local. (34)
15:25:00.226527 IP 172.31.0.2.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.51578: 7806 1/0/0 A 1.1.1.1 (50)

Vérifiez que les espaces de noms des zones hébergées privées ne se chevauchent pas

Lorsque plusieurs zones ont des espaces de noms qui se chevauchent (tels que example.com et test.example.com), le résolveur achemine le trafic vers la zone hébergée en fonction de la correspondance la plus spécifique. S'il existe une zone correspondante mais qu'aucun enregistrement ne correspond au nom de domaine et au type de la demande, Resolver ne transmet pas la demande. Resolver renvoie plutôt NXDOMAIN (domaine inexistant) au client.

Vérifiez que vous avez configuré l'enregistrement correct dans la zone hébergée privée la plus spécifique pour une résolution DNS réussie.

Supposons, par exemple, que vous disposiez de deux zones hébergées privées contenant les enregistrements suivants :

Nom de zone hébergée privée	Nom de l'enregistrement	Valeur
local	overlap.privatevpc.local	60.1.1.1
privatevpc.local	overlap.privatevpc.local	50.1.1.1

La demande obtient la réponse suivante à partir de la zone hébergée privée correspondante la plus spécifique :

[ec2-user@IAD-BAS-INSTANCE ~]$ dig overlap.privatevpc.local +short50.1.1.1

Confirmez qu'aucune délégation de zone n'est configurée dans la zone hébergée privée

Les zones hébergées privées ne prennent pas en charge la délégation de zones. Si la délégation est configurée, le client obtient le code de réponse « Servfail » du résolveur VPC.

Utilisez l'interface de ligne de commande AWS pour vérifier que la délégation de zone n'est pas configurée dans la zone hébergée privée, comme dans l'exemple suivant :

Zone hébergée privée : abc.com Enregistrement NS de délégation pour : kc.abc.com Enregistrement de ressource : test.kc.abc.com

[ec2-user@ip-172-31-0-8 ~]$ dig test.kc.abc.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63414
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;test.kc.abc.com        IN      A
;; Query time: 15 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Fri Apr 16 15:57:37 2021
;; MSG SIZE  rcvd: 48

Vérifiez que la politique de routage de l'enregistrement de ressource est prise en charge dans les zones hébergées privées.

Vérifiez que vous avez configuré une politique de routage dans votre enregistrement de ressources qui est prise en charge par une zone hébergée privée :

• Routage simplifié
• Routage par basculement
• Routage des réponses à valeurs multiples
• Routage pondéré
• Routage basé sur la latence
• Routage de géolocalisation

Vérifiez que la règle Resolver et son point de terminaison entrant sont résolus vers différents VPC

Lorsque le point de terminaison sortant d'une règle Resolver pointe vers un point de terminaison entrant qui partage un VPC avec la règle, le résultat est une boucle. Dans cette boucle, la requête passe continuellement entre les points de terminaison entrants et sortants.

Vous pouvez toujours associer la règle de transfert à d'autres VPC partagés avec d'autres comptes. Pour ce faire, utilisez AWS Resource Access Manager (AWS RAM). Les zones hébergées privées associées au hub ou à un VPC central résolvent les requêtes vers les points de terminaison entrants. Une règle de résolution de transfert ne modifie pas cette résolution, comme dans l'exemple suivant :

Hub VPC : VPC A - CIDR 172.31.0.0/VPC à 16 branches : VPC B - CIDR 172.32.0.0/16 Adresse IP entrante : 172.31.253.100 et 172.31.2.100 Adresses IP cibles dans la règle de transfert : 172.31.253.100 et 172.31.2.100 Règle associée aux VPCs : Client VPC A et VPC B : 172-32-254-37

ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9007
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;overlap.privatevpc.local. IN A
;; Query time: 2941 msec
;; SERVER: 172.32.0.2#53(172.32.0.2)

Dans cette sortie, la requête DNS passe continuellement des points de terminaison sortants aux points de terminaison entrants. La demande vérifie la règle associée au VPC A et renvoie la requête au point de terminaison sortant. Après plusieurs tentatives, la requête expire et renvoie un code de réponse Servfail.

Pour résoudre ce problème et rompre la boucle, supprimez l'association VPC du hub (VPC A) avec la règle. Ensuite, vous obtenez une réponse positive de la part de la zone hébergée privée :

ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58606
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;overlap.privatevpc.local. IN A
;; ANSWER SECTION:
overlap.privatevpc.local. 0 IN A 50.1.1.1
;; Query time: 5 msec
;; SERVER: 172.32.0.2#53(172.32.0.2)

Vérifiez que le résolveur local envoie une demande récursive

Si vous utilisez des requêtes locales vers le résolveur Route 53, vous pouvez transférer les requêtes DNS des résolveurs de votre réseau vers un résolveur VPC. Pour ce faire, utilisez le point de terminaison entrant du Resolver. Cette action vous permet de résoudre les noms de domaine des ressources AWS, telles que les enregistrements d'une zone hébergée privée.

Dans certains cas, il se peut que la zone hébergée privée ne soit pas résolue correctement à partir du résolveur local. Ce comportement se produit parce que le résolveur local envoie une requête itérative au lieu d'une demande récursive. Le point de terminaison entrant prend en charge les requêtes récursives pour des résolutions DNS réussies.

Pour vérifier le type de résolution, utilisez une capture de paquets sur le résolveur DNS (sur site). Passez ensuite en revue les indicateurs DNS (récursivité souhaitée = 0). Pour tester la résolution, envoyez une requête itérative avec la commande +norecurse dig, ou définissez norecurse avec nslookup :

**Adresse IP du point de terminaison entrant :**172.31.253.150

**Adresse IP du résolveur local :**10.0.4.210

L'échec d'une requête itérative adressée à l'adresse IP entrante entraîne le résultat suivant :

[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local +norecurse; <<>> DiG 9.11.0rc1 <<>> @172.31.253.150 overlap.privatevpc.local +norecurse
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Une requête récursive réussie produit le résultat suivant :

[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19051
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;overlap.privatevpc.local.      IN      A
;; ANSWER SECTION:
overlap.privatevpc.local. 0     IN      A       50.1.1.1
;; Query time: 200 msec
;; SERVER: 172.31.253.150#53(172.31.253.150)

Vérifiez que vous avez configuré les bonnes priorités de règles pour le DNS fourni par Amazon

Lorsque l'instance cliente envoie une requête au résolveur (serveur DNS fourni par AWS), le résolveur vérifie les règles de l'instance quant à l'endroit où acheminer la demande.

En général, c'est la règle la plus spécifique qui prime. S'il existe une règle de résolution test.example.com et une zone hébergée privée la.plus.longue.test.example.com, recherchez le domaine .test.example.com le plus long qui correspond à la zone hébergée privée.

Si les règles se situent au même niveau de domaine, elles ont la priorité suivante :

1. Règle du résolveur
2. Zone hébergée privée
3. Règle interne

Par exemple, s'il existe une règle de résolution test.example.com et une zone hébergée privée test.example.com, la règle de résolution est prioritaire. La requête est transmise aux serveurs ou aux adresses IP cibles configurés dans la règle.

Informations connexes

Utilisation de zones hébergées privées

Quelles options Amazon VPC dois-je activer pour utiliser ma zone hébergée privée ?

Évitez les configurations en boucle avec les points de terminaison Resolver