Dépannage

Cette page fournit des solutions aux problèmes courants que vous pouvez rencontrer lors de l'utilisation de Cloud DNS pour créer des zones privées, des zones de recherche inversées, des zones de transfert et des enregistrements de ressources.

Zones privées

Cette section traite des problèmes de zones privées.

Problèmes de zones privées dans les projets de service VPC partagé

Pour prendre connaissance d'informations importantes sur l'utilisation des zones privées avec des VPC partagés, consultez la section Zones privées et VPC partagé.

Impossible de créer une zone privée, de répertorier ou de créer des règles

Vous devez disposer du rôle d'administrateur DNS pour effectuer diverses actions de zones privées, telles que répertorier les règles de serveur DNS (Domain Name System) ou créer une zone privée. Ce rôle peut être attribué via l'outil Identity and Access Management (IAM).

Zones privées non résolues dans le même réseau VPC

Assurez-vous que vous effectuez le test à partir d'une instance de VM dont l'interface principale est sur le même réseau que la zone privée que vous avez créée.

Une instance de machine virtuelle (VM) envoie tout le trafic à partir de son interface principale, sauf si le trafic est destiné à un sous-réseau connecté à l'une des autres interfaces ou si la VM a un routage configuré à partir de règles. Assurez-vous que l'interface principale de votre VM de test est installée sur le même réseau que la zone privée que vous testez.

Déterminez si votre VM utilise :

gcloud compute instances describe ${VM_NAME} \
     --zone=${GCE_ZONE} \
     --format="csv[no-heading](networkInterfaces['network'])"

Assurez-vous que le réseau figure dans la liste des réseaux autorisés à effectuer une recherche dans votre zone privée :

gcloud dns managed-zones describe ${PRIVATE_ZONE_NAME} \
     --format="csv(privateVisibilityConfig['networks'])"

Vérifiez que le nom DNS dans la requête correspond à votre zone

Google Cloud utilise la correspondance du suffixe le plus long pour décider de la zone à interroger pour un nom DNS donné. Assurez-vous que le suffixe de l'enregistrement que vous interrogez correspond à au moins une zone privée accessible sur votre réseau VPC. Par exemple, Google Cloud recherche d'abord myapp.dev.gcp.example.lan dans une zone qui diffuse dev.gcp.example.lan, s'il est accessible, avant de le rechercher dans une zone diffusant gcp.example.lan, s'il est accessible.

La sortie de la commande suivante montre le suffixe DNS pour une zone privée donnée :

gcloud dns managed-zones describe ${PRIVATE_ZONE_NAME} \
--format="csv[no-heading](dnsName)"

Demandez le nom DNS à l'aide du serveur de métadonnées

Utilisez la commande dig pour envoyer la requête de nom DNS directement au serveur de métadonnées Google Cloud, 169.254.169.254 :

dig ${DNS_NAME} @169.254.169.254

Utilisez la commande dig pour interroger le serveur de noms par défaut de la VM :

dig ${DNS_NAME}

Si le résultat des deux commandes dig produit des réponses différentes, vérifiez la section ;; SERVER: de la deuxième commande. Le serveur qui répond doit être le serveur de métadonnées, 169.254.169.254. Si ce n'est pas le cas, cela signifie que vous avez configuré le système d'exploitation invité pour utiliser un serveur de noms DNS personnalisé au lieu du serveur de métadonnées Google Cloud par défaut. La résolution des noms dans les zones privées Cloud DNS requiert l'utilisation du serveur de métadonnées. L'environnement invité Linux et l'environnement invité Windows le font automatiquement. Si vous avez importé l'image que vous utilisez pour une VM, vérifiez que l'environnement invité approprié a bien été installé.

Impossible de résoudre les zones privées via Cloud VPN ou Cloud Interconnect

Tout d'abord, assurez-vous que vous pouvez bien interroger et résoudre le nom DNS depuis un réseau VPC autorisé.

Vérifiez la connectivité via Cloud VPN ou Cloud Interconnect

Assurez-vous que la connectivité d'un système sur site à votre réseau VPC est opérationnelle. Plus précisément, le trafic TCP et UDP sur le port 53 doit pouvoir quitter votre réseau sur site et être acheminé sur votre réseau VPC. Vérifiez la configuration des pare-feu sur site pour vous assurer que ce trafic de sortie est autorisé.

