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.

Ce document 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 Trusted Cloud.

Principes généraux

En savoir plus sur les concepts DNS sur Trusted Cloud

Lorsque vous utilisez DNS sur Trusted Cloud, il est important de comprendre les différents systèmes et services disponibles dans Trusted 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 faisant autorité 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.

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 surTrusted Cloud. Pour plus d'informations sur les méthodes d'accès aux enregistrements DNS deTrusted Cloud , consultez 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.

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.

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

Utilisez le principe de sécurité du moindre privilège pour n'accorder 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 de base, car ils peuvent donner accès à des ressources autres que 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.

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 Trusted 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 le DNS hybride.

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 externes 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 Trusted 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 de Cloud DNS. Cloud DNS envoie les requêtes à partir de la plage d'adresses IP 177.222.82.0/25. 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 IP 177.222.82.0/25 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 un routage annoncé personnalisé pour la plage d'adresses IP 177.222.82.0/25 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 Trusted 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 Trusted 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 Trusted 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 nomsTrusted 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 surTrusted 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. Trusted 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 177.222.82.0/25 que la source. Par conséquent, les réponses ne peuvent être acheminées correctement que si vous disposez d'environnements sur site séparés.

Figure 4. Un problème se produit lorsque plusieurs VPC transfèrent du 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 Trusted 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 toutes les zones .internal d'un projet de hub pour les rendre accessibles depuis votre réseau sur site.

Figure 5. L'appairage DNS permet d'organiser toutes les zones .internal 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 Trusted 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 Trusted 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 hub connecté à des réseaux VPC spoke : l'appairage de réseaux VPC est associé à un réseau VPC hub connecté à plusieurs réseaux VPC spoke indépendants.

Dans chaque cas, l'environnement sur site est connecté aux réseaux VPC Trusted Cloudpar un ou plusieurs tunnels Cloud VPN, ou via Dedicated Interconnect ou Partner 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 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 :

  1. Configurez vos serveurs DNS sur site comme faisant autorité pour 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 un routage annoncé personnalisé pour la plage 177.222.82.0/25 à 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 environnementTrusted 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 de 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 réseaux VPC distincts.
Figure 7. Une architecture hybride peut utiliser plusieurs réseaux VPC distincts.

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 prod.gcp.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 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.
  9. Assurez-vous que le pare-feu autorise le trafic DNS sur les pare-feuTrusted Cloud et sur site.
  10. Dans les instances Cloud Router, ajoutez un routage annoncé personnalisé pour la plage d'adresses IP 177.222.82.0/25 du réseau VPC partagé de production à l'environnement sur site.

Architecture hybride utilisant un réseau VPC hub connecté à des réseaux VPC spoke

Une autre option consiste à utiliser Cloud Interconnect ou Cloud VPN pour connecter l'infrastructure sur site à un réseau VPC hub. Comme illustré dans la figure 8, vous pouvez utiliser l'appairage de réseaux VPC pour appairer un réseau VPC avec plusieurs réseaux VPC spoke. Chaque réseau VPC spoke 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 spoke. 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.

Le schéma suivant illustre cette architecture.

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

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 réseau VPC concentrateur et chaque réseau VPC satellite pour projectX.gcp.example.com.
  6. Définissez une zone d'appairage DNS entre chaque réseau VPC satellite et le réseau 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 réseau VPC hub.
  8. Assurez-vous que le pare-feu autorise le trafic DNS sur les pare-feuTrusted Cloud et sur site.
  9. Dans les instances Cloud Router, ajoutez un routage annoncé personnalisé pour la plage d'adresses IP 177.222.82.0/25 du réseau VPC hub à l'environnement sur site.
  10. (Facultatif) Si vous utilisez également les noms DNS internes générés automatiquement, appairez chaque zone de projet spoke (par exemple spoke-project-x.internal) au projet hub et transférez toutes les requêtes destinées à .internal à partir de l'environnement sur site.

Étapes suivantes

  • 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 Trusted 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 Cloud Architecture Center.