Cette page a été traduite par l'API Cloud Translation.

Bonnes pratiques Cloud DNS

Ce document présente les bonnes pratiques concernant les zones privées, le transfert DNS et les architectures de référence pour les DNS hybrides.

Il est plus facile pour les utilisateurs et les applications d'utiliser le système DNS (Domain Name System) pour traiter les applications et les services, car l'utilisation d'un nom est plus facile à retenir et plus flexible que l'utilisation d'adresses IP. Dans un environnement hybride constitué d'éléments sur site et d'une ou plusieurs plates-formes cloud, les enregistrements DNS des ressources internes doivent souvent être accessibles quel que soit l'environnement. Traditionnellement, les enregistrements DNS sur site sont gérés manuellement à l'aide d'un serveur DNS faisant autorité, tel que BIND dans les environnements UNIX/Linux ou Active Directory dans les environnements Microsoft Windows.

Cet article décrit les bonnes pratiques à adopter pour transférer des requêtes DNS privées entre les environnements afin de garantir un adressage correct des services, aussi bien depuis les environnements sur site que dans Google Cloud.

Principes généraux

Apprenez-en plus sur les concepts DNS dans Google Cloud

Lorsque vous utilisez DNS sur Google Cloud, il est important de comprendre les différents systèmes et services disponibles dans Google Cloud pour la résolution DNS et les noms de domaine :

Le DNS interne est un service qui crée automatiquement des noms DNS pour les machines virtuelles et les équilibreurs de charge internes sur Compute Engine.
Cloud DNS propose un service de zones DNS à faible latence et haute disponibilité. Il peut faire office de serveur DNS primaire pour les zones publiques visibles sur Internet, de même que pour les zones privées qui ne sont visibles que sur votre réseau.
Le service géré pour Microsoft Active Directory est un service renforcé à disponibilité élevée qui exécute Microsoft Active Directory, y compris un contrôleur de domaine.
Public DNS est un service Google qui ne fait pas partie de Google Cloud et qui agit comme un résolveur DNS ouvert et récursif.
Cloud Domains est un service d'enregistrement de noms de domaine permettant l'achat, le transfert ou la gestion de domaines dans Google Cloud. Cloud Domains vous permet d'interagir avec le système d'enregistrement de domaine via une API.

Identifier les intervenants, les outils et les processus

Lorsque vous envisagez de développer une stratégie DNS dans un environnement hybride, il est important de bien connaître votre architecture actuelle et de vous rapprocher de toutes les personnes concernées. Procédez comme suit :

Identifiez et contactez l'administrateur des serveurs DNS d'entreprise de votre organisation. Demandez-lui des informations sur les configurations requises afin de mapper la configuration sur site à une architecture adaptée sur Google Cloud. Pour plus d'informations sur les méthodes d'accès aux enregistrements DNS de Google Cloud, consultez la page Utiliser le transfert conditionnel pour accéder aux enregistrements DNS depuis votre environnement sur site.
Familiarisez-vous avec le logiciel DNS actuel et identifiez les noms de domaine utilisés en mode privé au sein de votre organisation.
Identifiez les contacts au sein de l'équipe réseau pouvant s'assurer que le trafic vers les serveurs Cloud DNS est correctement acheminé.
Familiarisez-vous avec votre stratégie de connectivité hybride, ainsi qu'avec les modèles et les pratiques hybrides et multicloud.

Créer une convention de dénomination simple et cohérente

La convention de dénomination que vous allez adopter doit être cohérente sur l'ensemble de votre organisation et simple à mémoriser. Supposons que votre organisation utilise example.com comme nom de domaine de deuxième niveau et le domaine destiné aux ressources publiques (par exemple, www.example.com). L'emplacement où sont hébergées les zones publiques sort du cadre du présent document qui traite essentiellement de la migration des zones privées.

Pour attribuer des noms aux ressources d'entreprise sur site, vous avez le choix entre les modèles suivants :

