Comment résoudre les problèmes DNS inverses avec les règles Route 53 et les points de terminaison sortants ?

Dernière mise à jour : 16/07/2020

J'ai configuré des règles de résolveur Amazon Route 53 et des points de terminaison sortants. Ces règles et points de terminaison sont destinés à gérer le DNS inverse de mon Virtual Private Cloud (VPC) sur un serveur DNS sur site. Cependant, elles ne fonctionnent pas normalement. Comment résoudre ce problème ?

Brève description

Vous pouvez utiliser la recherche DNS inverse pour renvoyer le nom de domaine d'une adresse IP. Le format d'un enregistrement DNS inverse se trouve sous l'espace de noms « in-addr.arpa. », où le sous-domaine est représenté par les octets de l'adresse IP dans l'ordre inverse. Le type d'enregistrement est pointeur (PTR).

Supposons que vous avez un Virtual Private Cloud (VPC) avec la plage d'adresses CIDR 172.31.0.0/16. Dans le VPC, vous disposez d'une instance avec l'adresse IP 172.31.2.23. La zone inverse de ce VPC est 31 172.in-addr.arpa. L'enregistrement inverse de l'adresse IP de cette instance est 23.2.31.172.in-addr.arpa.

Vous pouvez vérifier la réponse DNS en exécutant dig ou nslookup. Ces outils vous permettent de tester directement l'adresse IP et d'effectuer la recherche inverse pour vous. Dans les exemples de sortie suivants, notez que la requête est envoyée directement à l'adresse IP 172.31.2.23. dig et nslookup effectuent une résolution par rapport au nom 23.2.31.172.in-addr.arpa.

En utilisant le paramètre -x avec dig, vous pouvez effectuer une résolution DNS inverse. Lorsque vous utilisez ce paramètre, dig ajoute automatiquement le nom, la classe et les arguments de type. Reportez-vous à QUESTION SECTION pour voir que dig a interrogé automatiquement le nom correct (23.2.31.172.in-addr.arpa.), la classe (IN) et le type d'enregistrement (PTR).

dig -x 172.31.2.23 :

; <<>> 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    testresolution.com.

Un nslookup sur une adresse IP effectue une recherche inverse :

nslookup 172.31.2.23
23.2.31.172.in-addr.arpa    name = testresolution.com.

Solution

Comprendre le flux de requêtes

Il est important de comprendre le flux de requête lorsque vous utilisez des règles de résolveur sur un VPC et des points de terminaison sortants. En effet, cela peut vous aider à identifier les problèmes potentiels et à orienter votre approche de dépannage. Le flux se présente comme suit :

  1. Un client dans le VPC effectue une résolution DNS inverse pour une adresse au sein du même VPC.
  2. La requête arrive au résolveur DNS VPC (plage d'adresses CIDR VPC plus 2).
  3. La requête est mise en correspondance par une règle de résolveur sur le VPC.
  4. La requête est envoyée par le point de terminaison sortant aux adresses IP cibles sur une connexion VPN ou AWS Direct Connect.
    Remarque : les adresses IP cibles sont des serveurs DNS sur site qui gèrent le DNS inverse pour la plage d'adresses CIDR du VPC.

Identifier les réponses DNS prévues et réelles

Utilisez dig et nslookup pour exécuter des requêtes directement vers l'adresse IP de votre serveur DNS sur site. Ces outils essaient de résoudre le nom d'enregistrement correct. Veuillez noter le code de réponse DNS réel qui est renvoyé. Notez qu'un code de réponse inattendu peut ne pas indiquer un problème avec la configuration de la règle ou du point de terminaison. Par exemple :

  • NXDOMAIN peut être une réponse DNS inattendue, mais valide. Cette réponse indique que le serveur interrogé ne contient pas l'enregistrement demandé.
  • SERVFAIL indique qu'il existe un problème d'expiration ou un autre problème sur le chemin d'accès de la requête. Cette réponse nécessite un examen plus approfondi, comme décrit plus loin dans cet article.
  • Une réponse inattendue dans la section ANSWER SECTION peut indiquer qu'une autre règle a été utilisée.

Déterminer si la requête arrive au résolveur DNS VPC

Pour qu'une requête soit mise en correspondance par une règle sur un VPC, la requête doit arriver au résolveur DNS du VPC. Vérifiez les paramètres VPC pour déterminer si DNS Support est activé.

Reportez-vous aux champs de serveur dans dig et nslookup pour vérifier l'adresse IP du résolveur.

dig :

;; SERVER: 172.31.0.2#53(172.31.0.2)

nslookup :

Server:		172.31.0.2

Trouver la règle la plus spécifique qui correspond

Lorsque la requête arrive au résolveur DNS VPC, elle doit être mise en correspondance par une règle sur ce VPC. Lorsque les règles sont évaluées, la règle la plus spécifique est mise en correspondance. En interne, les règles sont créées pour couvrir toutes les recherches inverses de chaque adresse IP dans les VPC sources et connectés. Ces règles ne s'affichent pas dans AWS Management Console. Ces règles sont appelées règles autodéfinies, et elles sont créées par le résolveur Route 53.

  1. Identifiez les règles autodéfinies sur le VPC et les VPC connectés. Si vous disposez de VPC appairés ou des VPC connectés via une passerelle de transit (et que la prise en charge DNS est activée), notez toutes les règles créées pour la résolution inverse de chaque CIDR connecté.
    Remarque : le résolveur crée ces règles autodéfinies lorsque les noms d'hôte DNS sont définis sur true. Si vous souhaitez remplacer une règle autodéfinie, vous pouvez créer une règle de réacheminement conditionnel pour le même nom de domaine.
  2. Si DNSSupport et DNSHostnames sont activés, notez toutes les zones hébergées privées associées au VPC.
    Remarque : si la règle du réacheminement de résolveur et la zone hébergée privée se chevauchent, la règle du résolveur est prioritaire. Ensuite, la requête est transférée vers le serveur sur site.
  3. Comparez à la requête votre liste de règles et les zones hébergées privées associées pour déterminer la règle sélectionnée et la destination de la requête va.

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

  • Vérifiez que vos points de terminaison sortants sont configurés pour envoyer la requête aux adresses IP cibles spécifiées dans la règle.
  • Vérifiez que le groupe de sécurité utilisé par les points de terminaison sortants autorise le trafic TCP et UDP sortant vers les adresses IP et les ports du serveur DNS sur site.
  • Vérifiez que les listes de contrôle d'accès (ACL) autorisent le trafic TCP et UDP vers les adresses IP et les ports du serveur DNS sur site. Les listes ACL doivent également autoriser le trafic vers les ports éphémères (1024-65535).
  • Vérifiez que les tables de routage des points de terminaison sortants ont une route pour les adresses IP du serveur sur site vers la connexion VPN ou Direct Connect.

Vérifier que le point de terminaison sortant peut envoyer la requête via la connexion spécifiée dans sa table de routage

Vous pouvez exécuter la commande dig ou nslookup directement sur l'adresse IP du résolveur DNS sur site pour vérifier que la connexion VPN ou Direct Connect autorise la communication. Vous pouvez également envoyer un ping à un hôte sur site qui autorise le protocole ICMP (Internet Control Message Protocol) à exclure les problèmes sur la connexion.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?