Présentation des zones DNS

Cloud DNS accepte différents types de zonespubliques et privées. Ce document fournit des détails sur les différents types de zones et sur leur utilisation.

Zones de transfert

Les zones de transfert Cloud DNS vous permettent de configurer des serveurs de noms cibles pour des zones privées spécifiques. L'utilisation d'une zone de transfert permet de mettre en œuvre le transfert DNS sortant à partir de votre réseau VPC.

Une zone de transfert Cloud DNS est un type spécial de zone privée Cloud DNS. Au lieu de créer des enregistrements dans la zone, vous spécifiez un ensemble de cibles de transfert. Chaque cible de transfert est l'adresse IP d'un serveur DNS situé dans votre réseau VPC ou dans un réseau sur site connecté à votre réseau VPC via Cloud VPN ou Cloud Interconnect.

Cibles de transfert et méthodes de routage

Cloud DNS accepte trois types de cibles et propose des méthodes de routage standard et privé pour la connectivité.

Cible de transfert Description Compatibilité avec le routage standard Compatibilité avec le routage privé Source des requêtes
Type 1 Une adresse IP interne d'une VM Google Cloud ou d'un équilibreur de charge réseau passthrough interne dans le même réseau VPC autorisé à utiliser la zone de transfert. Uniquement les adresses IP RFC 1918 : le trafic est toujours acheminé via un réseau VPC autorisé. Toute adresse IP interne, telle qu'une adresse privée RFC 1918, une adresse IP privée non RFC 1918, ou une adresse IP externe réutilisée de manière privée, à l'exception d'une adresse IP cible de transfert interdite : le trafic est toujours acheminé via un réseau VPC autorisé. 35.199.192.0/19
Type 2 Une adresse IP d'un système sur site, connecté au réseau VPC autorisé à interroger la zone de transfert, à l'aide de Cloud VPN ou Cloud Interconnect Uniquement les adresses IP RFC 1918 : le trafic est toujours acheminé via un réseau VPC autorisé. Toute adresse IP interne, telle qu'une adresse privée RFC 1918, une adresse IP privée non RFC 1918, ou une adresse IP externe réutilisée de manière privée, à l'exception d'une adresse IP cible de transfert interdite : le trafic est toujours acheminé via un réseau VPC autorisé. 35.199.192.0/19
Type 3 Une adresse IP externe d'un serveur de noms DNS accessible à Internet ou l'adresse IP externe d'une ressource Google Cloud par exemple, l'adresse IP externe d'une VM située dans un autre réseau VPC. Uniquement les adresses IP externes routables sur Internet : le trafic est toujours acheminé vers Internet ou vers l'adresse IP externe d'une ressource Google Cloud. Le routage privé n'est pas disponible. Assurez-vous de ne pas le sélectionner. Plages sources du DNS public de Google

Vous pouvez choisir l'une des deux méthodes de routage suivantes lorsque vous ajoutez la cible de transfert à la zone de transfert :

  • Routage standard : achemine le trafic via un réseau VPC autorisé ou sur Internet, selon que la cible de transfert est ou non une adresse IP RFC 1918. Si la cible de transfert est une adresse IP RFC 1918, Cloud DNS classe la cible en tant que cible de type 1 ou de type 2, et achemine les requêtes via un réseau VPC autorisé. Si la cible n'est pas une adresse IP RFC 1918, Cloud DNS classe la cible dans le champ Type 3 et s'attend à ce qu'elle soit accessible sur Internet.

  • Routage privé : achemine toujours le trafic via un réseau VPC autorisé, quelle que soit l'adresse IP de la cible (RFC 1918 ou non). Par conséquent, seules les cibles de type 1 et de type 2 sont acceptées.

Pour accéder à une cible de transfert de type 1 ou de type 2, Cloud DNS utilise les routes du réseau VPC autorisé où se trouve le client DNS. Ces routes définissent un chemin sécurisé vers la cible de transfert :

Pour plus d'informations sur les exigences en termes de réseau pour les cibles de type 1 et de type 2, consultez la section Exigences relatives aux réseaux cibles de transfert.

Adresses IP de cibles de transfert interdites

Vous ne pouvez pas utiliser les adresses IP suivantes pour les cibles de transfert Cloud DNS :

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Ordre de sélection des cibles de transfert

Cloud DNS vous permet de configurer une liste de cibles de transfert pour une zone de transfert.