Vous pouvez également utiliser n'importe quel protocole, tel que ping (ICMP), pour tester la connectivité à un exemple de VM de votre réseau VPC à partir de l'environnement sur site. Bien que les requêtes Cloud DNS ne soient pas envoyées aux VM Google Cloud, le test de la connectivité à un exemple de VM vous permet de vérifier la connectivité via un tunnel Cloud VPN ou une connexion Cloud Interconnect. Veillez à configurer une règle de pare-feu d'autorisation d'entrée appropriée pour l'exemple de VM Google Cloud, car la règle implicite d'entrée interdite bloque tout le trafic entrant.

Assurez-vous que le transfert entrant est activé pour le réseau VPC autorisé

Le transfert entrant doit être activé pour chaque réseau VPC autorisé à interroger votre zone privée Cloud DNS. Utilisez la commande suivante pour répertorier toutes les règles :

gcloud dns policies list

Identifiez le réseau dans la table de sortie et vérifiez si le champ Transfert est activé pour savoir si le transfert est activé.

Assurez-vous que le réseau autorisé est un réseau VPC

Le transfert DNS nécessite des sous-réseaux qui ne sont disponibles que pour les réseaux VPC, et non pour les anciens réseaux.

gcloud compute networks list \
     --format="csv[no-heading](name, SUBNET_MODE)"

Les réseaux existants sont identifiés en sortie en tant que LEGACY.

Assurez-vous qu'une adresse de transfert DNS valide est réservée sur ce réseau

La commande suivante affiche toutes les adresse IP de transfert DNS réservées dans votre projet.

gcloud compute addresses list \
     --filter="purpose=DNS_RESOLVER" \
     --format='csv[no-heading](address, subnetwork)'

Vous pouvez ajouter une clause AND au filtre pour limiter la sortie au seul sous-réseau qui vous intéresse.

Exemple :

--filter="name ~ ^dns-forwarding AND subnetwork ${subnetwork-name}"

Si aucune adresse IP ne s'affiche dans le réseau/la région auquel vous vous attendiez, envoyez une demande à l'assistance Google Cloud.

Exécutez la commande dig pointant vers la requête à l'adresse trouvée dans la commande ci-dessus. Faites-le depuis une VM du même réseau. Ce test vérifie que le redirecteur entrant fonctionne et que le problème réside ailleurs.

dig ${DNS_NAME} @10.150.0.1 # address returned by previous command

Répétez la même commande dig, mais à partir d'un hôte sur site sur le VPN.

L'enregistrement CNAME défini dans une zone privée ne fonctionne pas

Les enregistrements CNAME faisant référence à d'autres enregistrements de la même zone privée sont acceptés. Ceux qui pointent vers des noms de domaine définis dans d'autres zones privées, dans des zones internes ou sur Internet ne le sont pas.

Zones de recherche inversée

Cette section fournit des conseils de dépannage pour les zones de recherche inversée. Certains problèmes affectant les zones privées concernent également les zones de recherche inversée. Pour obtenir des conseils supplémentaires, consultez la section de dépannage pour les zones privées.

VM non résolue avec adresse non-RFC 1918

Remédiez à la non-résolution des VM associées à une adresse non-RFC 1918

Si vous avez créé une VM avec une adresse non-RFC 1918 pendant la phase alpha de Cloud DNS avant le lancement de la version compatible, ces VM risquent de ne pas être résolues correctement. Pour résoudre ce problème, mettez en veille et redémarrez vos VM.

Zones de transfert

Cette section fournit des conseils de dépannage pour les zones de transfert. Certains problèmes des zones privées concernent également les zones de transfert. Pour obtenir des conseils supplémentaires, consultez la section de dépannage pour les zones privées.

Les zones de transfert (transfert sortant) ne fonctionnent pas

Tout d'abord, assurez-vous que vous pouvez bien interroger et résoudre le nom DNS depuis un réseau VPC autorisé.

Le transfert de requêtes depuis des VM dans un réseau VPC consommateur vers un réseau VPC producteur ne fonctionne pas

Si vous utilisez l'appairage DNS et souhaitez transférer des requêtes à partir de VM d'un réseau VPC consommateur vers un réseau VPC producteur, puis vers un ou plusieurs serveurs de noms sur site, vous devez vous assurer que le réseau VPC producteur dispose d'une VM ou d'un tunnel VPN dans la même région que le sous-réseau utilisé par les VM clientes.

Par exemple, supposons que le VPC1 utilise une zone d'appairage qui envoie les requêtes destinées à example.com. au VPC2. Supposons également que le VPC2 comporte une zone de transfert privée pour example.com. qui transmet les requêtes à un serveur de noms sur site à l'aide d'un tunnel Cloud VPN ou de Cloud Interconnect. Pour qu'une VM située dans la région us-east1 du VPC1 puisse interroger example.com., le VPC2 doit également disposer d'une VM ou d'un tunnel VPN situé dans la région us-east1.

