Ce document présente les points de terminaison sortants Cloud DNS. Les points de terminaison sortants peuvent être associés à des zones de transfert ou à des règles de serveur pour permettre le transfert direct des requêtes DNS des réseaux VPC vers des résolveurs DNS externes et sur site à l'aide d'adresses IP privées. L'utilisation de points de terminaison sortants offre un contrôle précis sur le trafic DNS sortant et améliore votre capacité à débloquer les cas d'utilisation de la résolution DNS hybride et multicloud.
Pour savoir comment créer, mettre à jour et associer des points de terminaison sortants à des zones de transfert ou à des règles de serveur, consultez Créer et mettre à jour des points de terminaison sortants.
Fonctionnalités des points de terminaison sortants
Les points de terminaison sortants vous permettent de contrôler les adresses IP sources du trafic DNS sortant, ce qui permet un comportement spécifique au réseau VPC en attribuant une plage de sortie unique à chaque réseau. La plage de sortie unique surmonte les limites de routage de la plage de proxy de transfert fixe existante.
Les clusters GKE héritent automatiquement des points de terminaison sortants lorsqu'ils interrogent des destinations externes avec le réseau VPC hôte. Si le réseau VPC hôte est autorisé pour une zone de transfert Cloud DNS globale standard ou une règle de serveur configurée avec des points de terminaison sortants, les pods utilisant la résolution DNS VPC acheminent automatiquement les requêtes sortantes via des points de terminaison sortants régionaux sans nécessiter de modifications au niveau du cluster ni de zones de transfert zonales.
Pour en savoir plus sur la migration de votre configuration de transfert DNS existante vers des points de terminaison sortants, consultez Migrer une configuration de transfert Cloud DNS existante vers des points de terminaison sortants.
Architecture des points de terminaison sortants et routage des requêtes
Un point de terminaison sortant est créé dans un réseau VPC spécifique et utilise le sous-réseau proxy réservé de ce réseau pour son adresse IP source.
Lorsque vous associez des points de terminaison sortants à vos zones de transfert ou à votre règle de serveur, Cloud DNS tente d'abord d'acheminer les requêtes DNS via le point de terminaison sortant le mieux classé à l'aide de l'algorithme de classement de cibles existant. Si ce point de terminaison n'est pas opérationnel, Cloud DNS essaie le point de terminaison suivant le mieux classé. Le point de terminaison sortant géographiquement le plus proche est préféré, mais pas garanti.
L'algorithme de classement des serveurs de destination est exécuté automatiquement et est basé sur le modèle de basculement des zones de transfert existant - sélection de l'adresse IP avec la latence et le taux d'erreur les plus faibles. Les facteurs suivants augmentent le classement d'une cible de transfert :
- Nombre plus élevé de réponses DNS réussies traitées par la cible de transfert.
Les réponses DNS réussies incluent également les réponses
NXDOMAIN. - Latence plus faible pour la communication avec la cible de transfert.
- Distance géographique plus courte par rapport au point de terminaison sortant. Si les données de réussite et de latence ne sont pas disponibles, la cible la plus proche est préférée.
Pour vous protéger contre les pannes régionales, vous pouvez configurer des points de terminaison sortants dans au moins deux régions où vous exécutez des charges de travail de calcul. Cette approche fournit à Cloud DNS une cible de basculement régionale et maintient une latence de requête minimale. Si votre connectivité hybride n'est provisionnée que dans certaines régions, les points de terminaison d'autres régions de calcul peuvent toujours acheminer le trafic via ces connexions pour atteindre vos résolveurs sur site.
Même si le point de terminaison le mieux classé se trouve dans une autre région, Cloud DNS continue d'acheminer les requêtes vers ce point de terminaison. Par exemple, si un point de terminaison de la région A devient indisponible, le trafic est automatiquement acheminé vers un point de terminaison opérationnel de la région B. Lorsque le point de terminaison de la région A est de nouveau opérationnel, l'algorithme de classement détecte l'amélioration de ses performances et recommence à le privilégier pour les requêtes à venir.
Vous pouvez avoir jusqu'à 10 points de terminaison sortants par projet et par région, mais vous pouvez demander une augmentation de quota dans la Google Cloud console si nécessaire. Vous pouvez associer jusqu'à 100 points de terminaison sortants à une zone de transfert ou à une règle de serveur.
Acheminer les requêtes vers des résolveurs régionaux sur site
Cloud DNS ne garantit pas que le trafic est envoyé au point de terminaison dans la même région que la VM d'origine, mais vous pouvez utiliser des règles de routage de géolocalisation pour acheminer le trafic vers le serveur de noms cible le plus proche. Bien que Cloud DNS achemine de préférence le trafic vers le point de terminaison sortant de la région la plus proche de la requête d'origine et du serveur de noms cible, la région du serveur de noms cible et la région du point de terminaison sortant ne sont pas étroitement liées. Quel que soit l'emplacement, Cloud DNS choisit le point de terminaison qui a historiquement fourni la latence la plus faible.
Vous trouverez ci-dessous une présentation générale de la procédure à suivre pour acheminer les requêtes vers des résolveurs régionaux sur site :
- Créer une zone avec une règle de géolocalisation : créez une zone privée Cloud DNS
pour un nom de domaine complet que vous contrôlez (par exemple,
onprem-resolvers.example.com) autorisé pour votre réseau VPC. Dans cette zone, créez des enregistrementsApour les adresses IP de votre serveur DNS sur site et appliquez une règle de routage de géolocalisation. Configurez la règle pour renvoyer les adresses IP du résolveur pour les requêtes provenant de cette région spécifique. Par exemple, renvoyez les adresses IP du résolveur européen pour les requêtes provenant de régions européennes Google Cloud . - Utiliser le nom de domaine complet comme cible de transfert : dans votre zone de transfert, utilisez le nom de domaine complet
que vous venez de créer (
onprem-resolvers.example.com) comme serveur DNS de destination. - Configurer des points de terminaison sortants : associez vos points de terminaison sortants régionaux (par exemple, un dans une région des États-Unis et un dans une région européenne) à cette zone de transfert.
Lorsqu'une VM d'une région effectue une requête, le système suit un processus de routage en deux étapes :
- Sélection du point de terminaison : Cloud DNS évalue la liste des points de terminaison sortants associés à la zone de transfert et sélectionne le meilleur point de terminaison (par exemple, un point de terminaison en Europe est susceptible d'être choisi pour une requête provenant d'une VM en Europe).
- Résolution de la destination : le point de terminaison sortant sélectionné résout le
nom de domaine complet de destination (
onprem-resolvers.example.com). Comme le point de terminaison sortant est une ressource régionale située dans la région spécifiée, la règle de géolocalisation identifie la source de la requête comme étant cette région et renvoie l'adresse IP spécifique que vous avez configurée pour cette région. Le point de terminaison sortant transfère ensuite la requête d'origine à l'adresse IP du serveur DNS cible.
Pour en savoir plus, consultez le tutoriel sur le transfert DNS sortant de nom de domaine complet avec Cloud DNS.
Transfert à partir d'une région sans point de terminaison local dans un seul réseau VPC
Un réseau Google Cloud VPC est une ressource globale qui peut contenir des sous-réseaux dans plusieurs régions. Si une VM effectue une requête à partir d'une région dans laquelle vous n'avez pas configuré de point de terminaison sortant, le transfert réussit quand même. La requête est acheminée entre les régions vers le point de terminaison sortant disponible le mieux classé, qui existe dans le même réseau VPC et est configuré dans la zone de transfert ou la règle de serveur.
Transfert à partir de plusieurs réseaux VPC dans la même région avec isolation de l'adresse IP source
Si vous devez transférer des requêtes à partir de plusieurs réseaux VPC dans la même région et que vous avez besoin que le résolveur sur site affiche une adresse IP source distincte pour chaque réseau VPC, procédez comme suit :
- Créer un point de terminaison sortant dans chaque réseau VPC : pour en savoir plus, consultez Créer un point de terminaison sortant.
- Créer une zone de transfert ou une règle de serveur dans chaque réseau VPC: n'autorisez la zone de transfert ou la règle de serveur que pour ce réseau VPC et n'utilisez que le point de terminaison sortant de ce réseau VPC.
Cette action permet aux VM de chaque réseau VPC d'envoyer des requêtes via le point de terminaison sortant de leur réseau VPC. Chaque point de terminaison transfère la requête au résolveur sur site. Le réseau sur site voit l'adresse IP source du sous-réseau proxy réservé de chaque réseau VPC, ce qui lui permet d'appliquer différentes configurations pour le trafic de chaque réseau.
Transfert unifié sur différents réseaux VPC (hub-and-spoke)
Vous pouvez configurer une zone de transfert ou une règle de serveur pour utiliser un point de terminaison sortant dans un autre réseau VPC centralisé (le hub). La connectivité réseau n'est pas nécessaire entre le réseau hub et le réseau VPC d'où provient la requête (le spoke), car Cloud DNS gère le transfert de requête en interne.
Vous devez configurer la connectivité réseau entre le point de terminaison sortant et les cibles de transfert dans votre zone de transfert ou votre règle de serveur. Vous pouvez établir une connectivité à l'aide de Cloud Interconnect ou de Cloud VPN pour atteindre les résolveurs sur site. Vous pouvez utiliser l'appairage de réseaux VPC pour atteindre les cibles de transfert dans un autre réseau VPC.
- Créez un point de terminaison sortant dans le réseau VPC hub.
- Créez une zone de transfert ou une règle de serveur dans le réseau VPC spoke et configurez-la pour qu'elle utilise le point de terminaison sortant du réseau hub.
Les VM des réseaux VPC spoke envoient des requêtes via le point de terminaison sortant du réseau VPC hub. Le point de terminaison transfère la requête au résolveur sur site.
Compatibilité avec les VPC partagés
Les points de terminaison sortants sont compatibles avec les déploiements de VPC partagés. Le point de terminaison et son sous-réseau proxy réservé associé sont créés de manière centralisée dans le projet hôte. Les projets de service peuvent ensuite créer des zones de transfert privées ou des règles de serveur et les lier entre les projets au point de terminaison sortant centralisé du projet hôte (nécessite dns.outboundEndpoints.bindPrivateDNSZone ou dns.outboundEndpoints.bindPrivateDNSPolicy sur le projet hôte).
Gérer les ressources réseau associées aux points de terminaison sortants
Les points de terminaison sortants Cloud DNS appliquent des dépendances de cycle de vie strictes avec leurs réseaux VPC et sous-réseaux sous-jacents pour protéger le trafic DNS de production contre les modifications accidentelles de l'infrastructure, telles que les suppressions ou les modifications.
Supprimer un sous-réseau proxy réservé ou un réseau VPC lorsqu'il est utilisé par un point de terminaison sortant
Un sous-réseau proxy réservé ou un réseau VPC activement utilisé par un point de terminaison sortant est protégé contre la suppression pour éviter les pannes. Toute tentative de suppression de ces ressources génère une erreur. Si vous souhaitez supprimer ces ressources, vous devez suivre ces étapes dans l'ordre exact :
- Mettre à jour la configuration Cloud DNS : modifiez toutes les zones de transfert ou règles de serveur qui utilisent le point de terminaison sortant et supprimez-le de la configuration afin qu'il ne soit plus utilisé.
- Supprimer le point de terminaison sortant : une fois que le point de terminaison n'est plus utilisé, vous pouvez le supprimer. Cette action supprime la dépendance au sous-réseau proxy réservé.
- Supprimer le sous-réseau proxy réservé : après avoir confirmé qu'aucune autre ressource ne l' utilise, supprimez le sous-réseau proxy réservé.
- Supprimer le réseau VPC : une fois toutes les autres dépendances VPC supprimées, vous pouvez supprimer le réseau VPC.
Modification du sous-réseau
Vous ne pouvez pas modifier directement un sous-réseau proxy réservé lorsqu'un point de terminaison sortant l'utilise activement. Cette restriction vous empêche de modifier des propriétés clés, telles que la plage d'adresses IP, ce qui permet d'éviter les pannes de service. Pour modifier le sous-réseau, vous devez suivre les consignes existantes et d'abord migrer vers un nouveau sous-réseau.
Procédez comme suit pour modifier un sous-réseau utilisé par un point de terminaison sortant :
- Créer un sous-réseau de secours : créez un sous-réseau proxy réservé dans le même
réseau VPC et la même région. Vous devez définir le rôle de ce sous-réseau sur
BACKUPlors de sa création. - Activer le nouveau sous-réseau : définissez le rôle du nouveau sous-réseau sur
ACTIVE. Cette opération définit automatiquement le sous-réseau d'origine sur le rôleBACKUPet commence à vider les connexions actives. - Attendre la vidange : laissez le temps au processus de drainage de connexion de se terminer.
- Supprimer l'ancien sous-réseau : vous pouvez maintenant supprimer le sous-réseau d'origine une fois qu'il est
défini sur le rôle
BACKUPet qu'il ne comporte plus de connexions actives.
Prévisibilité de l'adresse IP source dédiée pour les pare-feu sur site
Si vos pare-feu DNS sur site nécessitent une plage d'adresses IP source dédiée et prévisible, isolée du trafic DNS, nous vous recommandons d'appliquer l'architecture suivante :
- Déployer dans un réseau VPC de sortie dédié : créez un réseau VPC dédié avec un sous-réseau standard (pour l'adresse IP du point de terminaison sortant) et un sous-réseau proxy réservé régional réservé exclusivement à Cloud DNS (
--purpose=REGIONAL_MANAGED_PROXYet--role=ACTIVE). - Isoler les réseaux VPC de votre application : n'appairez pas ni n'acheminez pas les réseaux VPC de votre application vers ce réseau de sortie dédié. Cloud DNS achemine les requêtes en interne dans l' Google Cloud infrastructure. La connectivité réseau directe entre ces réseaux VPC n'est donc pas requise.
- Connecter le réseau VPC de sortie dédié à des cibles de transfert externes:
configurez la connectivité uniquement entre le réseau VPC de sortie dédié
et vos serveurs de noms cibles externes ou sur site. Établissez ce chemin à l'aide des éléments suivants :
- Appairage de réseaux VPC vers un VPC de transit existant: il s'agit de l'approche recommandée et la plus rentable. Si votre organisation dispose déjà d'un réseau VPC de transit central avec Cloud Interconnect ou Cloud VPN sur site, appairez le réseau VPC DNS dédié à ce hub de transit. Cette approche évite le provisionnement de circuits hybrides redondants et minimise les coûts.
- Connectivité hybride directe : interconnexion dédiée, interconnexion cross-cloud ou Cloud VPN qui se termine directement dans le réseau VPC DNS dédié.
Limites
Les points de terminaison sortants sont soumis aux limites suivantes :
Partage limité de l'adresse IP source et du sous-réseau aux ressources de la même région: les points de terminaison sortants allouent des plages d'adresses IP sources à partir du sous-réseau proxy réservé régional du réseau VPC auquel ils sont associés. Dans les déploiements standards, ce sous-réseau proxy réservé peut être partagé avec d'autres ressources régionales, telles que les équilibreurs de charge d'application régionaux.
L'appairage direct aux sous-réseaux proxy réservés n'est pas compatible : vous ne pouvez pas vous appairer directement avec un sous-réseau proxy réservé. La connectivité réseau aux serveurs de noms externes doit être établie via un routage VPC standard, tel que Cloud Interconnect, Cloud VPN ou l'appairage de réseaux VPC.
Compatibilité avec IPv4 uniquement : l'adresse IP source d'un point de terminaison sortant est IPv4 uniquement, et les requêtes ne peuvent être transférées qu'à des cibles IPv4 ou à des cibles de transfert de nom de domaine complet sur des zones de transfert qui sont résolues en adresses IPv4.
L'association de points de terminaison sortants à un réseau entre les projets n'est pas compatible: La création d'un point de terminaison sortant dans un projet de service associé au réseau VPC partagé d'un projet hôte n'est pas compatible. Les points de terminaison sortants doivent résider dans le même projet que le réseau VPC et le sous-réseau auxquels ils sont associés.
Limité aux cibles privées : les points de terminaison sortants ne sont compatibles qu'avec le transfert vers des cibles privées et ne peuvent pas être utilisés comme proxy de sortie ni comme ancre d'adresse IP source statique pour le trafic DNS Internet public. Les requêtes adressées aux cibles Internet publiques sont résolues directement via la périphérie anycast distribuée de Google pour minimiser la latence et éviter les dépendances Cloud NAT.
Champ d'application régional : les points de terminaison sortants sont des ressources régionales. Vous devez créer des points de terminaison dans chaque région dans laquelle vous prévoyez de les utiliser.
Mécanisme de transfert unique uniquement : votre mécanisme de transfert (la plage par défaut
35.199.192.0/19ou les points de terminaison sortants) est configuré au niveau de la zone de transfert ou de la règle de serveur. Toutefois, vous ne pouvez pas utiliser les deux méthodes simultanément pour la même zone ou règle.
Étape suivante
- Pour en savoir plus sur Cloud DNS, consultez la présentation de Cloud DNS.
- Pour savoir comment créer ou mettre à jour des points de terminaison sortants, consultez Créer ou mettre à jour des points de terminaison sortants.
- Pour en savoir plus, consultez Résoudre les problèmes liés aux points de terminaison sortants Cloud DNS.