Comment puis-je résoudre les problèmes liés aux réponses NXDOMAIN lorsque j'utilise Route 53 comme service DNS ?

Résolution

Déterminez si le domaine est à l’état actif ou suspendu

1.    Exécutez une requête whois sur le domaine.

Remarque : avant d'exécuter les commandes suivantes, assurez-vous que whois est installé.

Pour Windows : ouvrez une invite de commande Windows, puis saisissez whois -v example.com.
Pour Linux : ouvrez votre client SSH. Dans l'invite de commande, saisissez whois example.com.

Remarque : si le domaine est enregistré auprès d'Amazon Registrar, vous pouvez utiliser l'](https://registrar.amazon.com/whois)outil de recherche whois d'Amazon Registrar[.

2.    Vérifiez l’état du domaine. Si la valeur de État du domaine est clientHold, le domaine est suspendu.

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: clientHold https://icann.org/epp#clientHold  
   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 rendre à nouveau un domaine disponible sur Internet, il faut le retirer de l'état suspendu. Les raisons les plus courantes pour lesquelles un domaine peut être suspendu sont les suivantes :

• Vous avez enregistré un nouveau domaine, mais vous n'avez pas cliqué sur le lien figurant dans l'e-mail de confirmation.
• Vous avez désactivé le renouvellement automatique du domaine et celui-ci a expiré.
• Vous avez modifié l'adresse e-mail du contact inscrit, mais vous n'avez pas vérifié la validité de la nouvelle adresse e-mail.

Pour plus d'informations, reportez-vous à Mon domaine est suspendu (l'état est ClientHold).

Vérifiez que les serveurs de noms appropriés sont configurés sur le bureau d'enregistrement de domaines

1.    Dans la sortie whois, notez les Serveurs de noms officiels pour votre domaine. Consultez la sortie whois précédente pour un exemple.

Vous pouvez également utiliser l'utilitaire dig pour vérifier les serveurs de noms configurés.

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

2.    Ouvrez la console Route 53.

3.    Dans le volet de navigation, choisissez Zones hébergées.

4.    Sur la page Zones hébergées, sélectionnez le bouton radio (pas le nom) de la zone hébergée. Sélectionnez ensuite Afficher les détails.

5.    Sur la page des détails de la zone hébergée, choisissez Détails de la zone hébergée.

6.    Vérifiez que les Serveurs de noms répertoriés dans les détails de la zone hébergée sont identiques aux Serveurs de noms figurant dans la sortie whois ou dig + trace.

Important : si les serveurs de noms ne sont pas identiques, mettez-les à jour auprès du bureau d'enregistrement des domaines. Pour les domaines enregistrés auprès de Route 53, reportez-vous à Ajout ou modification des serveurs de noms et des enregistrements de type glue pour un domaine. Pour les domaines enregistrés auprès d'un tiers, consultez la documentation du fournisseur pour savoir comment mettre à jour les serveurs de noms.

Vérifiez 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.example.com, vérifiez la zone hébergée de example.com pour l'enregistrement www.example.com. Pour savoir comment répertorier les enregistrements dans Route 53, reportez-vous à Liste des enregistrements.

Si un enregistrement CNAME pointe vers un autre nom de domaine, assurez-vous que le nom canonique existe et peut être résolu.

Exemple

L'enregistrement CNAME example.com est configuré avec la valeur blog.example.com. Dans ce cas, vérifiez que l'enregistrement blog.example.com existe et peut être résolu.

Recherchez la présence de problèmes de délégation de sous-domaines

1.    Recherchez dans la zone hébergée parent un enregistrement de serveur de noms (NS) pour le nom de domaine que vous êtes en train de résoudre. S'il existe un enregistrement NS pour un sous-domaine, l'autorité du domaine et de ses sous-domaines est déléguée à une autre zone. Par exemple, s'il existe un enregistrement NS pour www.example.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 de example.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 (example.com) contient un enregistrement pour le nom de domaine que vous essayez de résoudre.

3. Les résolveurs qui implémentent la minimisation de QNAME incluent un minimum de détails dans chaque requête, comme l’exige cette étape du processus de résolution. Cela peut provoquer un problème NXDOMAIN dans certains résolveurs. Lorsque vous configurez plusieurs niveaux de délégation de sous-domaines, respectez une délégation stricte à tous les niveaux. Pour plus d'informations, reportez-vous à Routage du trafic pour des niveaux supplémentaires de sous-domaines.

Déterminez 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 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 du cloud privé virtuel (VPC) par défaut (VPC CIDR+2). Par exemple, si le CIDR du VPC est 10.0.0.0/8, l'adresse IP du résolveur DNS est 10.0.0.2. Si le résolveur DNS VPC n'apparaît pas dans /etc/resolv.conf, vérifiez le résolveur DNS personnalisé.

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

Utilisation de règles de résolveur et de zones hébergées privées

Si la règle du résolveur et le nom de domaine de la zone hébergée privée correspondent, la règle du résolveur est prioritaire. Pour plus d'informations, reportez-vous à Considérations relatives à l'utilisation d'une zone hébergée privée. Dans ce cas, la requête DNS est envoyée à l'adresse IP configurée comme cible dans la règle du résolveur.

Utilisation d’une zone hébergée privée sans aucune règle de résolveur

Vérifiez qu'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 publique et d'une zone hébergée privée pour le domaine associé à un VPC. Il s'agit d'un DNS split-view ou split-horizon. Dans ce cas, les clients du VPC ne peuvent pas résoudre les enregistrements créés dans la zone hébergée publique. Si l'enregistrement n'est pas présent dans la zone hébergée privée, le DNS du VPC ne bascule pas dans la zone hébergée publique.

Utilisation de règles de résolveur sans aucune zone hébergée privée

Consultez les règles de résolveur Route 53. Si une règle correspond au nom de domaine, la requête sur le domaine est dirigée vers les adresses IP cibles configurées. Cela signifie que la requête n'est pas acheminée vers les résolveurs publics par défaut.

Déterminez si le problème est dû à une mise en cache négative

La mise en cache négative est le processus de stockage dans le cache d’une réponse négative d'un serveur de noms qui fait autorité. Une réponse NXDOMAIN est considérée comme une réponse négative. Prenons l'exemple suivant :

Un client effectue une requête DNS pour neg.example.com et reçoit un code de réponse NXDOMAIN parce que l'enregistrement neg.example.com n'existe pas.

Cet utilisateur est également propriétaire de example.com. Il crée donc un enregistrement pour neg.example.com. L'utilisateur continue de recevoir une réponse NXDOMAIN lorsque les utilisateurs d'autres réseaux parviennent à résoudre l'enregistrement.

Lorsque l'utilisateur adresse une requête à neg.example.com avant de créer l'enregistrement, il reçoit une réponse NXDOMAIN. Si l'utilisateur a activé la mise en cache négative dans les paramètres du résolveur, le résolveur met cette réponse en cache. Une fois que l'utilisateur a créé l'enregistrement, il effectue à nouveau la requête. Le résolveur avait précédemment reçu cette requête et l'avait mise en cache. Il a donc renvoyé la réponse depuis le 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 parmi les suivantes :

• La valeur TTL minimale de l'enregistrement Start of Authority (SOA)
• La valeur TTL de l'enregistrement SOA pour mettre en cache la réponse NXDOMAIN

Pour vérifier si vous avez déterminé le problème, envoyez une requête directement au serveur de noms pour voir si vous obtenez une réponse. Exemple :

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