Présentation

Cette page présente les fonctionnalités et les capacités de Cloud DNS. Pour démarrer avec Cloud DNS, consultez le guide de 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.

Pour obtenir la liste des termes généraux liés au DNS, reportez-vous à la section Présentation générale du DNS.

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 Google Cloud Console 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 les enregistrements DNS partageant 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 étiquettes, 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 les noms de domaine personnalisés de vos machines virtuelles, équilibreurs de charge et autres ressources Google Cloud 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 peuvent 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 des réseaux VPC partagés. Reportez-vous à la section Zones privées et VPC partagés de cette page pour obtenir des informations importantes sur l'utilisation des zones privées avec des réseaux VPC partagés.

Les zones privées ne sont pas compatibles avec les extensions de sécurité DNS (DNSSEC) ni avec les jeux d'enregistrements de ressources personnalisés de type NS.

Les requêtes concernant les 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 le domaine dev.gcp.example.com afin d'héberger des enregistrements DNS internes pour des 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

Une zone de transfert est un type de zone gérée privée de Cloud DNS, qui envoie des requêtes de cette zone aux adresses IP de ses cibles de transfert. Consultez la page Transfert DNS pour plus d'informations.

Zones d'appairage

Une zone d'appairage est un type de zone gérée privée de Cloud DNS, qui suit l'ordre de résolution des noms d'un autre réseau VPC. Elle permet de résoudre les noms définis dans l'autre réseau VPC.

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 service 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 national (ccTLD).

DNS interne

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

Sous-zones déléguées

Un 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. Vous devez plutôt modifier les jeux d'enregistrements de ressources dans une zone gérée en créant une requête Change dans la collection de 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 explique comment gérer les enregistrements.

Modifications des enregistrements de ressources

Pour apporter une modification à la collection de jeux d'enregistrements de ressources, envoyez 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.

Supposons, par exemple, que vous disposiez d'un enregistrement A semblable au suivant :

    www  A  203.0.113.1 203.0.113.2
    

Vous exécutez des commandes telles que les suivantes :

    DEL  www  A  203.0.113.2
    ADD  www  A  203.0.113.3
    

Votre enregistrement se présente comme suit après les modifications groupées :

    www  A  203.0.113.1 203.0.113.3
    

Les commandes ADD et DEL sont exécutées simultanément.

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 à partir de Google Cloud Console en saisissant la valeur souhaitée dans le troisième champ de l'enregistrement délimité par des espaces.

Règle de serveur DNS

Une règle de serveur DNS vous permet d'accéder aux services de résolution de noms fournis par Google Cloud sur 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 avantde définir 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 ne définissez 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 enregistrements 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, Google Cloud recherche les enregistrements DNS selon 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 Google Cloud ne sont transférées que vers ce serveur. Pour plus d'informations, reportez-vous à la page Transfert DNS sortant à l'aide d'un autre serveur de noms.
  2. Google Cloud interroge les services de résolution de noms Google Cloud suivants, dans l'ordre, en utilisant la correspondance du suffixe le plus long :
    • Google Cloud interroge toutes les zones gérées privées de transfert de Cloud DNS qui ont été autorisées pour le réseau VPC en envoyant des requêtes aux adresses IP des cibles de transfert.
    • Google Cloud interroge toutes les zones gérées privées de Cloud DNS qui ont été autorisées pour le réseau VPC à la recherche d'enregistrements dans ces zones. Cela inclut les zones d'appairage.
    • Google Cloud recherche les enregistrements DNS internes créés automatiquement par Compute Engine pour le projet.
  3. Google Cloud interroge les zones accessibles au public, en respectant le SOA (Début de l'enregistrement d'autorité) correctement configuré. Cela inclut les zones publiques de Cloud DNS.

Enregistrements PTR dans des zones privées

Enregistrements PTR des adresses RFC 1918

En raison de la correspondance du préfixe le plus long, décrit dans l'ordre de résolution des noms VPC, vous devez créer une zone privée Cloud DNS au moins aussi spécifique que l'une des zones ci-dessous pour pouvoir effectuer des résolutions inverses à l'aide des enregistrements PTR personnalisés des adresses RFC 1918 :

  • 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 instances de VM dans cette zone sont remplacés par ceux qui ont été automatiquement créés par le DNS interne de Compute Engine. 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 gérée privé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

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 de Compute Engine. L'enregistrement PTR de votre zone privée Cloud DNS pour 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 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 si vous devez juste remplacer une partie d'un bloc réseau. 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 de Compute Engine créés automatiquement pour les VM dont les adresses IP se situent dans la plage d'adresses 10.5.0.0/16.

Enregistrements PTR des adresses autres que RFC 1918

Les enregistrements PTR des adresses autres que RFC 1918 n'entrent pas en conflit avec les enregistrements PTR créés automatiquement par le DNS interne de Compute Engine.

En raison de l'ordre de résolution des noms VPC, les zones privées sont interrogées avant les zones accessibles au public sur Internet.

