Aperçu

Cette page présente les fonctionnalités et les capacités de Cloud DNS. Pour commencer à utiliser Cloud DNS, consultez la section Démarrage rapide.

Présentation

Cloud DNS est un système global de noms de domaine (DNS) offrant de hautes performances et une grande fiabilité. C'est un moyen économique de publier vos noms de domaine dans le DNS mondial.

Concepts

Un DNS est une base de données organisée de manière hiérarchique qui vous permet de stocker des adresses IP et d'autres données, et de les rechercher par nom. Avec Cloud DNS, vous pouvez publier vos zones et vos enregistrements dans le DNS sans avoir à gérer vos propres serveurs et logiciels DNS.

Concepts généraux de DNS

Pour obtenir la liste terminologique générale de DNS, reportez-vous au document RFC 7719.

Cloud DNS offre des zones gérées DNS publiques et privées. Une zone publique est visible depuis l'Internet public, tandis qu'une zone privée est visible uniquement depuis le ou les réseaux VPC que vous spécifiez.

Les zones privées vous permettent de créer des configurations DNS fractionnées, car vous pouvez créer une zone privée avec un jeu d'enregistrements DNS différent, spécifique à votre réseau VPC.

Concepts de Cloud DNS

L'API Cloud DNS repose sur des projets, des zones gérées et des jeux d'enregistrements, ainsi que sur les modifications apportées à ces jeux.

Projet
Un projet de la console Google Cloud Platform est un conteneur pour les ressources, un domaine permettant de contrôler les accès, et un emplacement dans lequel la facturation est configurée et consolidée. Chaque ressource Cloud DNS réside dans un projet, et chaque opération Cloud DNS doit spécifier un projet de travail.
Zones gérées
La zone gérée contient des enregistrements DNS pour le même suffixe de nom DNS (example.com, par exemple). Un projet peut posséder plusieurs zones gérées, mais chaque zone doit disposer d'un nom unique. Dans Cloud DNS, la zone gérée est la ressource qui modélise une zone DNS. Tous les enregistrements d'une zone gérée sont hébergés sur les mêmes serveurs de noms exploités par Google. Ces serveurs répondent aux requêtes DNS sur votre zone gérée en fonction de sa configuration. Un projet peut contenir plusieurs zones gérées. Des frais sont générés pour chaque jour d'existence de chaque zone gérée. Ces zones sont compatibles avec les libellés, qui peuvent vous servir à organiser votre facturation. La section Gérer les zones vous explique comment gérer les enregistrements au sein des zones.
Zones publiques

Une zone publique est visible sur Internet. Cloud DNS dispose de serveurs de noms primaires publics qui répondent aux requêtes concernant les zones publiques, quelle que soit leur origine. Vous pouvez créer des enregistrements DNS dans une zone publique pour publier votre service sur Internet. Par exemple, vous pouvez créer l'enregistrement suivant dans une zone publique example.com pour votre site Web public www.example.com.

Nom DNS Type TTL (secondes) Données
www.example.com A 300 [adresse_ip_publique]

Cloud DNS affecte un ensemble de serveurs de noms lors de la création d'une zone publique. Pour que les enregistrements DNS d'une zone publique puissent être résolus sur Internet, vous devez mettre à jour le paramètre de serveur de noms de votre enregistrement de domaine auprès de votre bureau d'enregistrement de noms de domaine.

Zones privées

Les zones privées vous permettent de gérer des noms de domaine personnalisés pour vos machines virtuelles (VM), vos équilibreurs de charge et d'autres ressources GCP sans exposer les données DNS sous-jacentes à l'Internet public. Une zone privée est un conteneur d'enregistrements DNS qui ne peut être interrogé que par un ou plusieurs réseaux VPC que vous autorisez.

Une zone privée ne peut être interrogée que par des ressources qui se trouvent dans le projet où elle est définie. Les réseaux VPC que vous autorisez doivent être situés dans le même projet que la zone privée. Vous pouvez outrepasser cette restriction en configurant l'appairage DNS avec un autre réseau.

Vous spécifiez la liste des réseaux VPC autorisés pouvant interroger votre zone privée lorsque vous la créez ou la mettez à jour. Seuls les réseaux autorisés sont autorisés à interroger votre zone privée. Si vous ne spécifiez aucun réseau autorisé, vous ne pouvez pas interroger la zone privée.

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