Lorsque vous configurez deux cibles de transfert ou plus, Cloud DNS utilise un algorithme interne pour sélectionner une cible de transfert. Cet algorithme classe chaque cible de transfert.

Pour traiter une requête, Cloud DNS essaie d'abord une requête DNS en contactant la cible de transfert avec le meilleur classement. Si ce serveur ne répond pas, Cloud DNS répète la requête vers la cible de transfert qui suit dans le classement. Si aucune cible de transfert ne répond, Cloud DNS synthétise une réponse SERVFAIL.

L'algorithme de classement est automatique et les facteurs suivants augmentent le classement d'une cible de transfert :

  • Le nombre le plus élevé possible de réponses DNS réussies traitées par la cible de transfert. Les réponses DNS réussies incluent les réponses NXDOMAIN.
  • La latence (délai aller-retour) la plus faible possible pour la communication avec la cible de transfert.

Utiliser des zones de transfert

Les VM d'un réseau VPC peuvent utiliser une zone de transfert Cloud DNS dans les cas suivants :

  • Le réseau VPC a été autorisé à utiliser la zone de transfert Cloud DNS. Pour utiliser la zone de transfert, vous pouvez autoriser plusieurs réseaux VPC dans le même projet ou entre plusieurs projets, à condition qu'ils appartiennent à la même organisation.

  • L'OS invité de chaque VM du réseau VPC utilise le serveur de métadonnées 169.254.169.254 de la VM comme serveur de noms.

Chevauchement de zones de transfert

Les zones de transfert Cloud DNS étant un type de zone privée gérée par Cloud DNS, vous pouvez créer plusieurs zones qui se chevauchent. Les VM configurées comme décrit ci-dessus résolvent un enregistrement selon l'ordre de résolution des noms, en utilisant la zone avec le suffixe le plus long. Pour en savoir plus, consultez la section Chevauchement de zones.

Mettre en cache et transférer des zones

Cloud DNS met en cache les réponses aux requêtes envoyées aux zones de transfert Cloud DNS. Cloud DNS conserve un cache des réponses des cibles de transfert joignables pendant la durée la plus courte des périodes suivantes :

  • 60 secondes
  • Durée de la valeur TTL (Time To Live) de l'enregistrement

Lorsque toutes les cibles de transfert d'une zone de transfert deviennent injoignables, Cloud DNS conserve son cache des enregistrements précédemment demandés dans cette zone pendant la durée TTL de chaque enregistrement.

Quand utiliser l'appairage

Cloud DNS ne peut pas utiliser le routage transitif pour se connecter à une cible de transfert. Pour illustrer une configuration non valide, prenons le scénario suivant :

  • Vous avez utilisé Cloud VPN ou Cloud Interconnect pour connecter un réseau sur site à un réseau VPC nommé vpc-net-a.

  • Vous avez utilisé l'appairage de réseaux VPC pour connecter le réseau VPC vpc-net-a à vpc-net-b. Vous avez configuré le réseau vpc-net-a pour exporter les routes personnalisées et vpc-net-b pour les importer.

  • Vous avez créé une zone de transfert dont les cibles de transfert se trouvent dans le réseau sur site auquel le réseau vpc-net-a est connecté. Vous avez autorisé vpc-net-b à utiliser cette zone de transfert.

Dans ce scénario, la résolution d'un enregistrement dans une zone diffusée par les cibles de transfert échoue, même si vpc-net-b est connecté à votre réseau sur site. Pour illustrer cet échec, effectuez les tests suivants à partir d'une VM dans vpc-net-b :

  • Interrogez le serveur de métadonnées 169.254.169.254 de la VM pour rechercher un enregistrement défini dans la zone de transfert. Cette requête échoue (normalement), car Cloud DNS n'est pas compatible avec le routage transitif vers les cibles de transfert. Pour utiliser une zone de transfert, vous devez configurer une VM pour qu'elle utilise son serveur de métadonnées.

  • Interrogez la cible de transfert directement pour le même enregistrement. Bien que Cloud DNS n'utilise pas ce chemin, cette requête démontre que la connectivité transitive aboutit.

Vous pouvez résoudre ce scénario non valide à l'aide d'une zone d'appairage Cloud DNS :

  1. Créez une zone d'appairage Cloud DNS autorisée pour vpc-net-b qui cible vpc-net-a.
  2. Créez une zone de transfert autorisée pour vpc-net-a dont les cibles de transfert sont des serveurs de noms sur site.