Vous pouvez avoir des noms de domaine disjoints pour les serveurs sur site et pour Google Cloud. Ce modèle utilise un domaine distinct pour vos différents environnements (par exemple, corp.example.com) pour vos serveurs sur site et gcp.example.com pour toutes les ressources sur Google Cloud. Si vous utilisez d'autres environnements de cloud public, chacun peut disposer d'un sous-domaine distinct. Il s'agit du modèle privilégié, car il permet de transférer facilement les requêtes entre les différents environnements.

Vous pouvez également utiliser des noms de domaine séparés, tels que example.com et example.cloud.
Vous pouvez utiliser le domaine Google Cloud comme sous-domaine du domaine qui contient les serveurs sur site. Avec le domaine example.com, il est possible d'utiliser corp.example.com pour l'environnement sur site et gcp.corp.example.com dans Google Cloud. Ce schéma est couramment adopté lorsque la plupart des ressources restent sur site.
Vous pouvez utiliser le domaine sur site comme sous-domaine du domaine contenant les enregistrements Google Cloud. Avec le domaine example.com, il est possible d'utiliser corp.example.com dans Google Cloud et dc.corp.example.com sur site. Bien qu'inhabituel, ce schéma peut être appliqué aux organisations numériques dont l'empreinte sur site est minime.
Vous pouvez utiliser le même domaine pour Google Cloud et pour l'environnement sur site. Dans ce cas, Google Cloud et l'environnement sur site utilisent des ressources utilisant le domaine corp.example.com. Évitez ce format, car il rend la gestion des enregistrements dans un environnement hybride bien plus complexe. Il n'est valable que si vous faites appel à un seul système DNS faisant autorité.

Sur le reste de cette page, les noms de domaine suivants sont utilisés :

example.com en tant que nom de domaine pour vos enregistrements publics, quel que soit l'emplacement où ils sont hébergés.
corp.example.com en tant que zone hébergée par votre serveur DNS sur site. Cette zone héberge les enregistrements de vos ressources sur site.
gcp.example.com en tant que zone gérée privée Cloud DNS qui héberge les enregistrements de vos ressources Google Cloud.

La figure 1 illustre une configuration de nom de domaine cohérente entre votre réseau sur site et Google Cloud.

Figure 1. Configuration des noms de domaine cohérente dans l'ensemble de votre organisation. — **Figure 1.** La configuration des noms de domaine est cohérente dans l'ensemble de l'organisation.

Pour nommer les ressources de votre réseau de cloud privé virtuel (VPC), vous pouvez suivre les instructions, telles que celles présentées dans le guide des solutions Bonnes pratiques et architectures de référence pour la conception de VPC.

Choisir où la résolution DNS est effectuée

Dans un environnement hybride, la résolution DNS peut être effectuée à différents emplacements. Vous pouvez procéder comme suit :

utiliser une approche hybride avec deux systèmes DNS faisant autorité ;
conserver la résolution DNS sur site ;
transférer l'ensemble du processus de résolution DNS vers Cloud DNS.

Nous recommandons l'approche hybride. Ce document se concentre donc sur cette approche. Toutefois, par souci d'exhaustivité, les différentes approches possibles sont également abordées.

Utiliser une approche hybride avec deux systèmes DNS faisant autorité

Nous vous recommandons d'adopter une approche hybride avec deux systèmes DNS faisant autorité. Dans cette approche :

la résolution DNS faisant autorité pour votre environnement Google Cloud privé est assurée par Cloud DNS ;
la résolution DNS faisant autorité pour les ressources sur site est hébergée par les serveurs DNS existants sur site.

La figure 2 illustre cette disposition.

Figure 2. Architecture DNS hybride qui utilise à la fois Cloud DNS et des serveurs DNS sur site pour fournir une résolution DNS faisant autorité. — **Figure 2.** Une architecture DNS hybride qui utilise à la fois Cloud DNS et les serveurs DNS sur site fournissent Résolution DNS