Par exemple, supposons que, sur l'Internet public, la requête PTR IN 2.2.0.192.in-addr.arpa renvoie example.com, mais que vous souhaitiez remplacer ce nom pour les instances de VM dans un ou plusieurs de vos réseaux VPC. Pour ce faire, vous créez une zone privée dont le nom DNS est in-addr.arpa, puis vous y ajoutez l'enregistrement PTR suivant :

2.2.0.192.in-addr.arpa -> test.com

Lorsque les VM résidant dans des réseaux VPC sont autorisées à interroger cette requête de zone privée sur PTR IN 2.2.0.192.in-addr.arpa, elles reçoivent la réponse test.com au lieu de example.com.

Enregistrements PTR dans les zones publiques

Pour interroger une zone publique Cloud DNS sur les adresses autres que RFC 1918, vous devez déléguer la partie de l'espace in-addr.arpa déléguée à la racine de votre bloc d'adresses IP aux serveurs de noms Cloud DNS.

Vous pouvez trouver des informations générales sur la configuration du DNS inverse ici. Cependant, veuillez noter que les étapes exactes qui permettent de configurer le DNS inverse varient selon l'opérateur de registre.

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 les noms d'hôte sur leur adresse IPv4.

AAAA

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 gérées privées (recherche de résolution des enregistrements CNAME par requêtes successives). Pour en savoir plus, consultez la section 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

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 permettant 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 Google Cloud. 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.

Le transfert DNS sur Google Cloud peut être configuré de différentes manières :

  • 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 gérées privées de Cloud DNS acceptent le transfert DNS sortant au moyen de zones de transfert.

L'exemple suivant montre 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 locaux 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 Google Cloud utilisent leur serveur de métadonnées, 169.254.169.254, pour résoudre les DNS internes de Google Cloud, 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.

Limites du transfert DNS

Les cibles de transfert d'une zone de transfert ne peuvent pas être atteintes de manière transitoire via l'appairage de réseaux VPC.

Exemple de configuration : votre environnement sur site est connecté à deux réseaux VPC, vpc-net-a et vpc-net-b, via des tunnels Cloud VPN ou à l'aide de Cloud Interconnect. Les deux réseaux VPC sont connectés à l'aide de l'appairage de réseaux VPC et sont configurés pour échanger des routes personnalisées. Si vous créez une zone de transfert dans vpc-net-b avec des cibles dans le réseau sur site, le transfert DNS ne fonctionnera pas. Vous pouvez le vérifier en effectuant le test suivant :

  • Interrogez le serveur de métadonnées, 169.254.169.254, pour rechercher un enregistrement défini dans la zone de transfert. La requête échoue.
  • Interrogez la cible de transfert directement pour le même enregistrement. Cette fois, la requête aboutit.

La solution consiste à créer une zone d'appairage Cloud DNS dans vpc-net-b qui cible vpc-net-a, et une zone de transfert dans vpc-net-a qui cible les serveurs de noms sur site. Vous pouvez connecter les deux réseaux vpc-net-a et vpc-net-b à l'environnement sur site via des rattachements ou des tunnels, mais l'un des deux doit transférer les requêtes vers l'environnement sur site et l'autre doit utiliser l'appairage DNS au réseau VPC désigné pour le transfert vers l'environnement sur site.

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

Pour obtenir des instructions détaillées, consultez la page Utiliser les règles du serveur DNS.

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, comme serveur de noms, Google Cloud recherche les enregistrements DNS conformément à l'ordre de résolution des noms 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 page Créer une règle DNS qui active le transfert DNS entrant pour savoir comment configurer une règle DNS qui autorise le transfert entrant vers votre réseau VPC. Une fois la règle configurée, Google Cloud attribue une adresse IP interne dans un sous-réseau (dans une région) de votre réseau VPC pour servir de proxy pour les requêtes DNS entrantes. Vous pouvez spécifier une région ou laisser Google Cloud 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.

Ordre de résolution de noms de réseau VPC à 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 secondaires deviennent la seule source interrogée par Google Cloud pour toutes les requêtes DNS soumises par les VM du réseau VPC à l'aide de leur serveur de métadonnées, 169.254.169.254.

Consultez la page Créer 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 à l'aide d'adresses IP internes RFC 1918, celles-ci doivent être les adresses IP internes d'autres VM Google Cloud sur votre réseau VPC ou de systèmes sur 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.

Transfert DNS sortant vers une adresse IP non-RFC 1918

Par défaut, le transfert DNS envoie des requêtes aux cibles de transfert via un chemin d'accès privé ou public. Le chemin privé passe par le réseau Google Cloud et le chemin public par Internet. Vous ne pouvez pas configurer le chemin d'accès réel qui sera emprunté. Cloud DNS sélectionne automatiquement le chemin d'accès en fonction de la plage d'adresses IP cibles de transfert. Si la cible est une adresse RFC 1918, la requête est envoyée via le réseau privé. Si la cible est une adresse non-RFC 1918, la requête est envoyée sur Internet.

