Présentation de Cloud DNS

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.

Cloud DNS propose à la fois des zones publiques et des zones gérées DNS 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.

Pour obtenir la liste des termes généraux du DNS, consultez la présentation générale du DNS.

Pour obtenir la liste des termes clés sur lesquels Cloud DNS repose, consultez la section Termes clés.

Considérations relatives au VPC partagé

Pour utiliser une zone privée gérée Cloud DNS, une zone de transfert Cloud DNS ou une zone d'appairage Cloud DNS avec un VPC partagé, vous devez créer la zone dans le projet hôte, puis ajouter le ou les réseaux VPC partagés appropriés à 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.

Commande de résolution des noms de VPC

Chaque réseau VPC fournit des services de résolution de noms DNS aux instances de machine virtuelle (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 :

  • Si votre réseau VPC dispose d'une règle de serveur sortant, Google Cloud transfère toutes les requêtes DNS vers ces serveurs alternatifs. L'ordre de résolution du nom du VPC ne comprend que cette étape.

  • Si votre réseau VPC ne possède pas de règle de serveur sortant :

    1. Google Cloud tente de trouver une zone privée correspondant à autant d'enregistrements demandés que possible (correspondance du suffixe le plus long). Par exemple :
      • Rechercher des enregistrements créés dans des zones privées
      • Interroger les cibles de transfert pour les zones de transfert
      • Interroger l'ordre de résolution de noms d'un autre réseau VPC à l'aide de zones d'appairage
    2. 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.

Méthodes de transfert DNS

Google Cloud propose un transfert DNS entrant et sortant pour les zones privées.

  • Le transfert entrant consiste à autoriser un client ou un serveur DNS sur site à envoyer des requêtes DNS à Cloud DNS. Le client ou le serveur DNS peut ensuite résoudre les enregistrements en fonction de l'ordre de résolution des noms d'un réseau VPC. Le transfert entrant permet aux clients sur site de résoudre les enregistrements dans des zones privées, de transfert ou d'appairage pour lesquelles le réseau VPC a été autorisé. Les clients sur site se connectent au réseau VPC à l'aide de Cloud VPN ou de Cloud Interconnect.

  • Le transfert sortant consiste à permettre aux VM de Google Cloud d'envoyer des requêtes DNS aux serveurs de noms DNS de votre choix. Les serveurs de noms peuvent se trouver dans le même réseau VPC, sur un réseau sur site ou sur Internet.

Pour configurer le transfert DNS, vous devez créer une zone de transfert ou une règle du serveur Cloud DNS. Les deux méthodes sont résumées dans le tableau suivant :

Transfert Méthodes Cloud DNS
Entrée Les systèmes sur site peuvent envoyer des requêtes à un réseau VPC afin d'utiliser l'ordre de résolution des noms VPC si vous créez une règle du serveur entrant pour ce réseau VPC.
Sortant Vous pouvez configurer des VM dans un réseau VPC pour :
  • Résoudre les enregistrements hébergés sur des serveurs de noms configurés en tant que cibles de transfert d'une zone de transfert mise à la disposition du réseau VPC. Pour obtenir des informations importantes sur la manière dont Google Cloud achemine le trafic vers l'adresse IP d'une cible de transfert, consultez la section Cibles de transfert et méthodes de routage.
  • Envoyer toutes les requêtes DNS à un autre serveur de noms en créant une stratégie de serveur sortant pour le réseau VPC. Lorsque vous utilisez un autre serveur de noms, les VM de votre réseau VPC ne peuvent plus résoudre les enregistrements dans les zones privées, de transfert ou d'appairage de Cloud DNS. Lisez attentivement l'ordre de résolution des noms de VPC pour plus de détails.

Vous pouvez configurer simultanément les transferts entrants et sortants pour un réseau VPC. Le transfert bidirectionnel permet aux VM de votre réseau VPC de résoudre les enregistrements dans un réseau sur site ou dans un réseau hébergé par un autre fournisseur cloud. Ce type de transfert permet également aux hôtes du réseau sur site de résoudre les enregistrements des ressources Google Cloud.

Le plan de contrôle Cloud DNS utilise un algorithme pour déterminer la réactivité d'une cible de transfert. Vos requêtes transférées sortantes peuvent parfois entraîner des erreurs SERVFAIL. Pour savoir comment contourner ce problème, consultez la section à ce sujet dans la documentation de dépannage.

Enregistrements PTR dans des zones privées

Enregistrements PTR des adresses RFC 1918

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

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

AAAA

Enregistrement d'adresse IPv6 permettant de mapper les noms d'hôte sur 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 plus de détails, 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

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. Pour en savoir plus sur le protocole DNSSEC, consultez la page Gérer la configuration DNSSEC.

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 correspond aux adresses IP d'un serveur DNS situé dans votre réseau VPC ou sur un réseau sur site connecté à votre réseau VPC à l'aide de Cloud VPN ou Cloud Interconnect.

Cibles de transfert et méthodes de routage

Cloud DNS est compatible avec trois types de cibles et propose des méthodes standards ou privées pour leur acheminer le trafic.

Cible de transfert Description Routage standard Routage privé Les requêtes proviennent de :
Type 1 Une adresse IP interne d'une VM Google Cloud dans le même réseau VPC autorisé à utiliser la zone de transfert Il doit s'agir d'une adresse IP RFC 1918 (le trafic est toujours acheminé via un réseau VPC autorisé). Toute adresse IP interne (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 Il doit s'agir d'une adresse IP RFC 1918 (le trafic est toujours acheminé via un réseau VPC autorisé). Toute adresse IP interne (le trafic est toujours acheminé via un réseau VPC autorisé) 35.199.192.0/19
Type 3 Adresse IP externe d'un serveur de noms DNS sur Internet.
Inclut une adresse IP externe d'une ressource Google Cloud.
Il doit s'agir d'une adresse Internet routable (le trafic doit toujours être acheminé vers Internet). Le routage privé n'est pas accepté. Plages d'adresses 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.

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. Vous pouvez autoriser plusieurs réseaux VPC du même projet à utiliser la zone de transfert.
  • L'OS invité de chaque VM du réseau VPC utilise le serveur de métadonnées de la VM 169.254.169.254 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 VPC, 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 de la valeur TTL de chaque enregistrement.

Quand utiliser l'appairage

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

  • Vous avez connecté un réseau sur site à un réseau VPC nommé vpc-net-a à l'aide de Cloud VPN ou de Cloud Interconnect.

  • Vous avez connecté le réseau VPC vpc-net-a à vpc-net-b à l'aide de l'appairage de réseaux VPC. 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 de la VM 169.254.169.254 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. Afin d'utiliser une zone de transfert, une VM doit être configurée pour utiliser son serveur de métadonnées.
  • Interrogez la cible de transfert directement pour le même enregistrement. Cette requête montre que la connectivité transitive réussit, bien que Cloud DNS n'utilise pas ce chemin.

Vous pouvez corriger 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.

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. Par exemple, un fournisseur SaaS peut autoriser un client SaaS à accéder aux enregistrements DNS qu'il gère.

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. 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 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 consommateurs DNS doivent être des réseaux VPC.
  • 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.
  • 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 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 d'interconnexion (VLAN) ou un tunnel Cloud VPN situé dans la même région que la VM source utilisant la zone d'appairage DNS. Pour en savoir plus sur cette limitation, consultez la section Dépannage.

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.

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. Par 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. Consultez la section suivante pour connaître les règles qui s'appliquent aux zones qui se chevauchent.

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 VPC. 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, car aucune zone privée pour example.com n'a été autorisée pour le réseau VPC.
  • 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 :

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

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

Enregistrement 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 requêtes suivantes sont résolues comme décrit ci-dessous :

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

Règles du serveur DNS

Vous pouvez configurer une règle de serveur DNS pour chaque réseau VPC. La règle peut spécifier le transfert entrant, le transfert sortant ou les deux. Dans cette section, la règle du serveur entrant fait référence à une règle autorisant le transfert DNS entrant, et la règle du serveur sortant fait référence à une méthode possible pour mettre en œuvre le transfert DNS sortant. Une règle peut être à la fois une règle de serveur entrant et une règle de serveur sortant si elle met en œuvre les deux fonctionnalités.

Pour en savoir plus, consultez la section Appliquer des règles de serveur.

Règle du serveur entrant

Chaque réseau VPC fournit des services de résolution de noms DNS aux VM qui les utilisent. Lorsqu'une VM utilise son serveur de métadonnées, 169.254.169.254, comme serveur de noms, Google Cloud recherche des enregistrements DNS en fonction de l'ordre de résolution des noms de VPC.

Par défaut, les services de résolution de noms d'un réseau VPC (à l'aide de l'ordre de résolution de noms) ne sont disponibles que pour ce réseau VPC. Vous pouvez mettre ces services de résolution de noms à disposition d'un réseau sur site connecté à l'aide de Cloud VPN ou Cloud Interconnect en créant une règle de réseau DNS entrant dans votre réseau VPC.

Lorsque vous créez une règle entrante, Cloud DNS extrait une adresse IP interne de la plage d'adresses IP principale d'un sous-réseau dans chaque région utilisée par votre réseau VPC. Il utilise ces adresses IP internes comme points d'entrée pour les requêtes DNS entrantes.

Points d'entrée d'une règle entrante

Les adresses IP internes régionales utilisées par Cloud DNS pour la règle DNS entrante servent de points d'entrée dans les services de résolution de noms du réseau VPC. Pour utiliser la règle DNS entrante, vous devez configurer vos systèmes sur site ou vos serveurs de noms afin de transférer les requêtes DNS vers l'adresse IP du proxy située dans la même région que le tunnel Cloud VPN ou le rattachement Cloud Interconnect (VLAN) qui connecte votre réseau sur site à votre réseau VPC.

Pour en savoir plus sur la création de règles de serveur entrant, consultez la page Créer une règle de serveur entrant.

Règle du serveur sortant

Vous pouvez modifier l'ordre de résolution des noms VPC en créant une règle DNS sortante qui spécifie une liste de serveurs de noms alternatifs. Lorsque vous spécifiez des serveurs de noms alternatifs pour un réseau VPC, ces serveurs sont les seuls que Google Cloud interroge lors du traitement de requêtes DNS des VM de votre réseau VPC qui sont configurées pour utiliser leurs serveurs de métadonnées (169.254.169.254).

Pour en savoir plus sur la création de règles de serveur sortant, consultez la page Créer une règle de serveur sortant.

Serveurs de noms alternatifs et méthodes de routage

Cloud DNS est compatible avec quatre types de serveurs de noms alternatifs et propose des méthodes de routage standard et privé pour acheminer le trafic vers ces serveurs.

Les serveurs de noms alternatifs sont définis dans le tableau suivant :

Serveurs de noms alternatifs Description Routage standard Routage privé Les requêtes proviennent de :
Type 1 Une adresse IP interne d'une VM Google Cloud dans le même réseau VPC où la règle du serveur sortant est définie Il doit s'agir d'une adresse IP RFC 1918 (le trafic est toujours acheminé via un réseau VPC autorisé). Toute adresse IP interne (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 avec la règle de serveur sortant, à l'aide de Cloud VPN ou Cloud Interconnect Il doit s'agir d'une adresse IP RFC 1918 (le trafic est toujours acheminé via un réseau VPC autorisé). Toute adresse IP interne (le trafic est toujours acheminé via un réseau VPC autorisé) 35.199.192.0/19
Type 3 Adresse IP externe d'un serveur de noms DNS sur Internet.
Inclut une adresse IP externe d'une ressource Google Cloud.
Il doit s'agir d'une adresse Internet routable (le trafic doit toujours être acheminé vers Internet). Le routage privé n'est pas accepté. Plages d'adresses sources du DNS public de Google
Type 4 Adresse IP externe d'une VM Compute Engine sur un autre réseau VPC.
Il doit s'agir d'une adresse IP non-RFC 1918. Le routage privé n'est pas compatible. Assurez-vous que le routage privé est désactivé. Plages d'adresses sources du DNS public de Google

Vous pouvez opter pour l'une des deux méthodes de routage suivantes lorsque vous spécifiez le serveur de noms alternatif d'une règle de transfert sortante.

  • Routage standard : achemine le trafic via un réseau VPC autorisé ou sur Internet, selon que le serveur de noms alternatif utilise ou non une adresse IP RFC 1918. Si le serveur de noms secondaire est une adresse IP RFC 1918, Cloud DNS classe le serveur de noms en tant que serveur de noms de type 1 ou de type 2 et achemine les requêtes via un réseau VPC autorisé. Si le serveur de noms secondaire n'est pas une adresse IP RFC 1918, Cloud DNS classe le serveur de noms en tant que Type 3 et requiert que le serveur de noms soit accessible à Internet.

  • Routage privé : achemine toujours le trafic via un réseau VPC autorisé, quelle que soit l'adresse IP du serveur de noms alternatif (RFC 1918 ou non). Par conséquent, seuls les serveurs de noms de type 1 et de type 2 sont acceptés.

Pour accéder à un serveur de noms secondaire 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 le serveur de noms :

Pour plus d'informations sur la configuration réseau requise pour les serveurs de noms de type 1 et de type 2, consultez la section Exigences réseau requises pour le serveur de noms.

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