Dépannage

Cette page décrit les erreurs que vous pourriez rencontrer en utilisant Cloud DNS et vous indique comment les gérer.

Zones gérées

Cette section répertorie les erreurs relatives aux zones gérées.

invalidFieldValue

La valeur "entity.managedZone.name" n'est pas valide.

L'opération de création de zone gérée peut échouer et renvoyer cette erreur si le nom de la zone gérée ne commence pas par une lettre, s'il se termine par une lettre ou un chiffre, ou s'il contient uniquement des lettres minuscules, des chiffres ou des traits d'union.

managedZoneDnsNameNotAvailable

La zone gérée spécifiée n'est pas disponible, elle ne peut pas être créée.

L'opération de création de zone gérée peut échouer et renvoyer cette erreur pour les raisons suivantes :

  • Le nom DNS de la zone proposée est réservé, par exemple le point final correspondant au domaine racine (.), .com ou .co.uk.
  • Il n'y a plus de serveurs de noms disponibles pour héberger le nom DNS de la zone. Cloud DNS utilise un pool de serveurs de noms dont la capacité limite est atteinte. Une requête DNS sur n'importe quel serveur de noms doit pouvoir être associée sans ambiguïté à une zone gérée spécifique.

Action recommandée : si vous êtes le propriétaire enregistré du nom DNS en question, vérifiez la présence éventuelle de zones de chevauchement. En ce qui concerne la configuration DNS pour un domaine et ses sous-domaines, nous recommandons de créer une seule zone racine et d'ajouter des enregistrements pour chaque sous-domaine dans cette zone.

verifyManagedZoneDnsNameOwnership

