Bonnes pratiques DNS

Ce document présente les bonnes pratiques à adopter dans les domaines suivants :

Présentation

Il est plus facile pour les utilisateurs et les applications de passer par le système de noms de domaine (DNS) pour accéder aux applications et services, car un nom est plus facile à retenir et plus souple qu'une adresse 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 primaire, 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. Pour plus d'informations, consultez la section Présentation de Cloud DNS.
  • 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.
  • Google Domains est un service d'enregistrement de noms de domaine permettant l'achat, le transfert ou la gestion de domaines. Il s'agit d'un service Google qui ne fait pas partie de Google Cloud.

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 vous documenter sur les méthodes d'accès aux enregistrements DNS Google Cloud, consultez la section Utiliser le transfert conditionnel pour accéder aux enregistrements DNS depuis un 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 :

  • Disposer de 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 complètement séparés, tels que example.com et example.cloud.

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

  • 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 "digital native" dont l'empreinte sur site est minime.

  • Utiliser le même domaine pour Google Cloud et sur site. Dans ce cas, les ressources sont utilisées aussi bien par Google Cloud que sur site par le biais du domaine corp.example.com. Vous devez toutefois éviter 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 hébergeant des enregistrements pour vos ressources Google Cloud.

Le schéma suivant illustre cette disposition :

Exemple de configuration de nom de domaine (cliquez pour agrandir)
Exemple de configuration de nom de domaine {cliquez pour agrandir}

Pour attribuer des noms aux ressources dans votre réseau VPC, vous pouvez suivre les consignes telles que celles présentées sur la page 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 :

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

Le schéma suivant illustre cette disposition :

Architecture hybride avec deux systèmes DNS faisant autorité (cliquez pour agrandir)
Architecture hybride avec deux systèmes DNS faisant autorité (cliquez pour agrandir)

Ce scénario étant le cas d'utilisation privilégié, il est traité en détail dans ce document. Voici les différents thèmes abordés :

  • 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 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 transférer toutes les requêtes provenant de Google Cloud via le transfert DNS sortant à l'aide d'un serveur de noms secondaire. Cette approche présente les avantages suivants :

  • Vous apportez moins de modifications aux processus métier.
  • Vous pouvez continuer à utiliser vos outils existants.
  • Les requêtes DNS individuelles peuvent être filtrées sur site en utilisant des listes d'interdiction.

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é 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 Cloud 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 transférer votre résolution de noms existante sur site vers Cloud DNS en utilisant des zones privées et le transfert DNS entrant. 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 exploiter les fonctionnalités de journalisation et de surveillance centralisées de Cloud DNS.

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 permettre aux équipes de 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é.

Le schéma suivant montre comment les zones privées sont hébergées dans un réseau VPC partagé :

Zones privées hébergées dans un réseau VPC partagé (cliquez pour agrandir)
Zones privées hébergées dans un réseau VPC partagé (cliquez pour agrandir)

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

En utilisant le principe de sécurité du moindre privilège, vous n'accordez le droit de modifier les enregistrements DNS qu'aux membres de votre organisation qui ont besoin d'effectuer cette tâche. Évitez d'utiliser des rôles primitifs, car ils peuvent donner accès à des ressources autres que celles dont l'utilisateur a besoin. Cloud DNS propose des autorisations et des rôles 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

Cloud DNS propose des règles de serveur DNS et des zones de transfert 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.

Le transfert DNS ne peut pas être utilisé pour transférer des données entre différents environnements Google Cloud, quel que soit leur mode d'interconnexion. Dans ce cas, utilisez l'appairage DNS.

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 exploité sur site pour vos ressources d'entreprise (tel que 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 utilisant cette configuration est illustré dans les architectures de référence.

Vous ne devez utiliser 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 DNS internes et les zones appairées. Bien que vous disposiez d'une adresse IP de redirecteur entrant distincte pour chaque sous-réseau, toutes les requêtes DNS renvoient des réponses identiques sans différence de latence. Vos applications peuvent envoyer une requête à n'importe laquelle de ces adresses.

Le flux de trafic utilisant cette configuration est illustré dans les architectures de référence.

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 VPC ou sur site. Par exemple :

  • Assurez-vous que votre pare-feu sur site transmet les requêtes depuis 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 de 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 serveur DNS sur site n'accepte que les requêtes provenant d'adresses IP spécifiques, assurez-vous que la plage d'adresses 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. Pour le transfert entrant, assurez-vous que le trafic vers les adresses IP de transfert provenant de vos serveurs DNS sur site ou d'autres clients n'est pas bloqué par votre pare-feu sur site. Vous devrez peut-être créer une règle de pare-feu sur votre pare-feu sur site pour autoriser le trafic de tous les clients sur le port UDP 53 vers l'adresse IP de transfert.

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 les utiliser 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. Les réponses de vos serveurs DNS ne sont acceptées par GCP que si elles sont acheminées vers le VPC à l'origine de la requête. Toutefois, les requêtes provenant de n'importe quel 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 être acheminées correctement que si vous disposez d'environnements sur site complètement séparés.

Le schéma suivant illustre le problème lié à plusieurs VPC effectuant un transfert sortant :

Problèmes liés à plusieurs VPC effectuant un transfert sortant (cliquez pour agrandir)
Problèmes liés à plusieurs VPC effectuant un transfert sortant (cliquez pour agrandir)

