Google PCNE: Cloud DNS, découverte de services et résolution de noms hybride — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Network Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Cloud DNS est le service DNS évolutif et hautement disponible de Google Cloud qui prend en charge à la fois les zones publiques faisant autorité et le DNS privé pour les VPC. Il fournit également des primitives de résolution de noms hybrides — redirection, peering, serveurs entrants, politiques de réponse et politiques DNS — pour s’intégrer avec le DNS sur site et le multi-cloud. Cette section couvre le cycle de vie du DNS faisant autorité, la visibilité et le partage des zones privées, la résolution hybride, les modèles de découverte de services, la sécurité et l’intégrité (y compris DNSSEC et les transferts de zone), la gestion avancée du trafic avec les politiques de routage, le DNS pour les points de terminaison de services privés, et les opérations post-déploiement (Day-2) telles que le dépannage, la mise en cache, la journalisation et les stratégies de migration/coexistence.

DNS faisant autorité et cycle de vie DNS

Zones gérées et enregistrements
- Une zone gérée est un conteneur pour les ensembles d’enregistrements de ressources (RRsets) pour un nom DNS unique (apex de zone).
- Types d’enregistrements : A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (et autres). Cloud DNS ne prend pas en charge les CNAME à l’apex de la zone ; utilisez A/AAAA avec l’adresse IP d’un load balancer pour le mappage de l’apex.
- Cycle de vie : créer la zone, ajouter/modifier les enregistrements (changements transactionnels), propager et exploiter (surveiller/journaliser/sécuriser).
- Importer depuis des fichiers BIND existants pour accélérer la migration :
  - Exemple : gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Zones publiques vs privées
- Les zones publiques sont accessibles mondialement via les serveurs de noms publics faisant autorité de Google. Déléguez au niveau du registrar en mettant à jour les enregistrements NS chez le parent.
- Les zones privées ne répondent que pour les réseaux VPC auxquels elles sont rattachées. Elles sont résolues par les résolveurs à portée de VPC de Google pour les instances dans ces VPC et, en option, pour les clients hybrides via la redirection entrante.
Propagation et TTL
- Au sein de Google Cloud, les modifications d’enregistrements deviennent actives en quelques secondes ; l’invalidation du cache externe dépend du TTL.
- Compromis sur le TTL : des TTL courts permettent plus d’agilité et des basculements plus sûrs, mais augmentent la charge des requêtes et peuvent réduire l’efficacité du cache ; des TTL longs réduisent la charge mais prolongent les réponses obsolètes. Pratique courante : 60–300s pour les services dynamiques ; 600–3600s pour les enregistrements stables. Avant un basculement, réduisez le TTL 24 à 48 heures à l’avance.

Visibilité des zones privées, association de VPC et conception inter-projets

Rattachement des zones privées aux VPC
- Une zone privée est explicitement associée à un ou plusieurs réseaux VPC. L’association peut s’étendre sur plusieurs projets (avec les autorisations IAM appropriées, telles que dns.admin sur la zone et la permission de lier les réseaux).
- Priorité : la correspondance du suffixe le plus long parmi les zones privées rattachées à un VPC l’emporte ; soyez prudent lors du chevauchement de zones privées (par exemple, svc.corp.internal. et corp.internal.).
- Modèles de partage inter-VPC
  - Rattachement direct : rattacher la même zone privée à plusieurs VPC. Simple sur le plan opérationnel ; évitez de rattacher là où ce n’est pas nécessaire pour réduire le rayon d’impact (blast radius).
  - VPC partagé : centraliser l’administration DNS dans le projet hôte tout en exposant le DNS aux projets de service en rattachant le VPC des sous-réseaux aux zones.
  - Zones de peering DNS : lorsque le peering de VPC est utilisé entre des réseaux, une zone de peering dans le VPC consommateur peut résoudre les enregistrements privés du VPC producteur sans dupliquer les zones.