Les zones privées ne prennent pas en charge les extensions de sécurité DNS (DNSSEC).

Les requêtes destinées aux enregistrements DNS de zones privées doivent être soumises via le serveur de métadonnées, 169.254.169.254, qui est le serveur de noms interne par défaut pour les VM créées à partir d'images fournies par Google. Vous pouvez soumettre des requêtes à ce serveur de noms à partir de toute VM utilisant un réseau VPC autorisé.

Par exemple, vous pouvez créer une zone privée pour dev.gcp.example.com afin d'héberger les enregistrements DNS internes d'applications expérimentales. Le tableau suivant montre des exemples d'enregistrements dans cette zone. Les clients de base de données peuvent se connecter au serveur de base de données, db-01.dev.gcp.example.com, en utilisant son nom DNS interne au lieu de son adresse IP. Les clients de base de données résolvent ce nom DNS interne à l'aide du résolveur d'hôte de la VM, qui soumet la requête DNS au serveur de métadonnées 169.254.169.254. Le serveur de métadonnées agit comme un résolveur récursif pour interroger votre zone privée.

Nom DNS Type TTL (secondes) Données
db-01.dev.gcp.example.com A 5 10.128.1.35
instance-01.dev.gcp.example.com A 50 10.128.1.10
Zones de transfert

Vous pouvez configurer le transfert DNS entre des serveurs de noms non-GCP et les serveurs de noms internes de GCP. Pour plus d'informations, consultez la section Transfert DNS.

Zones d'appairage

Lorsque deux réseaux sont appairés, ils ne partagent pas automatiquement les informations DNS l'un avec l'autre. Vous pouvez configurer l'appairage DNS entre deux réseaux VPC de sorte que, lorsqu'une ressource d'un réseau client envoie une requête DNS, celle-ci est transférée au résolveur DNS du réseau producteur.

Opérations de zone