Cloud DNS vous permet de forcer un chemin de requête privé pour n'importe quelle adresse IP. Pour ce faire, vous pouvez créer ou mettre à jour une zone de transfert avec une ou plusieurs cibles de transfert privé.

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, soit 172.16.1.28, 172.16.4.34 et 172.16.8.50, ou à un sous-ensemble de ceux-ci. Notez 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 destinée à mysvc.onprem.example.com est transmise à 172.16.8.40 selon la zone 1. Une requête destinée à mysvc.dev.onprem.example.com est transmise à 172.16.8.50 selon la zone 2. Une requête destinée à mysvc.prod.onprem.example.com est transmise à 172.16.8.60 selon la zone 3.

Pour plus d'informations, consultez la page Créer des zones de transfert.

Pour plus d'informations, consultez la section Bonnes pratiques pour les zones de transfert DNS Cloud.

Appairage DNS

L'appairage DNS vous permet d'envoyer les requêtes des enregistrements provenant de l'espace de noms d'une zone à un autre réseau VPC.

Pour effectuer l'appairage DNS, vous devez créer une zone d'appairage 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.

Pour effectuer l'appairage DNS, vous devez autoriser un réseau à utiliser une zone d'appairage. Le réseau VPC autorisé à utiliser la zone d'appairage s'appelle le réseau consommateur DNS.

Une fois autorisées, les ressources Google Cloud du réseau consommateur DNS 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 de producteurs DNS. La résolution des enregistrements de l'espace de noms de la zone d'appairage suit l'ordre de résolution des noms du réseau de producteurs DNS. Ainsi, les ressources Google Cloud du réseau consommateur DNS peuvent effectuer les résolutions des enregistrements de l'espace de noms de la zone à partir des sources suivantes disponibles dans le réseau de producteurs DNS :

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

Limites de l'appairage DNS

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 les réseaux consommateurs DNS doivent être des réseaux VPC Google Cloud.
  • L'appairage DNS et l'appairage de réseaux VPC sont des services différents. 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.
  • Le transfert DNS ne fonctionne pas avec l'appairage de réseaux VPC.
  • L'appairage DNS transitif est possible, mais uniquement via un seul saut transitif. En d'autres termes, vous pouvez établir un appairage du VPC1 vers le VPC2 et le VPC3, mais pas au-delà.

Pour créer une zone d'appairage, vous devez disposer du rôle IAM Pair DNS dans le projet qui contient le réseau de producteurs DNS.

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, lui permettant de 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

Vous pouvez autoriser plusieurs réseaux VPC à utiliser une zone gérée privée de Cloud DNS dans le même projet. Toutefois, vous devrez peut-être partager une zone DNS avec plusieurs projets de votre organisation.

Vous pouvez utiliser l'appairage DNS pour répondre à ce besoin : créer une seule zone gérée privée autorisée pour un réseau de producteurs. Créez ensuite un nombre suffisant de zones d'appairage pour le même espace de noms autorisé pour chacun des réseaux consommateurs des différents projets. Configurez chaque zone d'appairage pour qu'elle utilise le même réseau de producteurs afin que les ressources Google Cloud sur les réseaux consommateurs puissent suivre l'ordre de résolution des noms du réseau de producteurs. Cela leur donne la possibilité de résoudre les enregistrements dans l'espace de noms d'une zone gérée privée autorisée pour le réseau de producteurs.

Étape suivante pour les zones d'appairage

Accédez à la page 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.

Pour plus d'informations, consultez les Bonnes pratiques pour les zones privées Cloud DNS.

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 qui se chevauchent, Cloud DNS tente de les placer sur des serveurs de noms différents. 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 reçoivent 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 page 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. Google Cloud 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'existe 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 défini dans la zone dev.gcp.example.com, même s'il existe un enregistrement pour myapp.dev.gcp.example.com défini 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.

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 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éé une zone publique et une zone privée pour gcp.example.com, que vous ayez configuré le service d'enregistrement de gcp.example.com pour utiliser les serveurs de noms Cloud DNS afin de rendre votre zone publique accessible sur Internet, et que vous ayez autorisé l'accès à la zone privée depuis 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 portant sur foo.gcp.example.com provenant d'une VM de votre réseau VPC renvoie 10.128.1.35.
  • Une requête portant sur foo.gcp.example.com provenant d'Internet renvoie 104.198.6.142.
  • Une requête portant sur bar.gcp.example.com provenant 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 portant sur bar.gcp.example.com provenant 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 à apporter des modifications à vos enregistrements DNS sur la page "IAM et administration" de Google Cloud Console. Pour être autorisés à effectuer des modifications, les utilisateurs doivent être répertoriés dans la section "Autorisations" de Cloud Console avec le niveau d'autorisation editor ou owner. 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 du 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.

Étapes suivantes