Présentation de Cloud DNS

Cette page présente les fonctionnalités et les capacités de Cloud DNS. 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.

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 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 DNS gérées privées. Une zone publique est visible depuis l'Internet public, tandis qu'une zone privée n'est visible que depuis le ou les réseaux VPC (Virtual Private Cloud) 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.

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

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de Cloud DNS en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit de Cloud DNS

Considérations relatives au VPC partagé

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

Méthodes de transfert DNS

Google Cloud propose un transfert DNS entrant et sortant pour les zones privées. Vous pouvez configurer le transfert DNS en créant une zone de transfert ou une règle de serveur Cloud DNS. Les deux méthodes sont résumées dans le tableau suivant :

Transfert DNS Méthodes Cloud DNS
Entrant

Créez une règle de serveur entrant pour permettre à un client ou à un serveur DNS sur site d'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.

Les clients sur site peuvent résoudre des enregistrements dans des zones privées, des zones de transfert et des zones d'appairage pour lesquelles le réseau VPC a été autorisé. Les clients sur site utilisent Cloud VPN ou Cloud Interconnect pour se connecter au réseau VPC.

Sortant

Vous pouvez configurer les VM d'un réseau VPC pour effectuer les opérations suivantes :

  • Envoyer des requêtes DNS aux serveurs de noms DNS de votre choix. Ces serveurs de noms peuvent se trouver sur le même réseau VPC, sur un réseau sur site ou sur Internet.
  • 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 plus d'informations sur la manière dont Google Cloud achemine le trafic vers l'adresse IP d'une cible de transfert, consultez la page Cibles de transfert et méthodes de routage.
  • Créer une règle de serveur sortant pour le réseau VPC afin d'envoyer toutes les requêtes DNS à un autre serveur de noms. 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. Pour en savoir plus, consultez la section Ordre de résolution des noms.

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 plus d'informations sur la résolution de ce problème, consultez la section Requêtes transférées sortantes générant des erreurs SERVFAIL.

Pour plus d'informations sur l'application des règles de serveur, consultez la page Créer des règles de serveur DNS. Pour savoir comment créer une zone de transfert, consultez la section Créer une zone de transfert.

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

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

Voici quelques exemples de zones :

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

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

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

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

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

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

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

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 privées gérées (recherche de résolution des enregistrements CNAME par requêtes successives). Pour plus d'informations, consultez L'enregistrement CNAME défini dans une zone privée ne fonctionne pas.

DNSKEY

Clé DNSSEC d'un autre opérateur pour sécuriser le transfert. Ce type de jeu d'enregistrements peut uniquement être ajouté à une zone où DNSSEC est activé pour le transfert.

DS

Empreinte numérique de la clé DNSSEC pour sécuriser la zone déléguée. Ce type de jeu d'enregistrements n'active pas DNSSEC pour une zone déléguée, sauf si vous l'activez pour celle-ci.

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.

Pour utiliser des enregistrements DNS, consultez la page Gérer les enregistrements.

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 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 est l'adresse IP d'un serveur DNS situé dans votre réseau VPC ou dans un réseau sur site connecté à votre réseau VPC via Cloud VPN ou Cloud Interconnect.

Cibles de transfert et méthodes de routage

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

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

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

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

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

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

Ordre de sélection des cibles de transfert

Cloud DNS vous permet de configurer une liste de serveurs de noms alternatifs pour une règle de serveur sortant, ainsi qu'une liste de cibles de transfert pour une zone de transfert.

Dans le cas de plusieurs cibles de transfert, Cloud DNS utilise un algorithme interne pour sélectionner une cible de transfert. Cet algorithme classe chaque cible de transfert.

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

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

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

Utiliser des zones de transfert

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

  • Le réseau VPC a été autorisé à utiliser la zone de transfert Cloud DNS. 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 169.254.169.254 de la VM comme serveur de noms.

Chevauchement de zones de transfert

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

Mettre en cache et transférer des zones

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

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

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

Quand utiliser l'appairage

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

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

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

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

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

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

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

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

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

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

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 réseau consommateur DNS.

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

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

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

Limites d'appairage DNS et points essentiels

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

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

Pour 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. Exemple :

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

Règles pour les zones qui se chevauchent

Cloud DNS applique les règles suivantes pour les zones qui se chevauchent :

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

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

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

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

Exemples de résolution de requêtes

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

Sauf si vous avez spécifié un autre serveur de noms 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 l'enregistrement dans une zone publique.

Les exemples suivants illustrent la commande utilisée par le serveur de métadonnées lors de l'interrogation d'enregistrements DNS. Pour chacun de ces exemples, supposons que vous ayez créé deux zones privées, gcp.example.com et dev.gcp.example.com, et que vous y ayez autorisé l'accès à partir du même réseau VPC. Google Cloud gère les requêtes DNS des VM d'un réseau VPC de la manière suivante :

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

    dig myapp.example.com.
    

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

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

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

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

Exemple de DNS fractionné

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

Prenons l'exemple du DNS fractionné suivant :

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

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

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

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

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

Contrôle 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 à apporter des modifications, les utilisateurs doivent disposer du rôle d'éditeur (roles/editor) ou de propriétaire (roles/owner) dans la section "Autorisations" de Cloud Console. Le rôle de lecteur (roles/viewer) 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 (roles/dns.admin ou roles/dns.reader) 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.

La valeur TTL (Time To Live) que vous avez définie pour vos enregistrements (en secondes) contrôle le cache du résolveur DNS. 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 résolveurs 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 à des services nécessitant une fenêtre étroite, vous pouvez remplacer la valeur TTL par une valeur plus courte avant d'effectuer la modification. 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 résolveurs DNS.

Étape suivante