Le scénario de la figure 2 est le cas d'utilisation privilégié. Les informations suivantes sont abordées plus loin sur cette page :

Configurer le transfert entre des environnements utilisant des zones privées et le transfert DNS.
Configurer les pare-feu et le routage.
Architectures de référence montrant comment utiliser un ou plusieurs réseaux VPC.

Conserver la résolution DNS sur site

Une autre approche consiste à continuer à utiliser votre serveur DNS sur site existant en tant qu'hébergement faisant autorité pour tous les noms de domaine internes. Dans ce cas, vous pouvez utiliser un autre serveur de noms pour transférer toutes les requêtes en provenance de Google Cloud via le transfert DNS sortant.

Cette approche présente les avantages suivants :

Vous apportez moins de modifications aux processus métier.
Vous pouvez continuer à utiliser vos outils existants.
Vous pouvez utiliser des listes d'interdiction pour filtrer les requêtes DNS individuelles sur site.

Cependant, cette approche comporte les inconvénients suivants :

Les requêtes DNS de Google Cloud présentent une latence plus élevée.
Votre système est dépendant de la connectivité des environnements sur site pour les opérations DNS.
Il peut être difficile d'intégrer des environnements très flexibles, tels que les groupes d'instances avec autoscaling.
Le système n'est peut-être pas compatible avec des produits tels que Dataproc, car ceux-ci reposent sur la résolution inversée des noms d'instance Google Cloud.

Transférer l'ensemble du processus de résolution DNS vers Cloud DNS

Une autre approche consiste à migrer vers Cloud DNS en tant que service faisant autorité pour l'ensemble de la résolution de domaine. Vous pouvez ensuite utiliser des zones privées et le transfert DNS entrant pour migrer votre résolution de noms sur site existante vers Cloud DNS.

Cette approche présente les avantages suivants :

Vous n'avez pas besoin de gérer un service DNS à haute disponibilité sur site.
Votre système peut utiliser Cloud DNS pour bénéficier de la journalisation et de la surveillance centralisées.

Cependant, cette approche comporte les inconvénients suivants :

Les requêtes DNS sur site ont une latence plus élevée.
Votre système nécessite une connexion fiable à votre réseau VPC pour la résolution de noms.

Bonnes pratiques relatives à la création de zones privées Cloud DNS

Les zones privées hébergent les enregistrements DNS qui ne sont visibles qu'à l'intérieur de votre organisation. Les zones publiques sur Cloud DNS ne sont pas traitées dans ce document. Ces zones sont destinées aux enregistrements publics de l'organisation, tels que les enregistrements DNS du site Web. Leur pertinence dans une configuration hybride est donc minime.

Utiliser l'automatisation pour gérer les zones privées dans le projet hôte de VPC partagé

Si vous utilisez des réseaux VPC partagés dans votre organisation, vous devez héberger toutes les zones privées sur Cloud DNS dans le projet hôte. Tous les projets de service peuvent accéder automatiquement aux enregistrements des zones privées associées au réseau VPC partagé. Vous pouvez également configurer la zone dans un projet de service à l'aide d'une liaison inter-projets.

La figure 3 montre comment les zones privées sont hébergées dans un réseau VPC partagé.

Figure 3. Zones privées hébergées dans un réseau VPC partagé (cliquez pour agrandir). — **Figure 3.** Cette configuration montre comment les zones privées sont associées à un VPC partagé.

Si vous souhaitez que les équipes définissent leurs propres enregistrements DNS, nous vous recommandons d'automatiser leur création. Par exemple, vous pouvez créer une application Web ou une API interne dans laquelle les utilisateurs définissent leurs propres enregistrements DNS dans des sous-domaines spécifiques. L'application vérifie que les enregistrements sont conformes aux règles de votre organisation.