Toutes les modifications que vous apportez aux zones gérées dans Cloud DNS sont enregistrées dans la collection des opérations, qui répertorie les mises à jour des zones gérées (modification des descriptions, de l'état DNSSEC ou de la configuration).

Bureau d'enregistrement de noms de domaine

Un bureau d'enregistrement de noms de domaine est une organisation qui gère la réservation de noms de domaine Internet. Un tel service doit être accrédité par un registre de domaines de premier niveau (gTLD) générique ou un registre de domaine de premier niveau (ccTLD) national.

DNS interne

GCP crée automatiquement des noms DNS internes pour les VM, même si vous n'utilisez pas Cloud DNS. Pour plus d'informations sur le DNS interne, reportez-vous à la documentation relative au DNS interne.

Sous-zones déléguées

DNS permet au propriétaire d'une zone de déléguer un sous-domaine à un autre serveur de noms à l'aide d'enregistrements NS. Les résolveurs suivent ces enregistrements et envoient des requêtes destinées au sous-domaine au serveur de noms cible spécifié dans la délégation.

Collection de jeux d'enregistrements de ressources

La collection de jeux d'enregistrements de ressources préserve l'état actuel des enregistrements DNS qui composent une zone gérée. Vous pouvez consulter cette collection, mais vous ne pouvez pas la modifier directement. À la place, vous pouvez modifier les jeux d'enregistrements de ressources dans une zone gérée en créant une requête Change dans l'ensemble des modifications. La collection de jeux d'enregistrements de ressources reflète immédiatement toutes vos modifications. Toutefois, il existe un délai entre le moment où les modifications sont apportées dans l'API et le moment où elles sont appliquées sur vos serveurs DNS primaires. La section Gérer les enregistrements vous explique comment gérer les enregistrements.

Modifications des enregistrements de ressources

Lorsque vous souhaitez modifier la collection de jeux d'enregistrements de ressources, vous devez envoyer une requête Change contenant les ajouts ou les suppressions. Ces opérations peuvent être effectuées de façon groupée en une seule transaction atomique et être appliquées en même temps sur chaque serveur DNS primaire.

Le schéma ci-dessous illustre un ajout et une suppression simultanés :

/projects/example-project
../managedZones/examplezone (example.com)
../rrsets
example.com.  SOA  admin@example.com.
example.com.  NS   zns-1.google.com.
example.com.  MX   10 mail.example.com.
www           A    2.3.4.5 3.4.5.6
          
../changes
3  user2@    2014-03-31T18:59:23.587Z  PENDING
   DEL  www  A  1.2.3.4
   ADD  www  A  2.3.4.5 3.4.5.6
2  user1@    2014-03-31T16:34:18.58Z  DONE
1  devops@   2014-03-28T12:46:09.23Z  DONE
          
../managedZones/myorg (example.org)
../rrsets
example.org.  SOA  admin@example.org.
example.org.  NS   zns-1.google.com.
www           A    7.8.9.0
          
../changes
2  user2@    2014-04-02T18:53:55.132Z  PENDING
   DEL  www  A  5.6.7.8
   ADD  www  A  7.8.9.0
1  devops@   2014-03-230T07:22:35.192Z  DONE
          

Vous pouvez disposer de plusieurs zones gérées dans un projet.


Format de numéro de série SOA

Les numéros de série des enregistrements SOA créés dans les zones gérées de Cloud DNS augmentent de manière monotone avec chaque modification transactionnelle apportée aux jeux d'enregistrements d'une zone à l'aide de la commande gcloud dns record-sets transaction. Toutefois, vous êtes libre de remplacer manuellement le numéro de série d'un enregistrement SOA par un nombre arbitraire (y compris par une date au format ISO 8601, comme recommandé dans le document RFC 1912). Par exemple, si l'on considère l'enregistrement SOA suivant :

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

Vous pouvez modifier le numéro de série directement depuis la console Google Cloud Platform en saisissant la valeur souhaitée dans la troisième partie de l'enregistrement. Les différentes parties sont délimitées par des espaces.

Règle de serveur DNS

Une stratégie de serveur DNS vous permet d'accéder aux services de résolution de noms fournis par GCP dans un réseau VPC avec transfert entrant, ou de modifier l'ordre de résolution des noms VPC avec transfert sortant.

Domaines, sous-domaines et délégation

La plupart des sous-domaines ne sont que des enregistrements dans la zone gérée du domaine parent. Les sous-domaines délégués en créant des enregistrements NS (serveur de noms) dans la zone de leur domaine parent doivent également posséder leurs propres zones. Créez des zones gérées pour les domaines parents dans Cloud DNS avant de créer des zones pour leurs sous-domaines délégués. Procédez ainsi même si vous hébergez le domaine parent sur un autre service DNS. Si vous disposez de plusieurs zones de sous-domaine, mais que vous ne créez pas de zone parente, la création de la zone parente peut s'avérer compliquée si vous décidez par la suite de la déplacer vers Cloud DNS.

DNSSEC

Les extensions de sécurité du système de noms de domaine (DNSSEC) sont une suite d'extensions IETF (Internet Engineering Task Force) du DNS qui authentifient les réponses aux recherches de noms de domaine. Elles n'offrent aucune protection de la confidentialité pour ces recherches, mais empêchent les pirates informatiques de manipuler ou de contaminer les réponses aux requêtes DNS.

Collection DNSKEY

La collection DNSKEY préserve l'état actuel des enregistrements DNSKEY servant à signer une zone gérée où DNSSEC est activé. Cette collection n'offre qu'un accès en lecture. Toutes les modifications apportées aux DNSKEY sont effectuées par Cloud DNS. La collection DNSKEY contient toutes les informations dont les services d'enregistrement de noms de domaine ont besoin pour activer DNSSEC.

Commande de résolution des noms de VPC

Chaque réseau VPC fournit des services de résolution de noms DNS aux instances de VM qui les utilisent. Lorsque les VM utilisent leur serveur de métadonnées, 169.254.169.254, comme serveur de noms, GCP recherche les enregistrements DNS dans l'ordre suivant :

  1. Si une règle DNS spécifiant un autre serveur de noms pour le transfert sortant a été configurée pour le réseau VPC, toutes les requêtes DNS reçues par GCP ne sont transférées que vers ce serveur. Consultez Transfert DNS sortant à l'aide d'un autre serveur de noms pour plus de détails.
  2. GCP interroge les services de résolution de noms GCP suivants, dans l'ordre, en utilisant la correspondance du suffixe le plus long :
    • GCP interroge toutes les zones de transfert privées gérées par Cloud DNS qui ont été autorisées pour le réseau VPC, en envoyant des demandes aux adresses IP des cibles de transfert.
    • GCP interroge toutes les zones privées gérées dans Cloud DNS qui ont été autorisées pour le réseau VPC à la recherche d'enregistrements dans ces zones.
    • GCP recherche les enregistrements DNS internes créés automatiquement par Compute Engine pour le projet.
  3. GCP interroge les zones accessibles au public, en respectant le SOA (Start-of-Authority) correctement configuré. Cela inclut les zones publiques de Cloud DNS.

Utiliser des enregistrements PTR dans des zones privées

En raison de la correspondance du suffixe le plus long décrite dans la section relative à l'ordre de résolution de noms du VPC, vous devez créer une zone privée Cloud DNS au moins aussi spécifique que l'une de celles indiquées ci-dessous pour pouvoir effectuer des recherches inversées avec des enregistrements PTR personnalisés :

  • 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 in-addr.arpa., les enregistrements PTR personnalisés d'instances de VM que vous créez dans cette zone sont masqués par les enregistrements PTR que le DNS interne de Compute Engine crée automatiquement. En effet, les enregistrements PTR du DNS interne de Compute Engine sont créés dans la liste précédente qui contient des zones plus spécifiques.

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

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

C'est 10.in-addr.arpa. qui répondra aux requêtes PTR adressées à 1.1.1.10.in-addr.arpa. (10.in-addr.arpa. étant une zone plus spécifique du DNS interne de Compute Engine). L'enregistrement PTR de votre zone privée Cloud DNS correspondant à test.example.domain est ignoré.

Afin de remplacer les enregistrements PTR créés automatiquement par le DNS interne de Compute Engine 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 qui a été généré automatiquement :

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

Vous pouvez également créer des zones privées Cloud DNS inversées plus spécifiques s'il vous suffit de remplacer une partie d'un bloc réseau. Par exemple, une zone privée créée pour 5.10.in-addr.arpa. peut être utilisée pour le stockage des enregistrements PTR qui remplacent tous les enregistrements PTR créés automatiquement par le DNS interne de Compute Engine pour les VM dont les adresses IP sont comprises dans la plage d'adresses 10.5.0.0/16.

Types d'enregistrements DNS acceptés

Cloud DNS accepte les types d'enregistrements suivants :

Type d'enregistrement Description
A

Enregistrement d'adresse permettant de mapper des noms d'hôte à leur adresse IPv4.

AAAA

Enregistrement d'adresse IPv6 permettant de mapper les noms d'hôte à leur adresse IPv6.

CAA

Autorisation de l'autorité de certification (CA) permettant de spécifier les autorités de certification qui peuvent créer des certificats pour un domaine.

CNAME

Enregistrement de nom canonique permettant de spécifier des noms d'alias.
Cloud DNS n'accepte pas la résolution récursive des enregistrements CNAME dans différentes zones privées gérées (recherche de résolution des enregistrements CNAME par requêtes successives). Pour en savoir plus, consultez la section relative au dépannage.

IPSECKEY

Données de passerelle de tunnel IPSEC et clés publiques pour les clients compatibles IPSEC permettant d'activer le chiffrement opportuniste.

MX

Enregistrement Mail Exchange utilisé pour router des requêtes vers des serveurs de messagerie.

NAPTR

Enregistrement de pointeur d'autorité de nommage, défini par le document RFC 3403.

NS

Enregistrement du serveur de noms déléguant une zone DNS à un serveur primaire.

PTR

Enregistrement de pointeur, souvent utilisé pour les recherches DNS inversées.

SOA

Début de l'enregistrement d'autorité spécifiant les informations primaires relatives à une zone DNS. Un enregistrement de ressource SOA est généré pour vous lorsque vous créez votre zone gérée. Vous pouvez modifier l'enregistrement si nécessaire (par exemple, en remplaçant le numéro de série par un nombre arbitraire pour que les versions puissent être gérées en fonction de la date).

SPF

Les enregistrements Sender Policy Framework constituent un type d'enregistrement obsolète précédemment utilisé dans les systèmes de validation d'e-mail (utilisez plutôt un enregistrement TXT).

SRV

Enregistrement de localisateur de service utilisé par certains protocoles de voix sur IP et de messagerie instantanée, ainsi que par d'autres applications.

SSHFP

Empreinte SSH permettant aux clients SSH de valider les clés publiques des serveurs SSH.

TLSA

Enregistrement d'authentification TLS permettant aux clients TLS de valider les certificats de serveur X.509.

TXT

Enregistrement de texte pouvant contenir du texte arbitraire et permettre de définir des données exploitables par un ordinateur, telles que des informations de sécurité ou de prévention des abus. Un enregistrement TXT peut contenir une ou plusieurs chaînes de texte. La longueur maximale de chaque chaîne individuelle est de 255 caractères. Les agents de messagerie et d'autres agents logiciels rassemblent plusieurs chaînes. Placez chacune d'elles entre guillemets. Exemple :


"Hello world" "Bye world"

La page Gestion des enregistrements montre comment utiliser les enregistrements DNS.

Enregistrements DNS wildcard (zones génériques)

Les enregistrements wildcard sont compatibles avec tous les types d'enregistrements, à l'exception des enregistrements NS.

DNSSEC

Cloud DNS est compatible avec le protocole DNSSEC géré, qui protège vos domaines des attaques de spoofing et de contamination du cache. Lorsque vous utilisez un résolveur de validation tel que Google Public DNS, DNSSEC assure l'authentification renforcée (mais pas le chiffrement) des recherches de domaine.

Vous pouvez activer DNSSEC pour une zone gérée à l'aide de la commande suivante :

gcloud dns managed-zones update my-zone --dnssec-state on

Il est aussi possible d'activer DNSSEC sur des zones créées récemment :

gcloud dns managed-zones create my-zone \
    --description "Signed Zone" --dns-name myzone.example --dnssec-state=on

Il existe également un certain nombre de paramètres DNSSEC que vous pouvez spécifier si les paramètres par défaut ne sont pas adaptés à votre déploiement.

Transfert DNS

Vous pouvez configurer le transfert DNS entre vos serveurs de noms non-GCP et les serveurs de noms internes de GCP. La configuration du transfert bidirectionnel permet aux instances de votre réseau VPC de rechercher les adresses des hôtes de vos réseaux locaux ou multicloud et aux hôtes des réseaux liés de rechercher des adresses pour les ressources de votre réseau VPC.

GCP prend en charge le transfert DNS des manières suivantes :

  • Les réseaux VPC prennent en charge le transfert DNS entrant et sortant à l'aide de règles de serveur DNS. Les demandes entrantes doivent provenir de systèmes sur des réseaux connectés au VPC par un tunnel Cloud VPN ou une connexion Cloud Interconnect, tel qu'un centre de données sur site.

  • Les zones privées gérées de Cloud DNS prennent en charge le transfert DNS sortant au moyen de zones de transfert.

L'exemple suivant illustre deux réseaux VPC, prod et dev, pour lesquels le transfert DNS est configuré :

Transfert DNS avec des serveurs DNS sur site (cliquez pour agrandir)
Transfert DNS avec des serveurs DNS sur site (cliquez pour agrandir)
  • Le réseau dev est connecté à un centre de données sur site en Europe avec un tunnel Cloud VPN utilisant un routage dynamique.
  • Le réseau prod est connecté à des centres de données sur site en Asie, en Europe et aux États-Unis avec des tunnels Cloud VPN utilisant un routage dynamique.
  • Tous les réseaux ont été configurés pour utiliser le routage dynamique global.
  • Les trois centres de données sont connectés les uns aux autres. Les adresses IP utilisées par chaque réseau sur site et VPC sont des adresses IP RFC 1918 et ne se chevauchent pas.
  • Les serveurs BIND sur site sont situés dans chaque centre de données sur site, et ces serveurs de noms sont configurés de manière redondante pour desservir la zone corp.example.com.
  • Vous avez créé des règles DNS pour les deux réseaux Cloud VPN dev et prod afin de permettre le transfert sortant vers les serveurs de noms sur site.
  • Les VM dans GCP utilisent leur serveur de métadonnées, 169.254.169.254, pour résoudre les DNS internes de GCP, toutes les zones privées de Cloud DNS autorisées pour les réseaux respectifs dev ou prod, les zones DNS publiques et votre zone sur site corp.example.com.

Règle de serveur DNS

Une règle de serveur DNS vous permet de configurer les transferts DNS entrants et sortants pour un réseau VPC. Vous pouvez appliquer une règle du serveur DNS à un réseau VPC donné.

Consultez la page concernant l'utilisation des règles du serveur DNS pour des instructions détaillées.

Transfert DNS entrant

Chaque réseau VPC fournit des services de résolution de noms DNS aux instances de VM qui les utilisent. Lorsque les VM utilisent leur serveur de métadonnées (169.254.169.254) en tant que serveur de noms, GCP recherche les enregistrements DNS conformément à l'ordre de résolution de noms du VPC.

Par défaut, les services de résolution de noms du réseau VPC ne sont pas disponibles en dehors de ce réseau. Vous pouvez les rendre disponibles pour les systèmes des réseaux sur site connectés à l'aide de Cloud VPN ou Cloud Interconnect en créant une règle DNS permettant le transfert DNS entrant vers le réseau VPC. Lorsque cette règle est activée, les systèmes de réseaux connectés peuvent interroger une adresse IP interne de votre réseau VPC afin d'utiliser ses services de résolution de noms.

Reportez-vous à la section Créer une règle DNS qui active le transfert DNS entrant pour savoir comment configurer une règle DNS activant le transfert entrant vers votre réseau VPC. Une fois configuré, GCP attribue une adresse IP interne dans un sous-réseau (dans une région) de votre réseau VPC pour servir de proxy aux requêtes DNS entrantes. Vous pouvez spécifier une région ou laisser GCP en choisir une automatiquement. Chaque règle DNS pour le transfert DNS entrant attribue une adresse IP de proxy unique aux demandes entrantes. Cependant, cette adresse IP unique sert simplement de point d'entrée dans les services de résolution de noms du réseau VPC. Vous pouvez ensuite configurer vos serveurs de noms sur site pour les transférer à l'adresse de proxy, si nécessaire.

Transfert DNS sortant à l'aide d'un autre serveur de noms

Vous pouvez modifier l'ordre de résolution des noms VPC en créant une règle DNS spécifiant une liste de serveurs de noms alternatifs. Lorsque vous procédez ainsi, les serveurs de noms alternatifs deviennent la seule source interrogée par GCP pour toutes les requêtes DNS soumises par les VM du VPC à l'aide de leur serveur de métadonnées (169.254.169.254).

Consultez la section consacrée à la création d'une règle DNS qui active un autre serveur de noms pour savoir comment configurer une règle DNS pour le transfert sortant. Si vous spécifiez d'autres serveurs de noms utilisant des adresses IP RFC 1918, il doit s'agir d'adresses IP internes d'autres VM GCP de votre réseau VPC, ou de systèmes de votre réseau sur site connectés à votre réseau VPC via Cloud VPN ou Cloud Interconnect. Si vous spécifiez d'autres serveurs de noms utilisant des adresses IP publiques, ils doivent être accessibles sur Internet.

Zones de transfert DNS

La définition d'une zone de transfert permet d'utiliser un autre serveur de noms, ainsi qu'une autre forme de transfert DNS. Cette configuration est semblable à une zone privée dans la mesure où elle est associée à un nom DNS et peut être liée à plusieurs réseaux. Cependant, la zone de transfert ne contient aucun enregistrement. Toutes les requêtes correspondantes pour une zone de transfert sont transférées vers un ensemble de serveurs DNS de destination. Comme dans le cas du serveur de noms alternatif, la destination est une liste d'adresses IP.

Le système tente de résoudre le nom via tous les serveurs de noms de destination. Dans l'exemple ci-dessus, les requêtes correspondantes sont transmises à tous ces serveurs ou à un sous-ensemble de 172.16.1.28, 172.16.4.34 et 172.16.8.50. Veuillez noter que le système peut modifier la stratégie de résolution en fonction de la réactivité du serveur et de l'évolution des conditions du réseau.

Lorsque les conditions de transfert de plusieurs zones de transfert se chevauchent, la zone avec la correspondance la plus longue pour une requête l'emporte sur les autres. Par exemple, supposons qu'un serveur DNS contienne trois zones de transfert :

  • Zone de transfert 1 : onprem.example.com, destination : 172.16.8.40
  • Zone de transfert 2 : dev.onprem.example.com, destination : 172.16.8.50
  • Zone de transfert 3 : prod.onprem.example.com, destination : 172.16.8.60

Une requête pour mysvc.onprem.example.com est transmise à 172.16.8.40 selon la zone 1. Une requête pour mysvc.dev.onprem.example.com est transmise à 172.16.8.50 selon la zone 2. Une requête pour mysvc.prod.onprem.example.com est transmise à 172.16.8.60 selon la zone 3.

Consultez la section Créer des zones de transfert pour obtenir des instructions.

Appairage DNS

L'appairage DNS permet à un réseau VPC de transférer les requêtes DNS spécifiées à un autre réseau VPC.

Lorsque vous appairez deux réseaux VPC à l'aide de l'appairage de réseaux VPC, les instances des réseaux appairés peuvent communiquer entre elles à l'aide des adresses IP internes. Toutefois, les réseaux appairés n'échangent pas automatiquement les informations DNS. L'appairage DNS vous permet de configurer une zone d'appairage DNS sur un réseau (réseau consommateur) qui transfère les requêtes DNS et qui est configuré pour gérer le résolveur DNS d'un autre réseau (réseau producteur).

L'appairage DNS est unidirectionnel : une seule relation d'appairage permet à un réseau de transférer les requêtes DNS vers un autre réseau. L'appairage bidirectionnel nécessite deux relations d'appairage.

Pour établir un appairage DNS, vous avez besoin des éléments suivants :

  • Une ou plusieurs zones privées ou de transfert dans le réseau qui résout les requêtes DNS
  • Une zone d'appairage dans le réseau qui transfère les requêtes à l'autre réseau
  • L'autorisation pour la zone d'appairage, grâce au rôle IAM dns.peer, de transférer les requêtes du réseau en utilisant la zone privée

Cas d'utilisation

Exemple de SaaS

Un fournisseur SaaS (producteur) souhaite donner à son client SaaS (consommateur) l'accès à un service hébergé sur un réseau appairé. Le producteur crée un réseau qui héberge le service, puis l'appaire au réseau consommateur. Le producteur souhaite également fournir les noms DNS que les consommateurs utilisent pour accéder au service.

Le consommateur peut accorder au producteur l'utilisation d'un compte de service que le producteur peut utiliser pour créer une zone d'appairage dans le réseau consommateur. Le producteur attribue également à ce compte de service le rôle dns.peer dans son propre réseau afin que les requêtes de la zone d'appairage puissent atteindre la zone du résolveur. Ou, le producteur peut indiquer au consommateur comment effectuer la configuration.

Configuration intra-organisationnelle

Normalement, une zone privée peut être configurée de sorte que tous les réseaux d'un projet puissent l'atteindre. Cependant, une organisation peut avoir plusieurs projets mais souhaiter que chaque réseau de chaque projet utilise une seule zone privée pour toutes les résolutions internes. Cela est possible en créant une zone privée dans un projet, puis en créant des zones d'appairage pour chaque autre projet pointant vers la zone privée.

Étape suivante pour les zones d'appairage

Consultez la section Configurer les zones d'appairage pour obtenir des instructions.

Zones privées et VPC partagé

Pour utiliser des zones privées avec un VPC partagé, vous devez créer votre zone privée dans le projet hôte et ajouter le réseau VPC partagé approprié à la liste des réseaux autorisés pour cette zone.

Chevauchement de zones

Un projet peut contenir plusieurs zones gérées. 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. Par exemple, dev.gcp.example.com et gcp.example.com sont des 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 se chevauchant, Cloud DNS tente de les placer sur différents serveurs de noms. Si cela n'est pas possible, la création des zones échoue.

Le chevauchement de zones publiques et de zones privées est autorisé.

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 recevront des réponses différentes en fonction des enregistrements de zone définis pour les réseaux VPC respectifs. Pour plus d'informations, consultez la section DNS fractionné.

Résolution des requêtes en cas de chevauchement de zones

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.

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 depuis le même réseau VPC. GCP gère ensuite les requêtes DNS des VM du réseau VPC :

  • Le serveur de métadonnées utilise des serveurs de noms publics pour résoudre myapp.example.com, car il n'y a pas de zone privée pour example.com.
  • Le serveur de métadonnées résout myapp.gcp.example.com à l'aide de la zone privée gcp.example.com, car gcp.example.com est le suffixe commun le plus long entre l'enregistrement DNS demandé et les zones privé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 un serveur de noms public.
  • 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 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 pour myapp.prod.gcp.example.com sont résolues en fonction des enregistrements de 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.

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 VPC autorisé. Le DNS fractionné est utile si vous avez des réseaux VPC de développement, d'entreprise et de production distincts :

  • Vous pouvez définir une zone privée et autoriser l'accès à partir d'un réseau VPC de développement pour que les requêtes des VM de ce réseau concernant les enregistrements DNS de cette zone soient dirigées vers d'autres VM du même réseau.
  • Vous pouvez définir une deuxième zone privée desservant les mêmes enregistrements DNS (noms) avec des réponses différentes, autorisant l'accès à partir d'un réseau d'entreprise.
  • Vous pouvez définir une troisième zone publique desservant les mêmes enregistrements DNS avec des réponses publiques appropriées, adaptées à la production.

Par exemple, supposons que vous ayez créé à la fois une zone publique et une zone privée pour gcp.example.com, que vous ayez configuré le service d'enregistrement de nom de domaine de gcp.example.com pour qu'il utilise des serveurs de noms Cloud DNS, de sorte que votre zone publique soit accessible à partir d'Internet et que vous ayez autorisé l'accès à la zone privée à partir de votre réseau VPC.

Dans la zone privée, créez un seul enregistrement :

Nom DNS Type TTL (secondes) Données
foo.gcp.example.com A 5 10.128.1.35

Dans la zone publique, créez deux enregistrements :

Nom DNS Type TTL (secondes) Données
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

Les exemples suivants illustrent la façon de résoudre les requêtes envoyées aux enregistrements DNS :

  • Une requête destinée à foo.gcp.example.com à partir d'une VM de votre réseau VPC renvoie 10.128.1.35.
  • Une requête destinée à foo.gcp.example.com à partir d'Internet renvoie 104.198.6.142.
  • Une requête destinée à bar.gcp.example.com à partir d'une VM de votre réseau VPC renvoie une erreur NXDOMAIN, car il n'existe aucun enregistrement pour bar.gcp.example.com dans la zone privée gcp.example.com.
  • Une requête destinée à bar.gcp.example.com à partir d'Internet renvoie 104.198.7.145.

Contrôle des accès

Contrôle général des accès

Vous pouvez gérer les utilisateurs autorisés à modifier vos enregistrements DNS sur la page "IAM et administration" de la console Google Cloud Platform. Pour être autorisés à apporter des modifications, les utilisateurs doivent détenir le rôle editor ou owner dans la section "Autorisations" de la console GCP. Le niveau d'autorisation de lecteur accorde un accès en lecture seule aux enregistrements Cloud DNS.

Ces autorisations s'appliquent également aux comptes de service grâce auxquels vous pouvez gérer vos services DNS.

Contrôle des accès pour les zones gérées

Les utilisateurs dotés du rôle Propriétaire de projet ou Éditeur de projet peuvent gérer ou afficher les zones gérées dans le projet spécifique qu'ils gèrent.

Les utilisateurs dotés du rôle Administrateur DNS ou Lecteur DNS peuvent gérer ou afficher les zones gérées dans tous les projets auxquels ils ont accès.

Les propriétaires de projet, les éditeurs, les administrateurs DNS et les lecteurs peuvent afficher la liste des zones privées appliquées à tout réseau VPC du projet en cours.

Performances et planification

Cloud DNS utilise la technique Anycast pour desservir les zones gérées à partir de plusieurs sites à travers le monde afin d'offrir une haute disponibilité. Les requêtes sont automatiquement redirigées vers le site le plus proche, ce qui réduit la latence et améliore les performances de recherche de noms prioritaires pour vos utilisateurs.

Propagation des modifications

Les modifications sont propagées en deux parties. La modification que vous envoyez via l'API ou l'outil de ligne de commande doit tout d'abord être transmise aux serveurs DNS primaires de Cloud DNS. Les outils de résolution DNS doivent ensuite récupérer cette modification lorsque leur cache d'enregistrements vient à expiration.

Le cache de l'outil de résolution DNS est contrôlé par la valeur TTL (Time to Live) que vous avez définie pour vos enregistrements (en secondes). Par exemple, si vous définissez une valeur TTL sur 86 400 (le nombre de secondes correspondant à 24 heures), les outils de résolution DNS mettent en cache les enregistrements pendant 24 heures. Certains outils de résolution DNS ignorent la valeur TTL ou utilisent leurs propres valeurs, ce qui peut retarder la propagation complète des enregistrements.

Si vous envisagez d'apporter une modification urgente à des services, vous pouvez réduire la valeur TTL au préalable. Cette approche peut aider à réduire l'intervalle de mise en cache et à assurer une modification plus rapide de vos nouveaux paramètres d'enregistrement. Après la modification, vous pouvez rétablir l'ancienne valeur TTL afin de réduire la charge sur les outils de résolution DNS.

Étape suivante

Pour commencer à utiliser Cloud DNS, consultez la section Démarrage rapide.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Cloud DNS