Vérifiez la connectivité via Cloud VPN ou Cloud Interconnect

Vous pouvez également utiliser n'importe quel protocole, tel que ping (ICMP), pour tester la connectivité à un exemple de VM de votre réseau VPC à partir de l'environnement sur site. Vous devez également essayer d'interroger votre serveur de noms sur site, directement à partir d'un exemple de VM Google Cloud, à l'aide d'un outil tel que dig :

dig ${DNS_NAME} @192.168.x.x # address of the onprem DNS server

Vérifiez les règles de pare-feu dans votre réseau VPC

La règle implicite d'autorisation de sortie du pare-feu autorise les connexions sortantes et les réponses établies depuis les VM de votre réseau VPC, à moins que vous n'ayez créé des règles personnalisées pour interdire la sortie. Si vous avez créé des règles de refus de sortie personnalisées, vous devez créer des règles d'autorisation de priorité plus élevée autorisant au moins la sortie sur vos serveurs de noms sur site.

Vérifiez le pare-feu sur site

Assurez-vous que votre pare-feu sur site est configuré pour autoriser le trafic entrant et sortant associé à la plage d'adresses 35.199.192.0/19.

Consultez les journaux de votre pare-feu sur site pour rechercher les requêtes DNS provenant de la plage d'adresses 35.199.192.0/19. Pour utiliser une expression regex pour la recherche, exécutez la commande suivante :

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Vérifiez le serveur de noms sur site

Vérifiez qu'aucune liste de contrôle d'accès configurée dans votre serveur de noms sur site ne bloque les requêtes provenant de la plage d'adresses 35.199.192.0/19.

Vérifiez votre serveur de noms sur site pour savoir s'il reçoit les paquets provenant de la plage d'adresses 35.199.192.0/19. Si vous disposez d'un accès à l'interface système, vous pouvez utiliser un outil tel que tcpdump pour rechercher à la fois les paquets entrants et sortants associés à la plage d'adresses 35.199.192.0/19 :

sudo tcpdump port 53 and tcp -vv

Vérifiez les routes de retour

Votre réseau sur site doit disposer d'une route vers la destination 35.199.192.0/19, le saut suivant étant un tunnel VPN pour le même réseau VPC qui a envoyé la requête DNS. Ce comportement est décrit dans la section Créer des zones de transfert.

Si vous utilisez plusieurs tunnels VPN pour connecter le même réseau VPC à votre réseau sur site, il n'est pas nécessaire que la réponse soit livrée à l'aide du même tunnel que celui qui l'a envoyée. Toutefois, la réponse doit être fournie à l'aide d'un tunnel VPN avec un saut suivant dans le même réseau VPC à l'origine de la requête.

Si vous avez connecté plusieurs réseaux VPC à votre réseau sur site, vous devez vous assurer que les réponses DNS ne sont pas envoyées au mauvais réseau VPC. Google Cloud ignore les réponses DNS envoyées au mauvais réseau VPC.

L'enregistrement CNAME défini dans une zone privée ne fonctionne pas

Cloud DNS n'accepte pas la résolution récursive d'une adresse IP en utilisant un enregistrement CNAME pointant sur un enregistrement A situé dans une autre zone gérée privée (résolution des enregistrements CNAME). Par exemple, supposons que vous ayez deux zones gérées privées, zone-a.private et zone-b.private, et que vous créiez les enregistrements suivants :

  • Enregistrement CNAME cname.zone-a.private pointant vers target.zone-b.private
  • Enregistrement A target.zone-b.private pointant vers 192.168.1.9

Cloud DNS ne résout pas le problème cname.zone-a.private en tant que 192.168.1.9, car les deux enregistrements ne se trouvent pas dans la même zone (zone-a.private et zone-b.private).

Cloud DNS cherche à résoudre les enregistrements CNAME dans une zone gérée privée.

Le transfert sortant vers un serveur de noms qui utilise une adresse IP non-RFC 1918 échoue

Par défaut, Cloud DNS utilise le routage standard, qui achemine les requêtes via l'Internet public lorsque le serveur de noms cible possède une adresse IP non-RFC 1918. Le routage standard ne prend pas en charge les requêtes de transfert vers des serveurs de noms avec des adresses non-RFC 1918, qui ne sont pas accessibles depuis l'Internet public.