Modes de défaillance et garde-fous
- Masquage (Shadowing) : une zone privée portant le même nom qu’une zone publique amène les clients des VPC rattachés à préférer les réponses privées, ce qui peut interrompre l’accès aux points de terminaison publics. Utilisez le split-horizon intentionnellement, documentez et testez.
- Sur-rattachement : rattacher une zone privée de manière trop large peut entraîner la fuite de noms internes. Suivez le principe du moindre privilège et utilisez des sous-domaines distincts (limités à une région/un service) pour limiter la portée.
- Séparation IAM : déléguez les droits de modification DNS (dns.admin) séparément des droits de rattachement réseau (permission de lier les réseaux) pour obtenir des domaines d’administration distincts.

Exemple court : créer et rattacher une zone privée

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

Résolution de noms hybride : Transfert, Peering et Stratégies

Zones de transfert
- Transférer de manière autoritaire les requêtes pour un suffixe (par exemple, onprem.corp.) vers des serveurs de noms spécifiques (sur site ou dans d’autres clouds). À utiliser lorsque vous n’hébergez pas la zone dans Cloud DNS mais que vous avez besoin d’une résolution transparente depuis GCP.
- Éviter les boucles : assurez-vous que les redirecteurs sur site ne pointent pas en retour vers Cloud DNS pour le même suffixe.
Zones de peering
- Résoudre les zones privées hébergées dans un VPC en peering. Nécessite une connectivité de peering de VPC ; non transitif. À utiliser pour les architectures en étoile (hub-and-spoke) afin de centraliser le DNS privé dans un VPC hub.
Stratégies DNS
- Transfert sortant : les instances d’un VPC envoient des requêtes récursives aux résolveurs sur site pour les domaines non résolus dans les zones privées de Cloud DNS. Configurer via une stratégie DNS avec les adresses IP des serveurs de noms cibles joignables via Cloud VPN/Interconnect.
- Serveurs entrants : les résolveurs sur site transfèrent les requêtes vers les adresses IP de transfert entrant fournies par Google (allouées automatiquement dans 35.199.192.0/20) pour résoudre les zones privées de Cloud DNS. À utiliser pour étendre le DNS privé de GCP aux environnements sur site et à d’autres clouds.
- Journalisation des requêtes : à activer au niveau de la stratégie pour envoyer les journaux des requêtes du résolveur à Cloud Logging à des fins d’analyse et de dépannage. Pour les zones publiques, activez la journalisation des requêtes par zone pour les requêtes autoritaires.
Stratégies de réponse
- Définir des règles pour modifier les réponses (par exemple, renvoyer NXDOMAIN pour les domaines malveillants connus, ou synthétiser des enregistrements A internes pour remplacer les réponses publiques). Appliquer avec précaution ; validez que les domaines tiers critiques ne sont pas bloqués par inadvertance.
Prérequis de connectivité
- Pour que le trafic entrant/sortant fonctionne, assurez-vous de la connectivité hybride (Cloud VPN ou Interconnect) et que les règles de pare-feu autorisent l’UDP/TCP 53 dans les deux sens selon les besoins. Le comportement d’EDNS0 et de la fragmentation UDP varie selon les réseaux — en cas de problèmes de MTU, autorisez le repli sur TCP et envisagez d’ajuster le tampon EDNS(0) sur les résolveurs sur site.
Pièges courants
- Joignabilité asymétrique : si le transfert sortant pointe vers des résolveurs sur site mais que le trafic de retour est bloqué par un pare-feu ou une asymétrie de routage, les requêtes expirent (timeout). Vérifiez les routes apprises par Cloud Router et autorisez les flux de réponse DNS.
- Suffixes partagés : des suffixes d’entreprise qui se chevauchent (corp.local vs corp.internal) peuvent provoquer des correspondances inattendues dans le chemin de recherche du résolveur. Standardisez les chemins de recherche et la propriété des suffixes.

Exemples courts :

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

Découverte de services, Split-Horizon et Points de terminaison privés

