Comment puis-je résoudre les problèmes de DNS inverse liés aux règles Route 53 et aux points de terminaison sortants ?

Lecture de 5 minute(s)
0

Je dispose d'un cloud privé virtuel (VPC) avec un serveur DNS sur site. J'ai configuré les règles inverses d'Amazon Route 53 Resolver et les points de terminaison sortants pour résoudre les requêtes DNS inverses provenant de ce serveur. Cependant, rien ne fonctionne comme prévu.

Résolution

Identifiez les réponses DNS attendues et réelles

Vous pouvez utiliser dig ou nslookup pour interroger directement l'adresse IP de votre serveur DNS hébergé sur site. Ces outils tenteront de trouver le bon nom d'enregistrement.

Pour effectuer une résolution DNS inverse avec dig, utilisez le paramètre -x. Lorsque vous utilisez ce paramètre, dig ajoute automatiquement les arguments nom, classe et type. Consultez la SECTION QUESTION pour vérifier que dig a automatiquement demandé le nom, la classe et le type d'enregistrement adéquats.

Supposons par exemple que vous souhaitez résoudre l'adresse IP 172.31.2.23 avec les valeurs suivantes :

Nom : 23.2.31.172.in-addr.arpa.
Classe : IN
Type d'enregistrement : PTR

Dans cet exemple, la commande dig -x 172.31.2.23 renvoie le résultat suivant :

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> -x 172.31.2.23;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58812
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;;
OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;23.2.31.172.in-addr.arpa.    IN    PTR

;;
ANSWER SECTION:
23.2.31.172.in-addr.arpa. 60    IN    PTR    example.com.

Pour nslookup, la commande nslookup 172.31.2.23 renvoie le résultat suivant :

23.2.31.172.in-addr.arpa.   name = example.com.

Remarque : un code de réponse inattendu peut ne pas indiquer un problème lié à la configuration de la règle ou du point de terminaison :

  • NXDOMAIN peut être une réponse DNS inattendue, mais elle est valide. Cette réponse indique que le serveur interrogé ne contient pas l'enregistrement demandé.
  • SERVFAIL indique une expiration du délai de disponibilité ou un autre problème sur le chemin de la requête. Cette réponse doit faire l'objet d'une enquête plus approfondie.
  • Une réponse inattendue dans la SECTION RÉPONSE peut indiquer que vous avez utilisé une autre règle.

Déterminez si la requête parvient au résolveur DNS du VPC

Pour qu'une requête corresponde à une règle sur un VPC, elle doit parvenir au résolveur DNS du VPC. Vérifiez les paramètres du VPC pour confirmer que vous avez activé DNS Support.
Pour vérifier l'adresse IP du résolveur, reportez-vous aux champs du serveur dans dig ou nslookup :

dig

;; SERVER: 172.16.0.2#53(172.16.0.2)

nslookup

Server:        172.16.0.2

Remarque : pour les VPC, le DNS du VPC est le CIDR du VPC plus deux. Dans ces exemples, l'adresse IP d'un VPC est 171.16.0.2.

Trouvez la règle correspondante la plus précise

Lorsque la requête parvient au résolveur DNS du VPC, elle doit correspondre à une règle de ce VPC. Lorsque les règles sont évaluées, celle qui est la plus précise est mise en correspondance. Pour trouver cette règle, procédez comme suit :

  1. Identifiez toutes les règles définies automatiquement sur le VPC et les VPC connectés. Pour les VPC appairés ou les VPC qui se connectent via une passerelle de transit (avec support DNS), notez toutes les règles relatives à la résolution inverse de chaque CIDR connecté.
    Remarque : le résolveur crée ces règles définies automatiquement lorsque les noms d'hôtes DNS sont définis sur true. Si vous souhaitez remplacer une règle définie automatiquement, vous devez créer une règle de transfert conditionnelle pour le même nom de domaine. Vous pouvez également désactiver les règles définies automatiquement.
  2. Si vous avez activé DNSSupport et DNSHostnames, notez toutes les zones hébergées privées associées au VPC.
    Remarque : si la règle de transfert du résolveur et la zone hébergée privée se chevauchent, la règle du résolveur est prioritaire. Dans ce cas, la requête est transmise au serveur sur site.
  3. Pour déterminer quelle règle est sélectionnée ainsi que la destination de la requête, comparez votre liste de règles et de zones hébergées privées associées à la requête.

Résolution des problèmes liés à vos points de terminaison sortants

Pour résoudre les problèmes liés à vos points de terminaison sortants, vérifiez les configurations suivantes :

  • Vos points de terminaison sortants doivent envoyer la requête aux adresses IP cibles spécifiées par la règle. Assurez-vous que la règle de résolution dispose de la bonne adresse IP pour le serveur DNS hébergé sur site.
  • Le groupe de sécurité des points de terminaison sortants doit autoriser le trafic TCP et UDP sortant vers les adresses IP et les ports du serveur DNS hébergé sur site.
  • Les listes de contrôle d'accès (ACL) doivent autoriser le trafic TCP et UDP vers les adresses IP et les ports du serveur DNS hébergé sur site. Les ACL doivent également autoriser le trafic vers les ports éphémères (1024-65535).
  • La table de routage du sous-réseau des points de terminaison sortants doit comporter une route pour les adresses IP du serveur hébergé sur site vers la connexion VPN ou AWS Direct Connect.

Pour obtenir plus d'informations et des instructions de dépannage, consultez la page Comment résoudre les problèmes de résolution DNS liés aux points de terminaison Route 53 Resolver ?

Vérifiez si les points de terminaison sortants sont capables d'envoyer la requête via la connexion spécifiée dans leur table de routage

Vérifiez que la connexion VPN ou Direct Connect autorise la communication. Pour ce faire, exécutez une commande dig ou nslookup directement sur l'adresse IP du résolveur DNS sur site. Pour résoudre les problèmes de connexion rencontrés, envoyez un ping à un hôte sur site qui autorise le protocole ICMP (Internet Control Message Protocol).

Remarque : vous devez effectuer ce test à partir d'une instance EC2 située dans le même sous-réseau que les points de terminaison sortants.

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 6 mois
Aucun commentaire