Comment résoudre les problèmes liés aux réponses NXDOMAIN lors de l'utilisation de Route 53 en tant que service DNS ?

Lecture de 7 minute(s)
0

J'essaie de résoudre les enregistrements Amazon Route 53. Cependant, je reçois une réponse NXDOMAIN du résolveur DNS ou une erreur DNS_PROBE_FINISHED_NXDOMAIN. Comment puis-je résoudre ce problème ?

Solution

S'assurer que les serveurs de noms appropriés ont été configurés sur le bureau d'enregistrement de domaine

1.    Exécutez une requête whois sur le domaine.    
Pour Windows : ouvrez une invite de commandes Windows, puis saisissez whois -v example.com.
Pour Linux : ouvrez votre client SSH. Dans l'invite de commandes, saisissez whois example.com.
Remarque : si le domaine est enregistré auprès d'Amazon Registrar, vous pouvez utiliser l'outil de recherche whois d'Amazon Registrar.

2.    Vérifiez que votre domaine n'est pas suspendu. Pour plus d'informations et pour savoir comment résoudre ce problème, consultez Mon domaine est suspendu (le statut est ClientHold).

3.    Dans la sortie whois, notez les serveurs de noms qui font autorité pour votre domaine.

        Exemple de sortie whois :

whois example.com
   Domain Name: EXAMPLE.COM
   Registry Domain ID: 87023946_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.godaddy.com
   Registrar URL: http://www.godaddy.com
   Updated Date: 2020-05-08T10:05:49Z
   Creation Date: 2002-05-28T18:22:16Z
   Registry Expiry Date: 2021-05-28T18:22:16Z
   Registrar: GoDaddy.com, LLC
   Registrar IANA ID: 146
   Registrar Abuse Contact Email: abuse@godaddy.com
   Registrar Abuse Contact Phone: 480-624-2505
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Name Server: ns-1470.awsdns-55.org.
   Name Server: ns-1969.awsdns-54.co.uk.
   Name Server: ns-736.awsdns-28.net.
   Name Server: ns-316.awsdns-39.com.

Pour vérifier les serveurs de noms configurés dans un ordinateur sous Linux, vous pouvez aussi utiliser l'utilitaire dig.

Exemple de sortie dig +trace :

dig +trace example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace example.com
;; global options: +cmd
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
;; Received 239 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210329220000 20210316210000 42351 . 
;; Received 1174 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 104 ms

example.com.         172800  IN      NS      ns-1470.awsdns-55.org.   ------>Name servers of interest.
example.com.         172800  IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         172800  IN      NS      ns-736.awsdns-28.net.
example.com.         172800  IN      NS      ns-316.awsdns-39.com.

;; Received 732 bytes from 192.33.14.30#53(b.gtld-servers.net) in 91 ms

example.com.         3600    IN      A       104.200.22.130
example.com.         3600    IN      A       104.200.23.95
example.com.         3600    IN      NS      ns-1470.awsdns-55.org.
example.com.         3600    IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         3600    IN      NS      ns-736.awsdns-28.net.
example.com.         3600    IN      NS      ns-316.awsdns-39.com.

;; Received 127 bytes from 173.201.72.25#53(ns-1470.awsdns-55.org) in 90 ms

4.    Ouvrez la console Route 53.

5.    Dans le panneau de navigation, choisissez Hosted zones (Zones hébergées).

6.    Sur la page Hosted zones (Zones hébergées), choisissez le bouton radio (et non pas le nom) de la zone hébergée. Ensuite, choisissezView details (Afficher les détails).

7.    Sur la page des détails de la zone hébergée, choisissez Hosted zone details (Détails de la zone hébergée).

8.    Vérifiez que les serveurs de noms répertoriés dans les détails de la zone hébergée sont identiques à ceux de la sortie whois ou dig +trace.

Important : si les serveurs de noms ne sont pas identiques, vous devez les mettre à jour dans le bureau d'enregistrement du domaine. Si le domaine est enregistré avec Route 53, reportez-vous à la section Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine. Si le domaine est enregistré auprès d'un tiers, reportez-vous à leur documentation pour découvrir comment mettre à jour les serveurs de noms.

S'assurer que l'enregistrement demandé existe

Vérifiez que la zone hébergée du domaine contient l'enregistrement demandé. Par exemple, si vous recevez une réponse NXDOMAIN lorsque vous tentez de résoudre www.exemple.com, vérifiez la zone hébergée exemple**.com** pour l'enregistrement www.exemple.com. Pour savoir comment répertorier les enregistrements dans Route 53, reportez-vous à Répertorier les enregistrements.

Rechercher les problèmes de délégation de sous-domaine

