Comment tester et confirmer que le sous-domaine délégué effectue correctement la résolution ? En cas de non résolution, comment procéder au dépannage et résoudre l'erreur ?

Lorsque vous disposez d'une zone parent pour votre domaine apex (tel que example.com) configuré avec Amazon Route 53 ou un fournisseur DNS tiers, vous pouvez configurer un ensemble de délégations pour un sous-domaine (tel que www.example.com) avec Route 53 ou un fournisseur DNS tiers.

Si vous utilisez un ensemble de délégations distinct pour votre sous-domaine, vous pouvez avoir les configurations suivantes :

  • Un domaine apex et un sous-domaine qui utilisent tous les deux Route 53
  • Un domaine apex qui utilise un service DNS tiers et un sous-domaine qui utilise Route 53
  • Un domaine apex qui utilise Route 53 et un sous-domaine qui est délégué à un service DNS tiers

Suivez la résolution en fonction de votre configuration.

Un domaine apex et un sous-domaine qui utilisent tous les deux Route 53

1.    Utilisez la commande dig +trace pour vérifier que votre sous-domaine se résout correctement.

2.    Assurez-vous que vous avez un type d'enregistrement de votre choix sous la zone hébergée de votre sous-domaine. Pour ce test, il y a un enregistrement A pour www.example.com sous la zone du sous-domaine. Notez la sortie de dig par rapport au type d'enregistrement souhaité :

dig <record type> <desired subdomain record>

Exemple de sortie :

$ dig www.example.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48170
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.example.com.                IN         A
;; ANSWER SECTION:
www.example.com.     60          IN         A          127.0.0.1

3.    Si la recherche DNS échoue, utilisez les sorties dig et dig +trace pour identifier l'endroit de la chaîne DNS où la recherche a échouée.

Exemple de sortie :

$dig +trace www.example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.56.amzn1 <<>> +trace www.example.com
;; global options: +cmd
.                                   518400 IN         NS        G.ROOT-SERVERS.NET.
.....
.                                   518400 IN         NS        F.ROOT-SERVERS.NET.
;; Received 228 bytes from 169.xxx.xxx.xxx#53(169.xxx.xxx.xxx) in 21 ms
com.                            172800 IN         NS        c.gtld-servers.net.
.....
com.                            172800 IN         NS        i.gtld-servers.net.
;; Received 498 bytes from 199.xxx.xxx.xxx #53(199.xxx.xxx.xxx) in 198 ms
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.com.
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.net.
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.co.uk.
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.org.
;; Received 207 bytes from 192.xxx.xxx.xxx #53(192.xxx.xxx.xxx) in 498 ms
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.com.
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.net.
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.co.uk.
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.org.
;; Received 175 bytes from 205.xxx.xxx.xxx #53(205.xxx.xxx.xxx) in 345 ms
www.example.com.     900      IN         SOA      ns-xxx.awsdns-xx.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig www.example.com.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22072
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
www.example.com.com.          IN         A
;; AUTHORITY SECTION:
www.example.com.com. 60       IN         SOA      ns-xxx.awsdns-xx.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

4.    Vérifiez la sortie pour identifier la raison de l'échec :

dig renvoie un statut NOERROR sans section ANSWER, et la sortie dig +trace inclut seulement les serveurs de noms du domaine apex :

L'enregistrement NS pour votre sous-domaine délégué est manquant dans la zone hébergée de votre domaine apex. De même, le type d'enregistrement (par exemple, un enregistrement MX à la place d'un enregistrement A) pour le sous-domaine sous le domaine racine est erroné. Créez un enregistrement NS sous la zone hébergée de votre domaine apex pour votre sous-domaine avec les serveurs de noms corrects.

Supprimez l'enregistrement non NS pour le sous-domaine sous la zone hébergée du domaine apex. Ensuite, placez l'enregistrement non NS sous la zone hébergée du sous-domaine.

dig renvoie le statut NXDOMAIN et la sortie dig +trace inclut seulement les serveurs de noms du domaine apex :

L'enregistrement NS pour votre sous-domaine délégué est manquant sous la zone hébergée de votre domaine apex.

Créez un enregistrement NS sous la zone hébergée de votre domaine apex avec les serveurs de noms corrects.

dig +trace renvoie vos serveurs de noms pour le sous-domaine délégué, mais dig renvoie le statut NOERROR sans section ANSWER :

La zone hébergée contient un enregistrement de type erroné pour votre sous-domaine délégué. Il existe un enregistrement TXT au lieu d'un enregistrement A pour votre sous-domaine sous la zone hébergée du sous-domaine.

Créez un nouvel enregistrement A pour le sous-domaine délégué sous la zone hébergée du sous-domaine.

dig +trace renvoie les serveurs de noms pour le sous-domaine délégué, mais dig renvoie l'erreur « connection timed out; no servers could be reached » (délai d'attente de connexion dépassé ; aucun serveur ne peut être atteint) :

Les serveurs de noms Route 53 dans l'enregistrement NS pour votre sous-domaine délégué sous la zone hébergée de votre domaine apex sont incorrects. Confirmez ce problème en procédant à une recherche DNS sur un des serveurs de noms du sous-domaine délégué à l'aide de la commande dig @. Un serveur de noms incorrect renvoie un statut REFUSED (REFUSÉ).

Modifiez l'enregistrement NS et indiquez les serveurs de noms corrects pour la zone hébergée de votre sous-domaine.

5.    Si la recherche sur d'autres serveurs DNS aboutit, il est possible que votre résolveur local ait des problèmes de mise en cache.

Utilisez la commande dig @ avec un autre résolveur et votre nom de domaine pour contourner votre résolveur local. Par exemple, cette recherche utilise le résolveur public de Google :

dig @8.8.8.8 www.example.com 

Effectuez la recherche directement sur un des serveurs de noms AWS faisant autorité pour la zone hébergée du domaine apex :

dig @ns-***.awsdns-**.com www.example.com

Un domaine apex qui utilise un service DNS tiers et un sous-domaine qui utilise Route 53

1.    Confirmez que les serveurs de noms pour le sous-domaine sont configurés correctement dans la zone parent.

2.    Si ce n'est pas le cas, recherchez les enregistrements NS pour la zone hébergée de votre sous-domaine, puis ajoutez-les à la zone hébergée de votre domaine apex ou au fichier de zone avec le fournisseur DNS tiers.

3.    Utilisez dig @ pour vous assurer que le sous-domaine procède à la résolution en utilisant un des serveurs de noms de sa zone hébergée :

dig @ns-***.awsdns-**.com www.example.com

Remarque : si la résolution DNS échoue, consultez la section Dépannage des échecs de recherche DNS pour identifier et éliminer les raisons de l'échec.

Un domaine apex qui utilise Route 53 et un sous-domaine qui est délégué à un tiers

1.    Confirmez que les serveurs de noms pour le sous-domaine sont configurés correctement dans la zone parent.

2.    Si ce n'est pas le cas, ajoutez des enregistrements NS sous la zone hébergée pour votre domaine apex dans Route 53.

3.    Utilisez dig @ avec un nom de serveur faisant autorité de votre service DNS tiers pour vous assurer que votre sous-domaine procède correctement à la résolution :

dig @<Third party Name Server assigned for www.example.com> www.example.com

Remarque : si la résolution DNS échoue, consultez la section Dépannage des échecs de recherche DNS pour identifier et éliminer les raisons de l'échec.


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support

Date de publication : 31/08/2018