DNS Split-horizon
- Fournir des réponses différentes pour le même nom en interne et en externe. Schéma typique : le nom public foo.example.com se résout en une adresse IP publique Anycast ; le nom interne foo.example.com se résout en une adresse RFC1918 d’un ILB. Mettre en œuvre avec une zone publique et une zone privée du même nom, en limitant soigneusement la portée de la zone privée aux VPC appropriés.
Nommage des services internes
- Utiliser des suffixes internes cohérents (par exemple, svc.corp.internal) et des enregistrements orientés service (A/AAAA, SRV ou TXT spécifiques à la découverte). Conserver des TTL bas pour les services mis à l’échelle dynamiquement.
- Découverte de services GKE : les noms internes au cluster restent dans CoreDNS (svc.cluster.local). Pour une exposition entre les espaces de noms/VPC, publiez les VIP des ILB dans les zones privées de Cloud DNS ou utilisez l’intégration avec Service Directory.
Intégration avec Service Directory
- Publier automatiquement les points de terminaison de service vers le DNS via Service Directory et Cloud DNS, en émettant des enregistrements SRV et A par espace de noms/service. Utile pour découpler les producteurs et les consommateurs et pour prendre en charge la découverte d’instances de service en fonction de leur état de santé.
Points de terminaison de service privés
- Private Service Connect (PSC) vers les API Google : diriger googleapis.com de manière privée à l’aide de points de terminaison PSC, ou utiliser les VIP des API Google restreintes (199.36.153.8/30) avec une zone privée pour googleapis.com. PSC offre une connectivité IP privée, locale à la région, avec un contrôle par point de terminaison ; la VIP restreinte est plus simple mais utilise toujours des plages d’adresses IP publiques joignables via les routes par défaut.
- PSC vers les services producteurs : créer des enregistrements A/AAAA dans une zone privée pointant vers le point de terminaison PSC ou la VIP de l’ILB. Pour les domaines internes personnalisés, gérez la zone privée dans Cloud DNS et attachez-la aux VPC consommateurs.
Compromis
- PSC vs VIP restreinte : PSC offre un contrôle granulaire et évite les chemins d’inspection de sortie ; il nécessite une configuration de point de terminaison/DNS par région. La VIP restreinte est rapide à déployer mais utilise des VIP partagées et peut interagir avec les stratégies de routage de sortie.
- Risque du split-horizon : des zones privées mal délimitées peuvent bloquer l’accès à des SaaS publics (black-hole). Valider via des VM canaris et la journalisation des requêtes avant un déploiement à grande échelle.

Exemple court : mappage d’un ILB interne

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

Sécurité, gestion du trafic, opérations et migration