1.    Dans la zone hébergée parent, recherchez un enregistrement de serveur de noms (NS) pour le nom de domaine que vous résolvez. Si un enregistrement NS pour un sous-domaine existe, cela implique que l'autorité du domaine et de ses sous-domaines a été déléguée à une autre zone. Par exemple, si un enregistrement NS existe pour www.exemple.com, l'autorité pour www est déléguée aux serveurs de noms dans l'enregistrement NS. Si la délégation est valide, vous devez créer l'enregistrement du domaine dans la zone déléguée (et non pas dans la zone parent exemple.com).

2.    Si la délégation n'est pas valide, supprimez l'enregistrement NS du domaine. Vérifiez que la zone hébergée parent (exemple.com) contient un enregistrement pour le nom de domaine que vous tentez de résoudre.

Déterminer si le problème de résolution DNS existe uniquement dans le VPC

1.    Vérifiez l'adresse IP du résolveur configurée sur le système d'exploitation (SE) client. Pour Linux, vérifiez le fichier /etc/resolv.conf. Pour Windows, vérifiez les serveurs DNS dans la sortie ipconfig /all. Recherchez le résolveur DNS par défaut du VPC (qui est le CIDR+2 du VPC). Par exemple, si le CIDR du VPC est 10.0.0.0/8, l'adresse IP du résolveur DNS devrait être 10.0.0.2. Si vous ne voyez pas le résolveur DNS du VPC dans /etc/resolv.conf, vérifiez le résolveur DNS personnalisé.

2.    Si vous utilisez le résolveur DNS du VPC, vérifiez les zones hébergées privées et les règles Route 53 Resolver.

Lors de l'utilisation de règles Resolver et de zones hébergées privées :

Si la règle Resolver et le nom de domaine de la zone hébergée privée se chevauchent, la règle Resolver est prioritaire. Pour plus d'informations, consultez la section Remarques sur l'utilisation des zones hébergées privées. Dans ce cas, la requête DNS est envoyée à l'adresse IP configurée comme cible dans la règle Resolver.

Lors de l'utilisation d'une zone hébergée privée et d'aucune règle Resolver :

Vérifiez s'il existe une zone hébergée privée avec des noms de domaine correspondants associés au VPC. Par exemple, vous pouvez disposer à la fois d'une zone hébergée privée et d'une zone hébergée publique pour le domaine associé à un VPC. Les clients du VPC ne peuvent pas résoudre un enregistrement créé dans la zone hébergée publique. Le DNS du VPC ne se retrouve pas sur la zone hébergée publique si l'enregistrement n'est pas présent dans la zone hébergée privée.

Lors de l'utilisation de règles Resolver uniquement et d'aucune zone hébergée privée :

Vérifiez les règles Route 53 Resolver. S'il existe une règle qui correspond au nom de domaine, la requête pour ce domaine est alors acheminée vers les adresses IP cibles configurées plutôt que vers les résolveurs publics par défaut.

Déterminer si le problème est le résultat d'une mise en cache négative

La mise en cache négative est le processus de stockage d'une réponse négative d'un serveur de noms qui fait autorité dans le cache. Une réponse NXDOMAIN est considérée comme une réponse négative. Examinons les exemples suivants :

Un client effectue une requête DNS pour neg.exemple.com et reçoit le code de réponse NXDOMAIN. Cette réponse est envoyée, car l'enregistrement neg.exemple.com n'existe pas.

Cet utilisateur possède également exemple.com. Il crée alors un nouvel enregistrement pour neg.exemple.com. L'utilisateur continue de recevoir une réponse NXDOMAIN, tandis que les utilisateurs dans d'autres réseaux peuvent résoudre l'enregistrement correctement.

Lorsque l'utilisateur a effectué une requête sur neg.exemple avant de créer l'enregistrement, il a reçu la réponse NXDOMAIN. Si la mise en cache négative est activée dans ses paramètres de résolution, le résolveur met en cache cette réponse. Une fois que l'utilisateur a créé le nouvel enregistrement, il a reproduit la requête. Le résolveur avait précédemment reçu cette requête et l'avait mise en cache, de sorte qu'il a renvoyé la réponse du cache.

Aucun enregistrement n'est renvoyé dans le retour d'une réponse négative. Il n'y a donc pas de valeur Time to Live (TTL) par rapport à une réponse positive. Dans ce cas, le résolveur utilise la valeur la plus faible : la valeur TTL minimale de l'enregistrement Start of Authority (SOA) ou la valeur TTL de l'enregistrement SOA pour mettre en cache la réponse NXDOMAIN.

Pour vérifier ce problème, envoyez une requête directement au serveur de noms pour voir si vous obtenez une réponse. Par exemple :

dig www.example.com @ns-1470.awsdns-55.org

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans