Vous pouvez configurer une règle de serveur DNS pour chaque réseau cloud privé virtuel (VPC). La règle peut spécifier le transfert DNS entrant, le transfert DNS sortant, ou les deux. Dans cette section, la règle de serveur entrant fait référence à une règle qui autorise le transfert DNS entrant. La règle de serveur sortant fait référence à une méthode possible de mise en œuvre du transfert DNS sortant. Une règle peut être à la fois une règle de serveur entrant et une règle de serveur sortant si elle met en œuvre les deux fonctionnalités.
Pour plus d'informations, consultez la page Appliquer des règles de serveur Cloud DNS.
Règles de serveur entrant
Chaque réseau VPC fournit des services de résolution de noms Cloud DNS aux instances de machine virtuelle (VM) qui disposent d'une interface réseau (vNIC) associée au réseau VPC. Lorsqu'une VM utilise son serveur de métadonnées 169.254.169.254
comme serveur de noms, Google Cloud recherche des ressources Cloud DNS en fonction de l'ordre de résolution des noms de réseau VPC.
Pour mettre les services de résolution de noms d'un réseau VPC à la disposition des réseaux sur site qui y sont connectés à l'aide de tunnels Cloud VPN, de rattachements VLAN Cloud Interconnect ou d'appareils de routeur, vous pouvez utiliser une règle de serveur entrant.
Lorsque vous créez une règle de serveur entrant, Cloud DNS crée des points d'entrée de règle de serveur entrant dans le réseau VPC auquel la règle de serveur est appliquée. Les points d'entrée de la règle de serveur entrant sont des adresses IPv4 internes issues de la plage d'adresses IPv4 principale de chaque sous-réseau du réseau VPC applicable, à l'exception des sous-réseaux contenant des données --purpose
spécifiques, tels que les sous-réseaux proxy uniquement pour certains équilibreurs de charge et les sous-réseaux utilisés par Cloud NAT pour le NAT privé.
Par exemple, si vous disposez d'un réseau VPC contenant deux sous-réseaux dans la même région et un troisième sous-réseau dans une région différente, lorsque vous configurez une règle de serveur entrante pour le réseau VPC, Cloud DNS utilise un total de trois adresses IPv4 comme points d'entrée de la règle de serveur entrante, une par sous-réseau.
Pour savoir comment créer une règle de serveur entrant pour un VPC, consultez la section Créer une règle de serveur entrant.
Réseau et région pour les requêtes entrantes
Pour traiter les requêtes DNS envoyées à des points d'entrée de règle de serveur entrant, Cloud DNS associe la requête à un réseau VPC et à une région:
Le réseau VPC associé à une requête DNS est le réseau VPC contenant le tunnel Cloud VPN, le rattachement de VLAN Cloud Interconnect ou l'interface réseau de l'appareil de routeur qui reçoit les paquets de la requête DNS.
Google recommande de créer une règle de serveur entrant dans le réseau VPC qui se connecte à votre réseau sur site. De cette façon, les points d'entrée de la stratégie de serveur entrante se trouvent dans le même réseau VPC que les tunnels Cloud VPN, les rattachements de VLAN Cloud Interconnect ou les appareils de routeur qui se connectent au réseau sur site.
Un réseau sur site peut envoyer des requêtes à des points d'entrée de règles de serveur entrantes dans un autre réseau VPC. Par exemple, si le réseau VPC contenant les tunnels Cloud VPN, les rattachements de VLAN Cloud Interconnect ou les dispositifs de routeur qui se connectent au réseau sur site est également connecté à un autre réseau VPC à l'aide de l'appairage de réseaux VPC. Toutefois, nous vous déconseillons d'utiliser cette configuration, car le réseau VPC associé aux requêtes DNS ne correspond pas au réseau VPC contenant les points d'entrée de la règle de serveur entrante. Cela signifie que les requêtes DNS ne sont pas résolues à l'aide des zones privées Cloud DNS et des stratégies de réponse dans le réseau VPC contenant la règle de serveur entrante. Pour éviter toute confusion, nous vous recommandons plutôt de suivre les étapes de configuration suivantes:
- Créez une règle de serveur entrante dans le réseau VPC qui se connecte au réseau sur site à l'aide de tunnels Cloud VPN, de rattachements de VLAN Cloud Interconnect ou de dispositifs de routeur.
- Configurez les systèmes sur site pour qu'ils envoient des requêtes DNS aux points d'entrée de la règle du serveur entrant configurés à l'étape précédente.
Configurez les ressources Cloud DNS autorisées pour le réseau VPC qui se connecte au réseau sur site. Utilisez une ou plusieurs des méthodes suivantes:
- Ajoutez le réseau VPC qui se connecte au réseau sur site à la liste des réseaux autorisés pour les zones privées Cloud DNS autorisées pour l'autre réseau VPC: si une zone privée Cloud DNS et le réseau VPC qui se connecte au réseau sur site se trouvent dans différents projets de la même organisation, utilisez l'URL complète du réseau lors de l'autorisation du réseau. Pour en savoir plus, consultez la section Configurer la liaison inter-projets.
- Zones d'appairage Cloud DNS autorisées pour le réseau VPC qui se connecte au réseau sur site: définissez le réseau cible de la zone d'appairage sur l'autre réseau VPC. Peu importe que le réseau VPC qui se connecte au réseau sur site soit connecté au réseau VPC cible de la zone d'appairage à l'aide de l'appairage de réseaux VPC, car les zones d'appairage Cloud DNS ne reposent pas sur l'appairage de réseaux VPC pour la connectivité réseau.
La région associée à une requête DNS est toujours la région contenant le tunnel Cloud VPN, le rattachement VLAN Cloud Interconnect ou l'interface réseau de l'appareil de routeur qui reçoit les paquets de la requête DNS, et non la région du sous-réseau contenant le point d'entrée d'une règle de serveur entrant.
- Par exemple, si les paquets d'une requête DNS entrent dans un réseau VPC à l'aide d'un tunnel Cloud VPN situé dans la région
us-east1
et sont envoyés à un point d'entrée d'une règle de serveur entrante dans la régionus-west1
, la région associée à la requête DNS estus-east1
. - Nous vous recommandons d'envoyer les requêtes DNS à l'adresse IPv4 d'un point d'entrée de règle de serveur entrant dans la même région que le tunnel Cloud VPN, le rattachement de VLAN Cloud Interconnect ou l'appareil de routeur.
- La région associée à une requête DNS est importante si vous utilisez des règles de routage de géolocalisation. Pour en savoir plus, consultez la section Gérer les règles de routage DNS et les vérifications de l'état.
- Par exemple, si les paquets d'une requête DNS entrent dans un réseau VPC à l'aide d'un tunnel Cloud VPN situé dans la région
Annonce de routage du point d'entrée de la règle de serveur entrant
Étant donné que les adresses IP du point d'entrée de la stratégie de serveur entrante sont extraites des plages d'adresses IPv4 principales des sous-réseaux, les routeurs Cloud annoncent ces adresses IP lorsque la session BGP (Border Gateway Protocol) d'un tunnel Cloud VPN, d'un rattachement de VLAN Cloud Interconnect ou d'un appareil de routeur est configurée pour utiliser le mode d'annonce par défaut de Cloud Router. Vous pouvez également configurer une session BGP pour annoncer les adresses IP des points d'entrée de la stratégie de serveur entrante si vous utilisez le mode d'annonce personnalisé de Cloud Router de l'une des manières suivantes:
- Vous annoncez des plages d'adresses IP de sous-réseau en plus de vos préfixes personnalisés.
- Vous incluez les adresses IP des points d'entrée des règles de serveur entrant dans vos annonces de préfixe personnalisé.
Règles de serveur sortant
Vous pouvez modifier l'ordre de résolution des noms Cloud DNS d'un réseau VPC en créant une règle de serveur sortant qui spécifie une liste de serveurs de noms alternatifs. Lorsqu'une VM utilise son serveur de métadonnées 169.254.169.254
comme serveur de noms et que vous avez spécifié d'autres serveurs de noms pour un réseau VPC, Cloud DNS envoie toutes les requêtes aux autres serveurs de noms sauf si les requêtes sont mises en correspondance par une stratégie de réponse de portée de cluster Google Kubernetes Engine ou une zone privée de portée de cluster GKE.
Types, méthodes de routage et adresses des serveurs de noms alternatifs
Cloud DNS est compatible avec trois types de serveurs de noms alternatifs et propose des méthodes standards ou privées pour leur acheminer le trafic.
Autre type de serveur de noms | Compatibilité avec le routage standard | Compatibilité avec le routage privé | Plage d'adresses source de la requête |
---|---|---|---|
Serveur de noms de type 1 Une adresse IP interne d'une VM Google Cloud dans le même réseau VPC où la règle du serveur sortant est définie. |
Uniquement les adresses IP RFC 1918 : le trafic est toujours acheminé via un réseau VPC autorisé. | Toute adresse IP interne, telle qu'une adresse privée RFC 1918, une adresse IP privée non RFC 1918, ou une adresse IP externe réutilisée de manière privée, à l'exception d'une adresse IP de serveur de noms alternatif interdite. Le trafic est toujours acheminé via un réseau VPC autorisé. | 35.199.192.0/19 |
Serveur de noms de type 2 Une adresse IP d'un système sur site, connecté au réseau VPC avec la règle de serveur sortant, à l'aide de Cloud VPN ou Cloud Interconnect |
Uniquement les adresses IP RFC 1918 : le trafic est toujours acheminé via un réseau VPC autorisé. | Toute adresse IP interne, telle qu'une adresse privée RFC 1918, une adresse IP privée non RFC 1918, ou une adresse IP externe réutilisée de manière privée, à l'exception d'une adresse IP de serveur de noms alternatif interdite. Le trafic est toujours acheminé via un réseau VPC autorisé. | 35.199.192.0/19 |
Serveur de noms de type 3 Une adresse IP externe d'un serveur de noms DNS accessible sur Internet ou l'adresse IP externe d'une ressource Google Cloud (par exemple, l'adresse IP externe d'une VM située dans un autre réseau VPC). |
Uniquement les adresses IP externes routables sur Internet : le trafic est toujours acheminé vers Internet ou vers l'adresse IP externe d'une ressource Google Cloud. | Le routage privé n'est pas accepté. | Plages sources du DNS public de Google |
Cloud DNS propose deux méthodes de routage pour interroger des serveurs de noms alternatifs:
Routage standard: Cloud DNS détermine le type du serveur de noms alternatif à l'aide de son adresse IP, puis utilise le routage privé ou public :
- Si le serveur de noms alternatif est une adresse IP RFC 1918, Cloud DNS classe le serveur de noms en tant que serveur de noms de type 1 ou de type 2 et achemine les requêtes via un réseau VPC autorisé (routage privé).
- Si le serveur de noms alternatif n'est pas une adresse IP RFC 1918, Cloud DNS classe le serveur de noms en tant que Type 3 et requiert que le serveur de noms soit accessible à Internet. Cloud DNS achemine les requêtes via Internet (routage public).
Routage privé: Cloud DNS traite le serveur de noms alternatif comme un serveur de noms de type 1 ou de type 2. Cloud DNS achemine toujours le trafic via un réseau VPC autorisé, quelle que soit l'adresse IP du serveur de noms alternatif (RFC 1918 ou non).
Adresses IP des serveurs de noms alternatifs interdites
Vous ne pouvez pas utiliser les adresses IP suivantes pour les serveurs de noms alternatifs de Cloud DNS :
169.254.0.0/16
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
::1/128
::/128
2001:db8::/32
fe80::/10
fec0::/10
ff00::/8
Configuration réseau requise pour le serveur de noms alternatif
Les exigences réseau pour les serveurs de noms alternatifs varient en fonction du type de serveur de noms alternatif. Pour déterminer le type d'un serveur de noms alternatif, consultez la section Types, méthodes de routage et adresses des serveurs de noms alternatifs. Consultez ensuite l'une des sections suivantes pour connaître les exigences réseau.
Configuration réseau requise pour les serveurs de noms alternatifs de type 1
Cloud DNS envoie les paquets dont les sources proviennent de la plage d'adresses IP 35.199.192.0/19
à l'adresse IP du serveur de noms alternatif de type 1.
Google Cloud achemine les paquets pour les requêtes à l'aide de routes de sous-réseau locales dans le réseau VPC. Assurez-vous de ne pas avoir créé de routes basées sur des règles dont les destinations incluent des adresses IP de serveurs de noms alternatifs de type 1.
Pour autoriser les paquets entrants sur les VM de serveurs de noms alternatifs, vous devez créer des règles de pare-feu VPC ou des règles dans des stratégies de pare-feu autorisant les entrées avec les caractéristiques suivantes:
- Cibles: doivent inclure les VM de serveurs de noms alternatifs
- Sources:
35.199.192.0/19
- Protocoles:
TCP
etUDP
- Port :
53
Cloud DNS exige que chaque serveur de noms alternatif renvoie les paquets de réponse à l'adresse IP Cloud DNS dans 35.199.192.0/19
à partir de laquelle la requête a été envoyée. Les sources des paquets de réponse doivent correspondre à l'adresse IP du serveur de noms alternatif auquel Cloud DNS envoie la requête d'origine. Cloud DNS ignore les réponses si elles proviennent d'une source d'adresse IP inattendue (par exemple, l'adresse IP d'un autre serveur de noms auquel un serveur de noms alternatif peut transférer une requête).
Lorsqu'un serveur de noms alternatif de type 1 envoie des paquets de réponse à 35.199.192.0/19
, il utilise un chemin de routage spécial.
Configuration réseau requise pour les serveurs de noms alternatifs de type 2
Cloud DNS envoie les paquets dont les sources proviennent de la plage d'adresses IP 35.199.192.0/19
à des serveurs de noms alternatifs de type 2. Cloud DNS s'appuie sur les types de routes suivants dans le réseau VPC auquel la règle de serveur sortante s'applique:
- Routes statiques, à l'exception des routes statiques qui ne s'appliquent qu'aux VM par tag réseau
- Routes dynamiques
Pour autoriser les paquets entrants sur les serveurs de noms alternatifs de type 2, assurez-vous de configurer des règles de pare-feu autorisant les entrées applicables aux serveurs de noms alternatifs et à tout équipement réseau sur site pertinent doté de fonctionnalités de pare-feu. La configuration effective du pare-feu doit autoriser les protocoles TCP
et UDP
avec le port de destination 53
et les sources 35.199.192.0/19
.
Cloud DNS exige que chaque serveur de noms alternatif renvoie les paquets de réponse à l'adresse IP Cloud DNS dans 35.199.192.0/19
à partir de laquelle la requête a été envoyée. Les sources des paquets de réponse doivent correspondre à l'adresse IP du serveur de noms alternatif auquel Cloud DNS envoie la requête d'origine. Cloud DNS ignore les réponses si elles proviennent d'une source d'adresse IP inattendue (par exemple, l'adresse IP d'un autre serveur de noms auquel un serveur de noms alternatif peut transférer une requête).
Votre réseau sur site doit disposer de routes pour la destination 35.199.192.0/19
, dont les sauts suivants sont des tunnels Cloud VPN, des rattachements VLAN Cloud Interconnect ou des routeurs Cloud situés dans le même réseau VPC et la même région d'où Cloud DNS envoie la requête. Tant que les sauts suivants répondent à ces exigences réseau et régionales, Google Cloud n'exige pas de chemin de retour symétrique. Les réponses des serveurs de noms alternatifs de type 2 ne peuvent pas être acheminées à l'aide des sauts suivants:
- Prochains sauts sur Internet
- Sauts suivants dans un réseau VPC différent du réseau VPC d'origine des requêtes
- Sauts suivants dans le même réseau VPC, mais dans une région différente de celle d'origine des requêtes
Pour configurer les routes 35.199.192.0/19
dans votre réseau sur site, utilisez le mode d'annonce personnalisé de Cloud Router et incluez 35.199.192.0/19
comme préfixe personnalisé dans les sessions BGP des tunnels Cloud VPN, des rattachements VLAN Cloud Interconnect ou des routeurs Cloud qui connectent votre réseau VPC au réseau sur site contenant le serveur de noms alternatifs de type 2. Vous pouvez également configurer des routes statiques équivalentes sur votre réseau sur site.
Configuration réseau requise pour les serveurs de noms alternatifs de type 3
Cloud DNS envoie des paquets dont les sources correspondent aux plages sources du DNS public Google à des serveurs de noms alternatifs de type 3. Cloud DNS utilise le routage public. Il ne s'appuie pas sur des routes dans le réseau VPC auquel la règle de serveur sortante s'applique.
Pour autoriser les paquets entrants sur les serveurs de noms alternatifs de type 3, assurez-vous que la configuration effective du pare-feu applicable au serveur de noms alternatif autorise les paquets provenant des plages de sources du DNS public de Google.
Étape suivante
- Pour configurer et appliquer des règles de serveur DNS, consultez Appliquer des règles de serveur DNS.