Vous pouvez également placer votre configuration DNS dans un dépôt de code, tel que Cloud Source Repositories, sous forme de descripteurs Terraform ou Cloud Deployment Manager, puis accepter les demandes d'extraction des équipes.

Dans les deux cas, un compte de service disposant du rôle IAM Administrateur DNS dans le projet hôte permet de déployer automatiquement les modifications après leur approbation.

Définir les rôles IAM selon le principe du moindre privilège

Suivez le principe de sécurité de droit pour n'accorder le droit de modifier les enregistrements DNS ceux de votre organisation qui doivent effectuer cette tâche. Évitez d'utiliser des API de base des rôles, car ils peuvent donner accès au-delà de celles dont l'utilisateur a besoin. Cloud DNS propose des rôles et des autorisations qui vous permettent d'accorder un accès en lecture et en écriture spécifique au DNS.

S'il est important de dissocier la capacité à créer des zones DNS privées de la capacité à créer des zones publiques, utilisez l'autorisation dns.networks.bindPrivateDNSZone.

Bonnes pratiques concernant les zones de transfert DNS et les règles de serveur

Cloud DNS propose des zones de transfert DNS et des règles de serveur DNS pour permettre la recherche de noms DNS entre votre environnement sur site et Google Cloud. Vous disposez de plusieurs options pour configurer le transfert DNS. La section suivante répertorie les bonnes pratiques de configuration du système DNS hybride. Ces bonnes pratiques sont illustrées dans la section Architectures de référence pour les DNS hybrides.

Utiliser les zones de transfert pour interroger les serveurs sur site

Pour vous assurer que vous pouvez interroger les enregistrements DNS dans votre environnement sur site, configurez une zone de transfert pour le domaine que vous utilisez sur site pour vos ressources d'entreprise (par exemple, corp.example.com). Cette approche est préférable à l'utilisation d'une règle DNS qui active un serveur de noms secondaire. L'accès aux noms DNS internes de Compute Engine est conservé, et les adresses IP publiques sont toujours résolues sans saut supplémentaire via un serveur de noms sur site.

Le flux de trafic qui utilise cette configuration est présenté dans la section Architectures de référence pour les DNS hybrides.

N'utilisez des serveurs de noms secondaires que si l'ensemble du trafic DNS doit être surveillé ou filtré sur site, et si la journalisation DNS privée n'est pas en mesure de satisfaire vos exigences.

Utiliser des règles de serveur DNS pour autoriser les requêtes sur site

Pour autoriser des hôtes sur site à interroger des enregistrements DNS hébergés dans des zones privées Cloud DNS (telles que gcp.example.com), créez une règle de serveur DNS qui active le transfert DNS entrant. Le transfert DNS entrant permet à votre système d'interroger toutes les zones privées du projet, ainsi que les adresses IP DNS internes et les zones appairées.

Le flux de trafic qui utilise cette configuration est présenté dans la section Architectures de référence pour les DNS hybrides.

Ouvrir les pare-feu Google Cloud et sur site pour autoriser le trafic DNS

Assurez-vous que le trafic DNS n'est filtré nulle part dans votre réseau VPC ou dans votre environnement sur site en procédant comme suit :

Assurez-vous que votre pare-feu sur site transmet les requêtes Cloud DNS. Cloud DNS envoie les requêtes à partir de la plage d'adresses IP 35.199.192.0/19. DNS utilise le port UDP 53 ou TCP 53, en fonction la taille de la requête ou de la réponse.
Assurez-vous que votre serveur DNS ne bloque pas les requêtes. Si votre infrastructure sur site Le serveur DNS n'accepte que les requêtes provenant d'adresses IP spécifiques. Assurez-vous que la plage d'adresses IP 35.199.192.0/19 est incluse.
Assurez-vous que le trafic peut transiter de votre environnement sur site vers vos adresses IP de transfert. Dans les instances Cloud Router, ajoutez une route annoncée personnalisée pour la plage d'adresses IP 35.199.192.0/19 de votre réseau VPC à l'environnement sur site.