Pour transférer des requêtes vers un serveur de noms qui utilise une adresse IP non-RFC 1918 via votre réseau VPC, configurez la zone de transfert Cloud DNS ou la règle de serveur pour utiliser le routage privé du serveur de noms cible.

Pour plus d'informations sur les différences entre le routage standard et le routage privé, consultez la section Cibles de transfert et méthodes de routage.

Cette limitation s'applique même s'il existe une route VPC vers le serveur de noms cible. Les adresses non-RFC 1918 n'ont aucun effet sur le comportement du transfert sortant de Cloud DNS lorsque le routage standard est configuré.

Échec du transfert sortant vers une carte d'interface réseau secondaire

Actuellement, Cloud DNS ne permet pas le transfert vers les cartes d'interface réseau secondaires des VM Compute Engine.

Les requêtes sortantes transférées reçoivent des erreurs SERVFAIL.

Le plan de contrôle Cloud DNS utilise un algorithme pour déterminer la réactivité d'une cible de transfert. Le score de réactivité se base sur le nombre d'erreurs SERVFAIL et la latence des réponses reçues. Les erreurs SERVFAIL ont un impact plus important sur le score que la latence. Ces scores sont réinitialisés toutes les heures.

Si toutes les cibles d'une zone ont des scores faibles, Cloud DNS n'enverra pas de requêtes à ces cibles. Un ou plusieurs des problèmes suivants peuvent apparaître :

  • L'utilisation du transfert Cloud DNS génère une erreur SERVFAIL rapide (~2 ms).
  • Dans les journaux Cloud Logging pour les requêtes, les champs destinationIP, egressIP et egressError ne sont pas renseignés.
  • Les tentatives de requête ne s'affichent pas sur vos serveurs DNS.
  • Les requêtes que vous envoyez directement aux cibles de transfert (par exemple, dig @<TARGET> <QNAME>) peuvent aboutir.

Pour résoudre ce problème, vérifiez que vos serveurs de noms sur site sont correctement configurés. Ensuite, vérifiez que vos serveurs de noms sur site répondent aux requêtes dans un délai de 4 secondes. Si vos serveurs de noms sur site consultent des serveurs de noms en amont (par exemple, parce qu'ils sont configurés comme résolveurs de mise en cache), vérifiez que ceux-ci ne présentent aucun problème.

Échec du transfert entrant sur un réseau VPC utilisant des plages d'adresses IP non-RFC 1918

Cloud DNS ne permet pas le transfert entrant si le réseau VPC utilise une plage d'adresses non-RFC 1918.

Enregistrements de ressources

Cette section fournit des conseils de dépannage pour les enregistrements de ressources.

Données inattendues lors de l'interrogation de jeux d'enregistrements de ressources présents dans la zone

Plusieurs raisons peuvent expliquer pourquoi vous recevez des données inattendues lorsque vous interrogez des jeux d'enregistrements de ressources présents dans une zone gérée Cloud DNS :

  1. Les jeux d'enregistrements de ressources créés à l'aide de la syntaxe @ spécifiée dans RFC 1035 ne sont pas acceptés. Cloud DNS interprète littéralement le symbole @ dans ces jeux d'enregistrements de ressources. Par conséquent, dans la zone example.com., un jeu d'enregistrements créé pour le fichier QNAME @ est interprété comme @.example.com. au lieu de example.com.. Pour résoudre ce problème, veillez à créer des jeux d'enregistrements sans le symbole @. Tous les noms sont relatifs à l'apex de la zone.

  2. Comme tous les enregistrements, les enregistrements CNAME génériques sont soumis aux règles d'existence décrites dans la section RFC 4592. Par exemple, supposons que vous définissiez les jeux d'enregistrements suivants dans la zone example.com. :

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    Une requête destinée à public.srv1.images.example.com. renvoie NOERROR avec une section de réponse vide. L'existence d'un enregistrement entre CNAME et QNAME empêche le retour de CNAME, mais il n'existe aucun enregistrement correspondant exactement à QNAME. Cloud DNS renvoie donc une réponse vide. Il s'agit d'un comportement DNS standard.

Jeux d'enregistrements de ressources Cloud DNS renvoyés dans un ordre aléatoire

Conformément aux pratiques du secteur DNS, les serveurs de noms Cloud DNS utilisent désormais de manière aléatoire l'ordre des jeux d'enregistrements de ressources et ignorent l'ordre fourni par le serveur faisant autorité. Il s'agit d'un comportement DNS normal, qui s'applique à la fois aux zones Cloud DNS publiques et privées.

Étape suivante