Vous pouvez effectuer ces étapes dans n'importe quel ordre. Une fois ces étapes effectuées, les instances Compute Engine de vpc-net-a et de vpc-net-b peuvent interroger les cibles de transfert sur site.

Pour savoir comment créer des zones de transfert, consultez la section Créer une zone de transfert.

Zones d'appairage

Une zone d'appairage est une zone privée Cloud DNS qui vous permet d'envoyer des requêtes DNS entre des zones Cloud DNS de différents réseaux VPC. Par exemple, un fournisseur de logiciels en tant que service (SaaS) peut autoriser ses clients à accéder à leurs enregistrements DNS gérés dans Cloud DNS.

Pour effectuer l'appairage DNS, vous devez créer une zone d'appairage privée Cloud DNS et la configurer pour effectuer les résolutions DNS d'un réseau VPC dans lequel les enregistrements de l'espace de noms de cette zone sont disponibles. Le réseau VPC dans lequel la zone d'appairage DNS effectue les résolutions s'appelle réseau de producteurs DNS.

La zone d'appairage n'est visible que par les réseaux VPC sélectionnés lors de la configuration de la zone. Le réseau VPC autorisé à utiliser la zone d'appairage s'appelle le réseau consommateur DNS.

Une fois les ressources Google Cloud du réseau consommateur DNS autorisées, elles peuvent effectuer les résolutions des enregistrements de l'espace de noms de la zone d'appairage, comme si les ressources se trouvaient sur le réseau producteur DNS. Les résolutions des enregistrements de l'espace de noms de la zone d'appairage suivent l'ordre de résolution des noms du réseau producteur DNS.

Les ressources Google Cloud du réseau consommateur DNS peuvent donc effectuer les résolutions des enregistrements de l'espace de noms de la zone à partir des sources suivantes disponibles dans le réseau producteur DNS :

  • Zones gérées privées de Cloud DNS, mises à la disposition du réseau producteur DNS
  • Zones de transfert gérées de Cloud DNS, mises à la disposition du réseau producteur DNS
  • Noms DNS internes de Compute Engine sur le réseau producteur DNS.
  • Autre serveur de noms, si une règle DNS sortante a été configurée dans le réseau producteur DNS.

L'appairage DNS vous permet de faire en sorte qu'un réseau (réseau consommateur DNS) transfère les requêtes DNS à un autre réseau (réseau producteur DNS), qui effectue ensuite des recherches DNS.

Limites d'appairage DNS et points essentiels

Tenez compte des points suivants lorsque vous configurez l'appairage DNS :

  • L'appairage DNS est une relation à sens unique. Il permet aux ressources Google Cloud du réseau consommateur DNS d'effectuer les résolutions des enregistrements de l'espace de noms de la zone d'appairage, comme si les ressources Google Cloud se trouvaient sur le réseau de producteurs DNS.
  • Les réseaux de producteurs et consommateurs DNS doivent être des réseaux VPC.
  • Bien que les réseaux DNS et les réseaux consommateurs DNS appartiennent généralement à la même organisation, l'appairage DNS interorganisationnel est également accepté.
  • L'appairage DNS et l'appairage de réseaux VPC sont des services différents. L'appairage de réseaux VPC ne partage pas automatiquement les informations DNS. L'appairage DNS peut être utilisé conjointement avec l'appairage de réseaux VPC, mais ce dernier n'est pas requis pour l'appairage DNS.
  • L'appairage DNS transitif est possible, mais uniquement via un seul saut transitif. En d'autres termes, vous ne pouvez pas impliquer plus de trois réseaux VPC (le réseau central étant le saut transitif). Par exemple, vous pouvez créer une zone d'appairage dans vpc-net-a qui cible vpc-net-b, puis créer une zone d'appairage dans vpc-net-b qui cible vpc-net-c.
  • Si vous utilisez l'appairage DNS pour cibler une zone de transfert, le réseau VPC cible avec la zone de transfert doit contenir une VM, un rattachement de VLAN ou un tunnel Cloud VPN situé dans la même région que celle de la VM source qui utilise la zone d'appairage DNS. Pour en savoir plus sur cette limite, consultez la section Le transfert de requêtes depuis des VM dans un réseau VPC consommateur vers un réseau VPC producteur ne fonctionne pas.

Pour savoir comment créer une zone d'appairage, consultez la section Créer une zone d'appairage.

Zones de recherche inversée gérées

Une zone de recherche inversée gérée est une zone privée comportant un attribut spécial qui indique à Cloud DNS d'effectuer une recherche PTR sur les données DNS de Compute Engine.

