Résoudre les problèmes liés à Cloud DNS

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 publiques, des zones privées,des zones de recherche inversée, des zones de transfert et des enregistrements de ressources.

Zones publiques

Cette section traite des problèmes de zones publiques.

Impossible de créer une zone publique

Si vous rencontrez une erreur attempted action failed, cela signifie que l'API Cloud DNS n'est pas activée sur votre projet.

Pour activer l'API Cloud DNS, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Bibliothèque d'API.

    Accéder à la bibliothèque d'API

  2. Sous Sélectionner un projet récent, sélectionnez le projet Google Cloud dans lequel vous souhaitez activer l'API.

  3. Sur la page Bibliothèque d'API, utilisez la zone Rechercher des API et des services pour rechercher Cloud DNS API. Une page décrivant l'API s'affiche.

  4. Cliquez sur Activer.

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 hors de son interface principale, sauf si le trafic est destiné à un sous-réseau rattaché à l'une des autres interfaces ou si la VM dispose d'un routage de règles configuré. 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 à interroger 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 résout un enregistrement selon l'ordre de résolution des noms, en utilisant la zone avec le 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

Cloud DNS résout uniquement les enregistrements CNAME comme décrit dans la section Résolution d'enregistrements CNAME.

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, 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 que vous souhaitez transférer les requêtes des VM d'un réseau VPC consommateur vers un réseau VPC producteur, puis vers un ou plusieurs serveurs de noms sur site, assurez-vous que l'une des conditions préalables suivantes est remplie:

  • Le mode de routage dynamique du réseau VPC du producteur est défini sur GLOBAL.

  • La VM du réseau VPC consommateur se trouve dans la même région que le tunnel VPN ou Cloud Interconnect du VPC producteur.

  • (VPN classique uniquement) Le réseau VPC du producteur dispose d'une route statique configurée pour envoyer le trafic destiné aux serveurs de noms sur site via le tunnel VPN classique. Le réseau VPC du producteur doit également comporter une VM ou 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 VPN classique.

      Pour qu'une VM située dans us-east1 du VPC1 puisse interroger example.com., le VPC2 doit disposer d'une VM située dans us-east1. Une route statique doit également être configurée pour couvrir les plages CIDR des serveurs de noms sur site, avec le saut suivant configuré comme tunnel VPN classique.

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, où le saut suivant est un tunnel VPN ou une connexion Interconnect 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. Pour obtenir une solution recommandée, consultez notre guide des bonnes pratiques.

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

Assurez-vous d'avoir correctement configuré votre carte d'interface réseau secondaire.

Pour obtenir des instructions sur la configuration de NIC supplémentaires, consultez la page Créer des instances de machines virtuelles avec plusieurs interfaces réseau.

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

Si Cloud DNS reçoit une erreur de tous les serveurs de noms cibles ou ne reçoit aucune réponse de l'un des serveurs de noms cibles, une erreur SERVFAIL est renvoyée.

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 depuis la plage d'adresses Cloud DNS décrite dans la section Ouvrir Google Cloud et les pare-feu sur site pour autoriser le trafic DNS.{ 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.

De plus, si la cible de transfert est un système sur site, sachez que les routes configurées pour ce chemin peuvent être des routes dynamiques personnalisées ou des routes statiques personnalisées. Toutefois, il est important de souligner que les routes statiques personnalisées avec des tags réseau ne sont pas valides pour le transfert des requêtes DNS. Assurez-vous que la route utilisée pour accéder au serveur de noms sur site ne spécifie pas de tag de réseau.

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.

La VM Google Cloud affiche des enregistrements PTR incorrects

Lorsqu'une VM est migrée lors d'un événement de maintenance, la logique d'enregistrement PTR ne gère pas correctement certains cas marginaux et rétablit les enregistrements PTR DNS au nom de domaine complet googleusercontent.com. Pour restaurer les fonctionnalités, appliquez à nouveau l'enregistrement PTR.

Pour en savoir plus sur l'application des enregistrements PTR sur une VM, consultez la page Créer un enregistrement PTR pour une instance de VM.

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.

Type de ressource zonale non compatible

Lorsque vous saisissez l'option --location dans une commande gcloud ou une requête API pour une fonctionnalité qui cible une autre zone Cloud DNS, la requête est refusée. Par exemple, si vous envoyez une demande de fonctionnalité zonale uniquement à un serveur global ou une requête de fonctionnalité globale uniquement à un serveur zonal, le serveur rejette la requête et renvoie une erreur _UNSUPPORTED_ZONAL_RESOURCETYPE.

Pour obtenir la liste des ressources et des fonctionnalités compatibles avec Cloud DNS zonal, consultez la page Compatibilité avec Cloud DNS zonal.

Étape suivante