DNSSEC et intégrité
- Zones publiques : activez la signature DNSSEC dans Cloud DNS et publiez l’enregistrement DS auprès du bureau d’enregistrement pour vous protéger contre l’usurpation (spoofing) et l’empoisonnement du cache (cache poisoning). Planifiez les fenêtres de renouvellement des clés et surveillez les échecs de validation.
- Zones privées : la validation/signature DNSSEC est généralement inutile car la résolution s’effectue sur des réseaux de confiance ; concentrez-vous sur la sécurité du transport (liaisons hybrides) et le renforcement des résolveurs.
Transferts de zones gérées
- Cloud DNS peut agir en tant que serveur primaire ou secondaire pour AXFR/IXFR. Utilisez TSIG pour authentifier/autoriser les transferts et NOTIFY pour une propagation rapide. Les modèles de transfert de zone simplifient la coexistence lors des migrations et prennent en charge les serveurs secondaires sur site (on-prem) pour des besoins réglementaires ou de résilience.
- Modes de défaillance : transfert bloqué par des pare-feu, non-concordance de la clé TSIG, numéro de série SOA non incrémenté, ou IXFR désactivé sur le serveur primaire provoquant des transferts AXFR complets.
Règles de routage et vérifications d’état (health checks)
- Cloud DNS prend en charge les règles d’orientation du trafic (pondéré, géo, latence et basculement). Associez des vérifications d’état aux points de terminaison (endpoints) pour retirer automatiquement les réponses non saines.
- Conseils de conception : maintenez de petits ensembles d’enregistrements par cible de règle ; préférez une portée régionale alignée sur l’empreinte des utilisateurs ; combinez des TTL bas avec des intervalles de détection de panne pour limiter le temps de basculement.
- Pièges : des cartes géographiques trop granulaires peuvent entraîner une complexité opérationnelle ; l’absence d’un signal d’état cohérent conduit à des oscillations (flapping) — utilisez des seuils de stabilisation et des délais d’expiration (timeouts) de vérification d’état alignés sur le comportement de l’application.
Dépannage
- Outils : dig/nslookup avec +trace, +short, et +dnssec pour valider les chaînes ; examinez Cloud Logging pour les journaux de requêtes des résolveurs (règles DNS) et les journaux de requêtes faisant autorité (zones gérées).
- Mise en cache : confirmez quel résolveur vous testez (le fichier /etc/resolv.conf d’une VM pointe généralement vers le résolveur VPC de Google). Videz les caches des résolveurs locaux lors du test des changements de TTL. Considérez la mise en cache négative (RFC 2308) : les réponses NXDOMAIN sont mises en cache selon le TTL MINIMUM/négatif du SOA.
- Problèmes courants : boucles entre la redirection sortante et les redirecteurs conditionnels sur site ; blocage du port UDP 53 ou problèmes de MTU provoquant des réponses tronquées ; zones publiques masquées par des zones privées.
Modèles opérationnels
- Contrôle des changements : regroupez les changements avec des transactions, réduisez les TTL avant les basculements, et utilisez l’attachement à un VPC canary pour valider la visibilité.
- Journalisation et surveillance : activez la journalisation des requêtes de manière sélective ; exportez les journaux vers BigQuery pour l’analyse des tendances, et créez des alertes sur les pics de SERVFAIL/NXDOMAIN.
- Contrôle d’accès : séparez les rôles de modification d’enregistrements des rôles d’attachement réseau ; appliquez le moindre privilège aux éditeurs de règles de réponse pour éviter les blocages de domaine par inadvertance.
Migration et coexistence
- Coexistence : configurez Cloud DNS en tant que secondaire via AXFR/IXFR pendant que le DNS sur site reste primaire ; ou l’inverse (Cloud DNS primaire, secondaires sur site). Utilisez TSIG et des listes d’autorisation (allow-listing).
- Redirection conditionnelle : pour les domaines qui restent sur site, créez des zones de redirection ou des règles de redirection sortante. Assurez-vous que les liaisons hybrides sont hautement disponibles (doubles VPN avec des pairs distincts et Cloud Router).
- Pontage multi-organisation : connectez les VPC via Cloud VPN/Cloud Router, établissez une redirection conditionnelle mutuelle ou un peering selon le cas, et utilisez les transferts de zone pour les zones en cours de relocalisation. Abaissez les TTL bien avant les changements de NS ou de DS au niveau du bureau d’enregistrement.

Exemples courts :

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

Scénario de problème pratique

Contoso Retail et Fabrikam Payments sont des organisations Google Cloud distinctes qui doivent interopérer pendant un an tout en intégrant leurs réseaux et leur DNS avec un temps d’arrêt minimal. Chaque organisation utilise un espace d’adressage non chevauchant 10.0.0.0/8. Contoso hébergera des services internes sous svc.contoso.internal ; Fabrikam continuera d’héberger pay.fabrikam.internal sur site. Les deux parties doivent pouvoir résoudre les noms privés de l’autre et migrer progressivement certaines zones vers Cloud DNS.

Approche :