Nous vous recommandons de désigner un seul VPC pour interroger les serveurs de noms sur site via le transfert sortant. Ensuite, d'autres VPC peuvent interroger les serveurs de noms sur site en ciblant le 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 VPC du VPC désigné. Cette configuration est illustrée dans la section Architectures de référence.

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 VM de plusieurs projets de communiquer, mais pas de modifier la résolution de noms. Les ressources dans chaque 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 VPC. Cela vous permet de transférer des requêtes vers différents environnements Google Cloud, que les 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, chaque VPC doit créer une relation d'appairage avec l'autre 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 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 configurer l'appairage DNS pour transférer les zones projectname.internal vers d'autres projets. Vous pouvez agréger toutes les zones .internal d'un projet concentrateur pour les rendre disponibles sur site.

Cette configuration est illustrée par le schéma ci-dessous :

Appairage DNS dans une configuration maillée (cliquez pour agrandir)
Appairage DNS dans une configuration maillée (cliquez pour agrandir)

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 présente certaines 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.

Vous devez utiliser l'architecture de référence qui correspond à la conception de votre VPC :

  • Architecture hybride avec un seul VPC partagé : utilisation d'un seul réseau VPC connecté à/depuis l'environnement sur site.

  • Architecture hybride avec plusieurs réseaux VPC distincts : si vous connectez plusieurs VPC à l'environnement sur site via différents tunnels VPN ou rattachements VLAN, mais que vous partagez la même infrastructure DNS sur site.

  • Architecture hybride avec un réseau VPC concentrateur connecté à des réseaux VPC satellites : si vous utilisez l'appairage de réseaux VPC pour connecter un réseau VPC concentrateur à plusieurs réseaux VPC satellites indépendants.

Dans chaque cas, l'environnement sur site est connecté aux VPC Google Cloud via un ou plusieurs tunnels Cloud VPN ou à l'aide d'interconnexions dédiées ou partenaires Cloud Interconnect. 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 le plus courant est celui d'un seul réseau VPC partagé connecté à l'environnement sur site, tel qu'illustré dans le schéma suivant :

Architecture hybride utilisant un seul réseau VPC partagé (cliquez pour agrandir)
Architecture hybride utilisant un seul réseau VPC partagé (cliquez pour agrandir)

Pour configurer cette architecture, procédez comme suit :

  1. Configurez vos serveurs DNS sur site comme serveurs faisant autorité pour le domaine corp.example.com.
  2. 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.
  3. 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.
  4. 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.
  5. 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é.
  6. Assurez-vous que votre pare-feu sur site autorise le trafic DNS.
  7. Dans les instances Cloud Router, ajoutez une annonce de routage personnalisée pour la plage d'adresses 35.199.192.0/19 vers 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 sont connectés à vos environnements sur site à l'aide de tunnels Cloud VPN distincts ou de rattachements VLAN. Cette architecture est souvent utilisée lorsque vous avez des environnements distincts qui ne communiquent pas entre eux, mais qui partagent des serveurs DNS. Un autre cas d'utilisation courant consiste à créer des environnements de production et de développement séparés.

Cette architecture est illustrée par le schéma suivant :

Architecture hybride utilisant plusieurs réseaux VPC distincts (cliquez pour agrandir)
Architecture hybride utilisant plusieurs réseaux VPC distincts (cliquez pour agrandir)

Pour configurer cette architecture, procédez comme suit :

  1. Configurez vos serveurs DNS sur site comme faisant autorité pour corp.example.com.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 example.com.
  7. 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.
  8. 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é de production.
  9. Assurez-vous que le pare-feu autorise le trafic DNS sur les pare-feu Google Cloud et sur site.
  10. Dans les instances Cloud Router, ajoutez une annonce de routage personnalisée pour la plage d'adresses 35.199.192.0/19 dans le réseau VPC partagé de production vers l'environnement sur site.

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

Une autre possibilité consiste à connecter l'infrastructure sur site à un seul réseau VPC concentrateur à l'aide de Cloud Interconnect ou de Cloud VPN. Vous associez ce réseau VPC à plusieurs réseaux VPC satellites via l'appairage de réseaux VPC. Chaque réseau VPC satellite héberge ses propres zones privées sur Cloud DNS. Les routages personnalisés sur l'appairage de réseaux VPC et l'annonce de routage personnalisée sur Cloud Router permettent une connectivité et un échange de routage complets entre les réseaux VPC sur site et tous les réseaux VPC satellites. L'appairage DNS fonctionne en parallèle avec la connexion d'appairage de réseaux VPC pour permettre la résolution de noms entre les différents environnements.

Cette architecture est illustrée par le schéma suivant :

Architecture hybride utilisant un réseau VPC concentrateur connecté à des réseaux VPC satellites (cliquez pour agrandir)
Architecture hybride utilisant un réseau VPC concentrateur connecté à des réseaux VPC satellites (cliquez pour agrandir)

Pour configurer cette architecture, procédez comme suit :

  1. Configurez vos serveurs DNS sur site comme faisant autorité pour corp.example.com.
  2. 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.
  3. 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.
  4. 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.
  5. Définissez une zone d'appairage DNS entre le VPC concentrateur et chaque VPC satellite pour projectX.gcp.example.com.
  6. Définissez une zone d'appairage DNS entre chaque VPC satellite et le VPC concentrateur pour example.com.
  7. Configurez le transfert vers gcp.example.com sur vos serveurs DNS sur site pour pointer vers une adresse IP de redirecteur entrant dans le VPC concentrateur.
  8. Assurez-vous que le pare-feu autorise le trafic DNS sur les pare-feu Google Cloud et sur site.
  9. Dans les instances Cloud Router, ajoutez une annonce de routage personnalisée pour la plage d'adresses 35.199.192.0/19 dans le VPC concentrateur vers l'environnement sur site.
  10. (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.

Étapes suivantes