Utiliser le transfert conditionnel pour accéder aux enregistrements DNS depuis votre environnement sur site

Avec Cloud DNS, vous ne pouvez utiliser que les zones de transfert pour accéder aux enregistrements privés hébergés sur des serveurs DNS d'entreprise sur site. Toutefois, selon le logiciel de serveur DNS que vous utilisez, vous disposez de plusieurs options pour accéder aux enregistrements DNS dans Google Cloud depuis votre environnement sur site. Dans chaque cas, l'accès aux enregistrements s'effectue via le transfert DNS entrant :

Transfert conditionnel. Le transfert conditionnel signifie que votre serveur DNS d'entreprise transfère les requêtes destinées à des zones ou des sous-domaines spécifiques vers les adresses IP de transfert sur Google Cloud. Nous vous recommandons cette approche, car elle est la moins complexe et vous permet de contrôler de manière centralisée toutes les requêtes DNS sur les serveurs DNS d'entreprise.
Délégation. Si votre zone privée sur Google Cloud est un sous-domaine de la zone que vous utilisez sur site, vous pouvez également déléguer ce sous-domaine au serveur de noms Google Cloud en définissant les entrées NS dans votre zone. Lorsque vous utilisez cette configuration, les clients peuvent communiquer directement avec les adresses IP de transfert sur Google Cloud. Par conséquent, assurez-vous que le pare-feu laisse passer ces requêtes.
Transferts de zone. Cloud DNS n'est pas compatible avec les transferts de zone. Vous ne pouvez donc pas utiliser les transferts de zone pour synchroniser les enregistrements DNS avec vos serveurs DNS sur site.

Utiliser l'appairage DNS pour éviter le transfert sortant de plusieurs réseaux VPC

Vous ne devez pas utiliser le transfert sortant vers vos serveurs DNS sur site à partir de plusieurs réseaux VPC, car des problèmes peuvent se produire avec le trafic de retour. Google Cloud n'accepte les réponses de vos serveurs DNS que si elles sont acheminées vers le réseau VPC à l'origine de la requête. Cependant, les requêtes provenant de n'importe quel réseau VPC ont la même plage d'adresses IP 35.199.192.0/19 que la source. Par conséquent, les réponses ne peuvent pas routés correctement, sauf si vous disposez d'environnements sur site distincts.

Figure 4. Un problème survient lorsque plusieurs transferts VPC
le trafic en dehors de leurs réseaux. — **Figure 4.** Problème lié à plusieurs réseaux VPC effectuant un transfert sortant.

Nous vous recommandons de désigner un seul réseau VPC pour interroger les serveurs de noms sur site via le transfert sortant. Ensuite, d'autres réseaux VPC peuvent interroger les serveurs de noms sur site en ciblant le réseau VPC désigné à l'aide d'une zone d'appairage DNS. Les requêtes sont ensuite transférées vers des serveurs de noms sur site en fonction de l'ordre de résolution de noms du réseau VPC désigné. Cette configuration est illustrée dans la section Architectures de référence pour les DNS hybrides.

Comprendre la différence entre l'appairage DNS et l'appairage de réseaux VPC

L'appairage de réseaux VPC est différent de l'appairage DNS. L'appairage de réseaux VPC permet aux instances de machine virtuelle (VM) de plusieurs projets de communiquer, mais pas de modifier la résolution de noms. Les ressources de chaque réseau VPC suivent toujours leur propre ordre de résolution.

En revanche, avec l'appairage DNS, vous pouvez autoriser le transfert de requêtes destinées à des zones spécifiques vers un autre réseau VPC. Vous pouvez ainsi transférer des requêtes vers différents environnements Google Cloud, que les réseaux VPC soient interconnectés ou non.