Veuillez valider la propriété du domaine "EXAMPLE.COM" (ou d'un domaine parent) à l'adresse http://www.google.com/webmasters/verification/ puis réessayer.

Action recommandée : Lorsque vous recevez cette erreur, vous devez valider la propriété du domaine, puis réessayer.

Enregistrements

Les erreurs présentées dans cette section concernent les enregistrements.

containerNotEmpty

La ressource spécifiée ne peut pas être supprimée car elle n'est pas vide.

Action recommandée : Si vous souhaitez supprimer la ressource, vous devez au préalable supprimer son contenu.

invalidZoneApex

Le jeu d'enregistrements de ressources spécifié n'est pas valide car une zone doit contenir exactement un jeu d'enregistrements de ressources d'un certain type au niveau de l'apex.

"Apex" dans le contexte DNS correspond simplement au nom DNS ayant le plus petit nombre de libellés autorisé dans la zone. L'apex d'une zone est le nom DNS équivalent à ManagedZone.dnsName.

Cette erreur signifie que vous avez tenté d'apporter une modification qui ne respecte pas une règle DNS de l'apex de la zone. Les actions suivantes peuvent provoquer cette erreur :

  • Vous avez essayé de supprimer le jeu d'enregistrements de ressources NS requis au niveau de l'apex.
  • Vous avez essayé de supprimer le jeu d'enregistrements de ressources SOA requis au niveau de l'apex.
  • Vous avez essayé de créer un jeu d'enregistrements de ressources de type SOA, mais pas au niveau de l'apex.

Action recommandée : Si vous rencontrez cette erreur, cela signifie que vous tentez d'effectuer une opération qui n'est pas autorisée par les règles du DNS. Vérifiez votre requête. Il n'y a aucune raison de supprimer ces jeux d'enregistrements de ressources requis.

invalidRecordCount

Le jeu d'enregistrements de ressources "entity.change.additions [XX]" ne peut contenir qu'un seul enregistrement car il est de type "<SOA_OR_CNAME>".

Les règles du DNS stipulent que certains jeux d'enregistrements de ressources ne peuvent contenir qu'un seul type d'enregistrement de ressource. Actuellement, ce type peut être SOA ou CNAME. Cette erreur se produit si vous essayez de créer une modification non conforme à ces règles. Exemple :

{
  kind: "dns#rrset"
  name: "blog.foo.com.",
  type: "CNAME",
  rrdata: [ "www.foo.com.", "www2.foo.com." ],
  ...
}

Action recommandée : Si vous rencontrez cette erreur, vérifiez votre requête. Cette erreur indique que vous tentez d'effectuer une opération qui n'est pas autorisée.

cnameResourceRecordSetConflict

Le jeu d'enregistrements de ressources "entity.change.additions [XX]" n'est pas valide car le nom DNS "EXAMPLE.COM" peut être associé soit à un jeu d'enregistrements de ressources CNAME, soit à des jeux d'enregistrements de ressources d'autres types, mais pas aux deux.

Cette erreur peut se produire lorsque vous créez deux types de jeux d'enregistrements de ressources, tels qu'un enregistrement A et un enregistrement CNAME pour le même nom DNS. Une cause courante de cette erreur est la tentative de création d'un enregistrement CNAME au niveau de l'apex de la zone. Cela n'est pas possible car cet enregistrement entrerait en conflit avec les enregistrements SOA et NS requis associés au même nom.

Action recommandée : Choisissez un type d'enregistrement ou l'autre.

wildcardNotAllowed

Le jeu d'enregistrements de ressources spécifié n'a pas le bon type pour obtenir le statut d'enregistrement générique.

Dans le système DNS, un enregistrement générique est un type particulier de jeu d'enregistrements de ressources qui permet le traitement des requêtes concernant des noms de domaine qui n'existent pas. Cloud DNS ne permet pas encore de créer des jeux d'enregistrements de ressources génériques de type NS.

Action recommandée : Les jeux d'enregistrements de ressources génériques de type NS ne sont pas acceptés pour le moment. Contactez l'assistance ou rejoignez notre groupe de discussion cloud-dns-discuss pour nous expliquer ce que vous tentez de mettre en œuvre.

invalidValue

Il s'agit d'un message d'erreur générique indiquant qu'un élément de votre requête n'est pas valide. Ce type de message n'est pas lié à l'état du serveur. Le message d'erreur inclut le chemin d'accès à la partie problématique de la requête, ainsi que la valeur non valide. Les opérations pouvant entraîner cette erreur sont multiples :

  • Vous avez spécifié un jeu d'enregistrements de ressources avec un nom qui n'est pas valide. Par exemple, "foo..bar" n'est pas un nom DNS valide (libellé central absent).
  • Vous avez spécifié un jeu d'enregistrements de ressources dont le type n'est pas valide. Par exemple, A et CNAME sont des types valides, mais pas "XXX".
  • Vous avez spécifié un jeu d'enregistrements de ressources ne comportant aucun enregistrement.
  • Vous avez spécifié des données d'enregistrement de ressources non valides. Par exemple, "1.1.1.1" est une donnée d'enregistrement de ressource valide pour le type A. "XXX "est une donnée d'enregistrement de ressource non valide pour le type A.
  • Vous avez spécifié un jeu d'enregistrements de ressources dont le TTL n'est pas valide. Le TTL doit être un entier non négatif.
  • Vous avez spécifié un nom de ressource trop long.

Action recommandée : Corrigez votre requête.

Erreurs générales

Cette section décrit les erreurs générales.

alreadyExists

La ressource spécifiée existe déjà. Vous ne pouvez pas créer de doublons.

Action recommandée : Lorsque vous créez une ressource, utilisez l'API get/list appropriée pour identifier les ressources qui existent déjà.

Si vous rencontrez cette erreur lors de l'ajout d'enregistrements, cela signifie qu'un enregistrement individuel est traité comme un jeu d'enregistrements, c'est-à-dire que chaque entrée (si vous en avez plusieurs) agit comme un enregistrement différent. Lorsque vous ajoutez deux valeurs ou chaînes au jeu d'enregistrements pour le même nom DNS, vous devez insérer un espace entre la première et la deuxième valeur.

accessNotConfigured

Accès non configuré

Pour résoudre ce problème, vous devez activer l'API Cloud DNS pour votre projet.

inactiveBillingState

Le projet "EXAMPLE_PROJECT" ne peut pas accepter de requêtes tant que la facturation n'est pas activée. L'activation de la facturation peut prendre plusieurs minutes.

Action recommandée : Activez la facturation au niveau de la section Paramètres de votre projet dans Cloud Console.

preconditionFailed

Il s'agit d'un message d'erreur générique indiquant qu'un élément de la requête n'est pas compatible avec l'état actuel de la ressource serveur. Le client doit tenter de corriger sa requête, puis réessayer. Cela peut se produire si vous envoyez une demande de modification create qui tente de supprimer un jeu d'enregistrements de ressources ne correspondant pas à celui qui existe déjà (même nom et même type).

Contrôlez à nouveau l'état actuel de la zone et décidez de ce que vous souhaitez supprimer. Il est possible que cet état ait été modifié depuis la dernière fois que vous l'avez vérifié.

Le message d'erreur inclut le chemin d'accès vers la partie de votre requête qui pose problème. Par exemple, entity.change.deletions[6] fait référence au 7e élément du tableau "deletions" de l'objet "change" dans le corps du message POST de votre requête.

Action recommandée : Corrigez la partie de la requête identifiée comme problématique.

required

Il s'agit d'un message d'erreur générique indiquant qu'un élément obligatoire n'est pas présent dans la requête. Par exemple, pour effectuer une requête de création de zone gérée, il est nécessaire d'indiquer un nom, un nom DNS et une description. Si l'un de ces éléments est manquant, la requête échouera et renverra cette erreur.

Action recommandée : Renseignez le paramètre requis et réessayez.

notFound

La ressource spécifiée n'existe pas.

Action recommandée : Assurez-vous que vous utilisez le nom d'une ressource existante.

quotaExceeded

Ce message d'erreur indique qu'une modification imminente entraînera le dépassement de votre quota actuel. Par exemple, vous ne pouvez créer qu'un certain nombre de jeux d'enregistrements de ressources dans chaque zone. Le quota est associé au projet. Si vous avez besoin d'une augmentation de quota, vous devez vous adresser au service client de Google. Les nouveaux projets ont un quota par défaut. Reportez-vous à l'opération Projects.get pour connaître toutes les différentes dimensions pour lesquelles DNS impose des limites.

Action recommandée : Vérifiez votre projet pour comprendre pourquoi vous utilisez déjà dans de si grandes proportions la ressource concernée. Vous pouvez demander une augmentation de quota en accédant à la page Quotas de Cloud Console pour le projet dont vous souhaitez augmenter le quota. Consultez également la section Utiliser des quotas.

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é

Reportez-vous à la section Zones privées et VPC partagé de la page de présentation pour prendre connaissance d'informations importantes sur l'utilisation des zones privées avec des réseaux VPC partagés.

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 zone privée, telles que répertorier les règles de serveur DNS ou créer une zone privée. Ce rôle peut être attribué via l'outil Cloud IAM.

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

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

Une 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. De ce fait, assurez-vous que l'interface principale de votre VM se trouve sur le même réseau que la zone privée que vous testez.

Déterminez le réseau utilisé par votre VM :

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 recherchera 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.

Le résultat 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, vous devez vérifier que l'environnement invité approprié a été installé.

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

Tout d'abord, assurez-vous que vous pouvez interroger et résoudre le nom DNS avec succès 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 votre environnement sur site. Bien que les requêtes Cloud DNS ne soient pas envoyées aux VM Google Cloud, un test de connectivité à un exemple de VM vous permet de vérifier la connectivité via un tunnel Cloud VPN ou 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 ci-dessous affiche toutes les adresses IP de redirecteurs 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 vous ne voyez pas d'adresse IP dans le réseau/la région que vous attendiez, veuillez envoyer une demande à l'assistance Cloud.

Exécutez la commande dig en pointant la requête vers l'adresse trouvée 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 command above.

Répétez la même commande dig mais à partir d'une VM 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 des conseils supplémentaires, veuillez consulter la section qui fournit des informations 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 instance de 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égler le problème, il vous suffit d'arrêter et de redémarrer votre VM. La résolution devrait s'effectuer correctement.

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 des conseils supplémentaires, veuillez consulter la section qui fournit des informations 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 interroger et résoudre le nom DNS avec succès 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 effectuer une recherche à l'aide d'une expression régulière, spécifiez "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érifier les routes de retour

Votre réseau sur site doit disposer d'une route vers la plage de destination 35.199.192.0/19. Le saut suivant est un tunnel VPN pour le même réseau VPC qui a envoyé la requête DNS, comme décrit à la page 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 via un enregistrement CNAME pointant sur un enregistrement A situé dans une autre zone gérée privée (recherche de résolution des enregistrements CNAME par requêtes successives). 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 :

  • L'enregistrement CNAME cname.zone-a.private pointant vers target.zone-b.private
  • L'enregistrement A target.zone-b.private pointant vers l'adresse 192.168.1.9

Cloud DNS ne résoudra pas 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

Cloud DNS achemine toujours les requêtes via l'Internet public lorsque le serveur de noms cible possède une adresse IP non-RFC 1918. Les serveurs de noms ayant des adresses non-RFC 1918 qui ne sont pas accessibles à partir de l'Internet public ne peuvent pas être utilisés comme cibles de transfert.

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.

É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 VPC utilisant des plages d'adresses non-RFC 1918

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

Étapes suivantes

  • Consultez la page Présentation pour obtenir plus de contexte sur les fonctionnalités.
  • Consultez la section Assistance pour accéder à d'autres documents susceptibles de vous aider.