Établir une connectivité hybride résiliente
- Créez deux tunnels Cloud VPN entre le VPC hub de Contoso et les routeurs sur site de Fabrikam, chacun vers une adresse IP publique distincte de Fabrikam, avec BGP de Cloud Router sur les deux tunnels.
- Justification : Les tunnels doubles ainsi que le routage dynamique fournissent une redondance de chemin et propagent automatiquement les routes pour les cibles DNS, réduisant les risques de routage asymétrique pour UDP/TCP 53.
Mettre en œuvre la résolution de noms conditionnelle dans les deux sens
- Chez Contoso, créez une zone de redirection fabrikam.internal qui redirige vers les serveurs DNS sur site de Fabrikam (par exemple, 172.20.10.53 et 172.20.11.53) et attachez-la aux VPC des applications.
- Chez Fabrikam, configurez des redirecteurs conditionnels sur le DNS sur site pour rediriger svc.contoso.internal vers les adresses IP de redirection entrante de Cloud DNS de Contoso, fournies par une règle entrante de Cloud DNS.
- Justification : Les zones de redirection évitent de dupliquer l’autorité et permettent à chaque partie de conserver son DNS là où il se trouve actuellement. Les serveurs entrants étendent la résolution privée de Cloud DNS à Fabrikam sans modifier largement ses résolveurs.
Se prémunir contre les boucles de redirection et appliquer des limites de visibilité
- Assurez-vous que les redirecteurs conditionnels de Fabrikam ne redirigent pas contoso.internal en retour vers Contoso pour les noms que Fabrikam possède encore ; de même, Contoso ne doit rediriger que fabrikam.internal.
- Attachez les zones privées de Contoso uniquement aux VPC qui en ont besoin ; ne les attachez pas globalement pour réduire le rayon d’impact (blast radius).
- Justification : Élimine les boucles de récursion DNS et empêche le masquage (shadowing) de domaines publics par des zones privées.
Migrer une zone partagée en utilisant les transferts de zones gérées
- Pour une zone partagée héritée legacy.shared.internal actuellement hébergée sur le serveur BIND primaire de Fabrikam, configurez Cloud DNS en tant que secondaire avec TSIG et autorisez (allow-list) le primaire de Fabrikam pour AXFR/IXFR. Gardez Fabrikam comme primaire pendant la période de coexistence.
- Justification : Le mode secondaire fournit une synchronisation en direct sans modifier les clients. Il permet une validation sécurisée chez Contoso tout en maintenant une source unique de vérité.
Introduire le split-horizon pour les services exposés à l’externe
- Créez une zone publique contoso.example avec des enregistrements pointant vers l’adresse IP d’un équilibreur de charge HTTPS mondial pour les clients. Créez une zone privée de nom identique attachée aux VPC internes qui mappe les mêmes noms à des adresses d’ILB internes.
- Justification : Les utilisateurs externes continuent d’atteindre les équilibreurs de charge en périphérie (edge) ; les services internes atteignent les ILB privés via RFC1918, optimisant la latence et le coût tout en maintenant des noms d’hôte cohérents.
Fournir un accès privé aux API Google sans sortie via des pare-feu
- Pour les VM de Contoso sans adresses IP externes, activez Private Service Connect pour les API Google et créez la zone DNS privée gérée pour googleapis.com qui mappe vers les points de terminaison PSC.
- Justification : Garantit que l’accès à BigQuery et Pub/Sub reste privé et local au VPC, évitant les appliances de sortie tierces et préservant la posture de sécurité.
Activer l’observabilité et le contrôle
- Activez la journalisation des requêtes Cloud DNS sur la règle DNS de Contoso pour les VPC concernés et la journalisation des requêtes faisant autorité sur les zones publiques. Créez des règles de politique de réponse pour bloquer les domaines malveillants connus à l’échelle de l’organisation.
- Justification : La télémétrie des requêtes aide au dépannage et à la planification de la capacité ; les politiques de réponse fournissent un contrôle centralisé de la sécurité sans toucher à chaque résolveur.
Exécuter la gestion des changements avec des TTL sécurisés
- Réduisez les TTL à 60s pour les enregistrements en cours de migration une semaine avant les changements. Après la validation et le basculement (par exemple, passer un service du sur-site à un ILB GCP), augmentez progressivement les TTL à 300–600s.
- Justification : Des TTL courts limitent le risque pendant les transitions ; restaurer des TTL plus élevés améliore l’efficacité du cache après la stabilisation.
Tester, valider et renforcer
- Depuis des VM canary des deux côtés, exécutez dig avec +trace et vérifiez les chemins faisant autorité, confirmez l’absence de pics de SERVFAIL/NXDOMAIN dans les journaux, et simulez des pannes de liaison pour observer le comportement du DNS avec la redondance VPN.
- Justification : La validation proactive détecte tôt les problèmes de boucle/visibilité ; les simulations de panne vérifient que la résolution hybride survit aux incidents de transport sans impact pour l’utilisateur.