L'appairage de réseaux VPC et l'appairage DNS sont également configurés différemment. Pour l'appairage de réseaux VPC, les deux réseaux VPC doivent établir une relation d'appairage avec l'autre réseau VPC. L'appairage est alors automatiquement bidirectionnel.

Un appairage DNS unidirectionnel transfère les requêtes DNS et ne nécessite pas de relation bidirectionnelle entre les réseaux VPC. Un réseau VPC dénommé réseau consommateur DNS effectue des recherches pour une zone d'appairage Cloud DNS située dans un autre réseau VPC, dénommé réseau producteur DNS. Les utilisateurs disposant de l'autorisation IAM dns.networks.targetWithPeeringZone sur le projet du réseau producteur peuvent établir un appairage DNS entre les réseaux consommateur et producteur. Pour configurer l'appairage DNS à partir d'un réseau VPC consommateur, vous devez disposer du rôle de pair DNS pour le projet hôte du réseau VPC producteur.

Si vous utilisez des noms générés automatiquement, configurez l'appairage DNS pour les zones internes.

Si vous utilisez les noms générés automatiquement pour les VM créées par le service DNS interne, vous pouvez utiliser l'appairage DNS pour transférer les zones projectname.internal vers d'autres projets. Comme le montre la figure 5, vous pouvez regrouper tous les .internal zones d'un projet hub pour les rendre accessibles depuis votre réseau sur site.

Figure 5. L'appairage DNS permet d'organiser toutes les zones internes dans un hub. — **Figure 5** : L'appairage DNS permet d'organiser toutes les zones `.internal` dans un hub.

Si vous rencontrez des problèmes, consultez le guide de dépannage.

Le guide de dépannage Cloud DNS fournit des instructions pour résoudre les problèmes courants que vous pourriez rencontrer lors de la configuration de Cloud DNS.

Architectures de référence pour le DNS hybride

Cette section fournit des architectures de référence pour les scénarios courants utilisant des zones privées Cloud DNS dans un environnement hybride. Dans chaque cas, les ressources sur site ainsi que les enregistrements de ressources et les zones Google Cloud sont gérés au sein de l'environnement. Tous les enregistrements peuvent être interrogés à partir des hôtes sur site et des hôtes Google Cloud.

Utilisez l'architecture de référence qui correspond à la conception de votre réseau VPC :

Architecture hybride avec un seul réseau VPC partagé : utilise un seul réseau VPC connecté à des environnements sur site ou en provenance de ceux-ci.
Architecture hybride avec plusieurs réseaux VPC distincts : connecte plusieurs réseaux VPC à des environnements sur site via différents tunnels VPN ou rattachements VLAN, et partage la même infrastructure DNS sur site.
Architecture hybride avec un réseau VPC concentrateur connecté à des réseaux VPC satellites : l'appairage de réseaux VPC est associé à un réseau VPC concentrateur connecté à plusieurs réseaux VPC satellites indépendants.

Dans chaque cas, l'environnement sur site est connecté aux réseaux VPC Google Cloud par un ou plusieurs tunnels Cloud VPN, ou via une interconnexion dédiée ou une interconnexion partenaire. Le mode de connexion utilisé pour chaque réseau VPC n'a pas d'importance.

Architecture hybride avec un seul réseau VPC partagé

Le cas d'utilisation le plus courant consiste en un seul réseau VPC partagé connecté à l'environnement sur site, comme illustré dans la figure 6.

Figure 6. Une architecture hybride utilise un seul réseau VPC partagé pour se connecter à un réseau sur site. — **Figure 6.** Une architecture hybride utilise un seul réseau VPC partagé pour se connecter à un réseau sur site.

Pour configurer cette architecture, procédez comme suit :