Enregistrements PTR des adresses RFC 1918 dans des zones privées

Pour effectuer des résolutions inverses à l'aide des enregistrements PTR personnalisés des adresses RFC 1918, vous devez créer une zone privée Cloud DNS au moins aussi spécifique que l'une des zones d'exemple suivantes. Cela est dû à la correspondance du suffixe le plus long décrite dans l'ordre de résolution des noms.

Voici quelques exemples de zones :

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... jusqu'à 31.172.in-addr.arpa.

Si vous créez une zone privée Cloud DNS pour les adresses RFC 1918, les enregistrements PTR personnalisés que vous créez pour les VM de cette zone sont remplacés par ceux qui ont été créés par le DNS interne automatiquement. En effet, les enregistrements PTR du DNS interne sont créés dans la liste précédente de zones plus spécifiques.

Par exemple, supposons que vous créiez une zone gérée privée pour in-addr.arpa. avec l'enregistrement PTR suivant pour une VM dont l'adresse IP est 10.1.1.1 :

1.1.1.10.in-addr.arpa. -> test.example.domain

Les requêtes PTR pour 1.1.1.10.in-addr.arpa. sont traitées par la zone DNS interne 10.in-addr.arpa. plus spécifique. L'enregistrement PTR de votre zone privée Cloud DNS pour test.example.domain est ignoré.

Pour remplacer les enregistrements PTR des DNS internes créés automatiquement pour les VM, veillez à créer vos enregistrements PTR personnalisés dans une zone privée au moins aussi spécifique que l'une des zones présentées dans cette section. Par exemple, si vous créez l'enregistrement PTR suivant dans une zone privée pour 10.in-addr.arpa., votre enregistrement remplace celui généré automatiquement : 1.1.1.10.in-addr.arpa. -> test.example.domain

Si vous devez uniquement remplacer une partie d'un bloc réseau, vous pouvez créer des zones privées Cloud DNS inversées plus spécifiques. Par exemple, une zone privée pour 5.10.in-addr.arpa. peut contenir des enregistrements PTR qui remplacent les enregistrements PTR des DNS internes qui sont automatiquement créés pour les VM avec des adresses IP situées dans la plage d'adresse 10.5.0.0/16.

Pour découvrir comment créer une zone de recherche inversée gérée, consultez la section Créer une zone de recherche inversée gérée.

Chevauchement de zones

Deux zones se chevauchent lorsque le nom de domaine d'origine d'une zone est identique à celui de l'autre zone ou lorsqu'il est un sous-domaine de l'origine de l'autre zone. Exemple :

  • Les zones pour gcp.example.com et pour gcp.example.com se chevauchent, car les noms de domaine sont identiques.
  • Les zones pour dev.gcp.example.com et pour gcp.example.com se chevauchent, car dev.gcp.example.com est un sous-domaine de gcp.example.com.

Règles pour les zones qui se chevauchent

Cloud DNS applique les règles suivantes pour les zones qui se chevauchent : * Les zones publiques qui se chevauchent ne sont pas autorisées sur les mêmes serveurs de noms Cloud DNS. Lorsque vous créez des zones qui se chevauchent, Cloud DNS tente de les placer sur des serveurs de noms différents. Si cela n'est pas possible, Cloud DNS ne parvient pas à créer la zone de chevauchement.

  • Une zone privée peut chevaucher n'importe quelle zone publique.

  • Les zones privées prévues pour différents réseaux VPC peuvent se chevaucher. Par exemple, deux réseaux VPC peuvent avoir chacun une VM de base de données nommée database.gcp.example.com dans une zone gcp.example.com. Les requêtes envoyées à database.gcp.example.com reçoivent des réponses différentes en fonction des enregistrements de zone définis dans la zone autorisée pour chaque réseau VPC.

  • Deux zones privées dont l'accès est autorisé depuis le même réseau VPC ne peuvent pas avoir des origines identiques à moins qu'une zone ne soit un sous-domaine de l'autre. Le serveur de métadonnées utilise la correspondance du suffixe le plus long pour déterminer l'origine à interroger pour les enregistrements d'une zone donnée.

Exemples de résolution de requêtes

Google Cloud résout les zones Cloud DNS conformément à l'ordre de résolution des noms. Lors de la définition de la zone à interroger pour un enregistrement donné, Cloud DNS tente de trouver une zone correspondant à autant d'enregistrements demandés que possible (correspondance du suffixe le plus long).

