Comment résoudre les problèmes liés aux réponses NXDOMAIN lors de l'utilisation de Route 53 en tant que service DNS ?
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
Contenus pertinents
- demandé il y a 8 moislg...
- demandé il y a un anlg...
- demandé il y a 10 moislg...
- demandé il y a un moislg...
- AWS OFFICIELA mis à jour il y a 10 mois
- AWS OFFICIELA mis à jour il y a 8 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 5 mois