Configurez vos serveurs DNS sur site comme faisant autorité pour corp.example.com.
Configurez une zone privée faisant autorité (par exemple, gcp.example.com) sur Cloud DNS dans le projet hôte du réseau VPC partagé, ainsi que tous les enregistrements des ressources dans cette zone.
Définissez une règle de serveur DNS sur le projet hôte pour le réseau VPC partagé afin d'autoriser le transfert DNS entrant.
Définissez une zone de transfert DNS qui transfère corp.example.com aux serveurs DNS sur site. Le réseau VPC partagé doit être autorisé à interroger la zone de transfert.
Configurez le transfert vers gcp.example.com sur vos serveurs DNS sur site, en pointant vers une adresse IP de redirecteur entrant dans le réseau VPC partagé.
Assurez-vous que votre pare-feu sur site autorise le trafic DNS.
Dans les instances Cloud Router, ajoutez une route annoncée personnalisée pour la plage 35.199.192.0/19 à l'environnement sur site.

Architecture hybride avec plusieurs réseaux VPC

Une autre possibilité pour les architectures hybrides consiste à établir plusieurs réseaux VPC distincts. Ces réseaux VPC dans votre environnement Google Cloud ne sont pas connectés via l'appairage de réseaux VPC. Tous les réseaux VPC utilisent des tunnels Cloud VPN ou des rattachements VLAN séparés pour se connecter à vos environnements sur site.

Comme illustré dans la figure 7, cette architecture est souvent utilisée dans le cas d'environnements de production et de développement séparés qui ne communiquent pas entre eux, mais qui partagent des serveurs DNS.

Figure 7. Une architecture hybride peut utiliser plusieurs
entre les réseaux VPC. — **Figure 7.** Une architecture hybride peut utiliser plusieurs des réseaux VPC distincts.

Pour configurer cette architecture, procédez comme suit :

Configurez vos serveurs DNS sur site comme faisant autorité pour corp.example.com.
Configurez une zone privée (par exemple, prod.gcp.example.com) sur Cloud DNS dans le projet hôte du réseau VPC partagé de production, ainsi que tous les enregistrements des ressources dans cette zone.
Configurez une zone privée (par exemple, dev.gcp.example.com) sur Cloud DNS dans le projet hôte du réseau VPC partagé de développement, ainsi que tous les enregistrements des ressources dans cette zone.
Définissez une règle de serveur DNS sur le projet hôte pour le réseau VPC partagé de production et autorisez le transfert DNS entrant.
Dans le réseau VPC partagé de production, définissez une zone DNS pour transférer corp.example.com vers les serveurs DNS sur site.
Définissez une zone d'appairage DNS entre le réseau VPC partagé de développement et le réseau VPC partagé de production pour prod.gcp.example.com.
Définissez une zone d'appairage DNS entre le réseau VPC partagé de production et le réseau VPC partagé de développement pour dev.gcp.example.com.
Configurez le transfert entrant en déléguant la résolution de gcp.example.com. à l'adresse IP virtuelle de transfert entrant de Cloud DNS sur vos serveurs de noms sur site.
Assurez-vous que le pare-feu autorise le trafic DNS sur les pare-feu Google Cloud et sur site.
Dans les instances Cloud Router, ajoutez une route annoncée personnalisée pour la plage d'adresses IP 35.199.192.0/19 du réseau VPC partagé de production à l'environnement sur site.

Architecture hybride utilisant un réseau VPC concentrateur connecté à des réseaux VPC satellites

Une autre option consiste à utiliser Cloud Interconnect ou Cloud VPN pour connecter l'infrastructure sur site à un réseau VPC concentrateur. Comme illustré dans la figure 8, vous pouvez utiliser l'appairage de réseaux VPC pour associer un réseau VPC à plusieurs réseaux VPC satellites. Chaque réseau VPC satellite héberge ses propres zones privées sur Cloud DNS. Les routes personnalisées sur l'appairage de réseaux VPC route personnalisée sur Cloud Router, permettent un échange complet de routes et la connectivité entre les réseaux VPC sur site et tous les réseaux VPC satellites. L'appairage DNS fonctionne en parallèle avec les connexions d'appairage de réseaux VPC pour permettre la résolution de noms entre les différents environnements.