Sauf si vous avez spécifié un serveur de noms alternatif dans une règle de serveur sortant, Google Cloud tente d'abord de trouver un enregistrement dans une zone privée (ou une zone de transfert ou d'appairage) autorisée pour votre réseau VPC avant de rechercher dans une zone publique. Les exemples suivants illustrent la commande utilisée par le serveur de métadonnées lors de l'interrogation d'enregistrements DNS. Pour chacun de ces exemples, supposons que vous ayez créé deux zones privées, gcp.example.com et dev.gcp.example.com, et que vous y ayez autorisé l'accès à partir du même réseau VPC. Google Cloud gère les requêtes DNS des VM d'un réseau VPC de la manière suivante :

  • Le serveur de métadonnées utilise des serveurs de noms publics pour résoudre un enregistrement pour myapp.example.com. (notez le point final), car aucune zone privée pour example.com n'a été autorisée pour le réseau VPC. Utilisez dig à partir d'une VM Compute Engine pour interroger le serveur de noms par défaut de la VM :

    dig myapp.example.com.

    Pour en savoir plus, consultez la section Interroger le nom DNS à l'aide du serveur de métadonnées.

  • Le serveur de métadonnées résout l'enregistrement myapp.gcp.example.com à l'aide de la zone privée autorisée gcp.example.com, car gcp.example.com est le suffixe commun le plus long entre le nom de l'enregistrement demandé et les zones privées autorisées disponibles. NXDOMAIN est renvoyé s'il n'existe aucun enregistrement pour myapp.gcp.example.com défini dans la zone privée gcp.example.com, même s'il existe un enregistrement pour myapp.gcp.example.com défini dans une zone publique.

  • De même, les requêtes destinées à myapp.dev.gcp.example.com sont résolues en fonction des enregistrements définis dans la zone privée autorisée dev.gcp.example.com. NXDOMAIN est renvoyé s'il n'existe aucun enregistrement pour myapp.dev.gcp.example.com dans la zone dev.gcp.example.com, même s'il existe un enregistrement pour myapp.dev.gcp.example.com dans une autre zone privée ou publique.

  • Les requêtes destinées à myapp.prod.gcp.example.com sont résolues en fonction des enregistrements définis dans la zone privée gcp.example.com, car gcp.example.com est le plus long suffixe commun entre l'enregistrement DNS demandé et les zones privées disponibles.

Exemple de DNS fractionné

Vous pouvez utiliser une combinaison de zones publiques et privées dans une configuration de DNS fractionné. Les zones privées vous permettent de définir différentes réponses à une requête pour le même enregistrement lorsque la requête provient d'une VM au sein d'un réseau VPC autorisé. Le DNS fractionné est utile lorsque vous devez fournir des enregistrements différents pour les mêmes requêtes DNS en fonction du réseau VPC d'origine.

Prenons l'exemple du DNS fractionné suivant :

  • Vous avez créé une zone publique, gcp.example.com, et vous avez configuré son bureau d'enregistrement pour utiliser des serveurs de noms Cloud DNS.
  • Vous avez créé une zone privée, gcp.example.com, et vous avez autorisé votre réseau VPC à y accéder.

Dans la zone privée, vous avez créé un seul enregistrement, comme indiqué dans le tableau suivant.

Enregistrer Type TTL (secondes) Données
myrecord1.gcp.example.com A 5 10.128.1.35

Dans la zone publique, vous avez créé deux enregistrements.

Enregistrer Type TTL (secondes) Données
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

Les requêtes suivantes sont résolues comme décrit ci-dessous :

  • Une requête portant sur myrecord1.gcp.example.com provenant d'une VM de votre réseau VPC renvoie 10.128.1.35.
  • Une requête portant sur myrecord1.gcp.example.com provenant d'Internet renvoie 104.198.6.142.
  • Une requête portant sur myrecord2.gcp.example.com provenant d'une VM de votre réseau VPC renvoie une erreur NXDOMAIN, car il n'existe aucun enregistrement pour myrecord2.gcp.example.com dans la zone privée gcp.example.com.
  • Une requête portant sur myrecord2.gcp.example.com provenant d'Internet renvoie 104.198.7.145.

Liaison inter-projets

Les zones de liaison inter-projets vous permettent de maintenir la propriété de l'espace de noms DNS du projet de service indépendante de la propriété de l'espace de noms DNS de l'ensemble du réseau VPC.