Le schéma suivant illustre cette architecture.

Figure 8. Une architecture hybride peut utiliser un VPC hub
connecté à des réseaux VPC satellites à l'aide de l'appairage de réseaux VPC. — **Figure 8.** Une architecture hybride peut utiliser un hub Réseau VPC connecté à des réseaux VPC spoke.

Pour configurer cette architecture, procédez comme suit :

Configurez vos serveurs DNS sur site comme faisant autorité pour corp.example.com.
Configurez une zone privée (par exemple, projectX.gcp.example.com) sur Cloud DNS pour chaque réseau VPC satellite, ainsi que tous les enregistrements de ressources dans cette zone.
Définissez une règle de serveur DNS sur le projet concentrateur pour le réseau VPC partagé de production afin d'autoriser le transfert DNS entrant.
Dans le réseau VPC concentrateur, créez une zone DNS privée pour corp.example.com et configurez le transfert sortant vers les serveurs DNS sur site.
Définissez une zone d'appairage DNS entre le réseau VPC concentrateur et chaque réseau VPC satellite pour projectX.gcp.example.com.
Définissez une zone d'appairage DNS entre chaque réseau VPC satellite et le réseau VPC concentrateur pour example.com.
Configurez le transfert vers gcp.example.com sur vos serveurs DNS sur site pour pointer vers une adresse IP de redirecteur entrant dans le réseau VPC concentrateur.
Assurez-vous que le pare-feu autorise le trafic DNS sur les pare-feu Google Cloud et sur site.
Dans les instances Cloud Router, ajoutez une route annoncée personnalisée pour Plage d'adresses IP 35.199.192.0/19 dans le réseau VPC hub vers l'environnement sur site.
(Facultatif) Si vous utilisez également les noms DNS internes générés automatiquement, appairez chaque zone de projet satellite (par exemple spoke-project-x.internal) au projet concentrateur et transférez toutes les requêtes destinées à .internal à partir de l'environnement sur site.

DNS public multifournisseur avec Cloud DNS

En tant que composant fondamental de la mise en réseau des applications, un DNS fiable est essentiel pour vous assurer que vos applications ou services sont disponibles pour vos utilisateurs. Toi peut améliorer la disponibilité et la résilience de vos applications et services en la configuration de plusieurs fournisseurs DNS. Lorsque plusieurs fournisseurs DNS sont configurés, votre application ou votre service peut être disponible pour vos utilisateurs, même en cas d'indisponibilité de l'un d'entre eux. Vous pouvez également simplifier le déploiement la migration d'applications hybrides ayant des dépendances sur site cloud avec une configuration DNS multifournisseur.

Google Cloud propose une solution Open Source basée sur octoDNS pour vous aider à configurer et d’exploiter un environnement avec plusieurs fournisseurs DNS. Le DNS multifournisseur utilise Cloud DNS comme l'un de vos fournisseurs DNS dans active-active (recommandée) ou active-passive pour garantir un débit élevé de l'architecture DNS disponible. Une fois la solution déployée, octoDNS effectue une synchronisation ponctuelle ou continue entre vos zones DNS actuelles et des zones gérées DNS hébergées dans Cloud DNS. Lorsque des enregistrements DNS individuels sont mis à jour, les modifications sont propagées aux zones DNS correspondantes hébergées dans Cloud DNS sans avoir à modifier vos pipelines CI/CD.

Pour configurer Cloud DNS dans une configuration DNS publique multifournisseur, voir multi-provider-dns-with-clouddns.

Étape suivante

Pour trouver des solutions aux problèmes courants que vous pouvez rencontrer lors de l'utilisation de Cloud DNS, consultez la page Dépannage.
Pour savoir comment adopter et mettre en œuvre une configuration hybride utilisant Google Cloud, consultez le guide des solutions Modèles et pratiques hybrides et multicloud.
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.