Une configuration standard de VPC partagé comporte des projets de service qui assument la propriété d'une application ou de services de machine virtuelle (VM), tandis que le projet hôte assume la propriété du réseau VPC et de l'infrastructure réseau. Souvent, un espace de noms DNS est créé à partir de l'espace de noms du réseau VPC pour correspondre aux ressources du projet de service. Pour ce type de configuration, il peut être plus facile de déléguer l'administration de l'espace de noms DNS de chaque projet de service aux administrateurs de chaque projet de service (qui sont souvent différents départements ou entreprises). La liaison inter-projets vous permet de séparer la propriété de l'espace de noms DNS du projet de service de celle de l'espace de noms DNS de l'ensemble du réseau VPC.

La figure suivante montre une configuration de VPC partagé classique avec appairage DNS.

Une configuration de VPC partagé avec appairage DNS.
Une configuration de VPC partagé avec appairage DNS (cliquez pour agrandir)

La figure suivante montre une configuration utilisant une liaison inter-projets. Cloud DNS permet à chaque projet de service de créer et d'être propriétaire de ses zones DNS, mais reste lié au réseau partagé appartenant au projet hôte. Cela permet une meilleure autonomie et une limite d'autorisation plus précise pour l'administration de la zone DNS.

Configuration avec liaison inter-projets.
Configuration avec liaison inter-projets (cliquez pour agrandir)

La liaison inter-projets offre les avantages suivants :

  • Les administrateurs et les utilisateurs du projet de service peuvent créer et gérer leurs propres zones DNS.
  • Vous n'avez pas besoin de créer un réseau VPC d'espace réservé.
  • Les administrateurs du projet hôte n'ont pas besoin de gérer le projet de service.
  • Les rôles IAM s'appliquent toujours au niveau du projet.
  • Toutes les zones DNS sont directement associées au réseau VPC partagé.
  • La résolution DNS sans contraintes (any-to-any) est disponible. Toute VM du réseau VPC partagé peut résoudre les zones associées.
  • Il n'y a pas de limite de saut transitif. Vous pouvez la gérer dans une conception en étoile.

Pour savoir comment créer une zone avec la liaison inter-projets activée, consultez la page Créer une zone de liaison inter-projets.

Zones Cloud DNS zonales

Cloud DNS zonal vous permet de créer des zones DNS privées et exclusivement limitées à une zone Google Cloud. Les zones Cloud DNS zonales sont créées pour GKE lorsque vous choisissez un champ d'application de cluster.

Le service Cloud DNS par défaut est global et les noms DNS sont visibles de manière globale dans votre réseau VPC. Cette configuration expose votre service aux pannes globales. Le service Cloud DNS zonal est un nouveau service Cloud DNS privé existant dans chaque zone Google Cloud. Le domaine de défaillance est contenu dans cette zone Google Cloud. Les zones privées Cloud DNS zonales ne sont pas affectées en cas de pannes globales. Toutes les pannes zonales Google Cloud n'affectent que cette zone Google Cloud spécifique ainsi que les zones Cloud DNS qu'elle contient. Notez que toute ressource créée dans un service zonal n'est visible que par cette zone Google Cloud.

Pour savoir comment configurer une zone à l'échelle d'un cluster Cloud DNS zonal, consultez Configurer une zone à l'échelle d'un cluster Cloud DNS zonal.

Compatibilité avec Cloud DNS zonal

Le tableau suivant répertorie les ressources et fonctionnalités Cloud DNS compatibles avec les services Cloud DNS zonaux.

Ressource ou fonctionnalité Disponible sur Cloud DNS mondial Disponible sur Cloud DNS zonal
Zones publiques gérées
Zones privées gérées (à l'échelle d'un réseau ou d'un VPC)
Zones privées gérées (à l'échelle de GKE)
Zones de transfert1
Zones d'appairage
Zones de recherche inversée gérées
Créer des modifications ou gérer les enregistrements2
Zones de l'annuaire des services
Règles
Stratégies de réponse (à l'échelle du réseau)
Stratégies de réponse (à l'échelle d'un cluster GKE)
Règles de stratégie de réponse

1 Cloud DNS zonal n'est compatible qu'avec les zones de transfert limitées à un cluster GKE.

2 Le contrôleur GKE écrase les modifications apportées aux enregistrements lors du redémarrage.

Facturation des zones Cloud DNS zonales

La facturation des zones et des stratégies de réponse de Cloud DNS zonal fonctionne de la même manière que pour leurs homologues globaux.

Étapes suivantes