Migrer une configuration de transfert Cloud DNS existante vers les points de terminaison sortants

Ce document présente les grandes lignes de la procédure à suivre pour migrer une configuration de transfert Cloud DNS existante afin d'utiliser des points de terminaison sortants.

Migrer une configuration de transfert Cloud DNS existante

La migration d'une configuration de transfert Cloud DNS existante pour utiliser des points de terminaison sortants se déroule en quatre phases :

Préparation

Lors de la phase de préparation, avant de pouvoir démarrer la migration, vous devez créer les sous-réseaux proxy réservés, les sous-réseaux standards et les points de terminaison sortants. Assurez-vous également que votre réseau sur site dispose d'une route de retour pour la plage d'adresses IP du sous-réseau proxy réservé régional et que vos règles de pare-feu sur site autorisent le trafic DNS entrant provenant de la plage d'adresses IP de votre sous-réseau proxy réservé régional.

  1. Créer des sous-réseaux proxy réservés : s'ils ne sont pas déjà présents, dans chaque région où vous prévoyez de déployer un point de terminaison sortant, créez un sous-réseau proxy réservé d'une taille minimale de /26 (64 adresses).
  2. Identifier ou créer un sous-réseau standard : dans chaque région où vous prévoyez de déployer un point de terminaison sortant, identifiez ou créez un sous-réseau standard avec une adresse IPv4 interne disponible dans sa plage d'adresses IP principale.
  3. Créer des points de terminaison sortants : créez vos points de terminaison sortants et associez-les à votre réseau VPC cible, à votre région, à votre sous-réseau standard (--subnetwork=REGULAR_SUBNET) et à une adresse IPv4 interne disponible (--endpoint-ip=IP_ADDRESS_STRING). Cloud DNS crée et gère automatiquement la ressource de réservation d'adresse IP statique, et lie le point de terminaison au sous-réseau régional proxy-only du réseau VPC.

  4. Mettre à jour les pare-feu et les routes sur site : assurez-vous que votre réseau sur site dispose d'une route de retour pour la plage d'adresses IP du sous-réseau proxy réservé régional. Ajoutez des règles de pare-feu dans vos environnements sur site et externes pour autoriser le trafic DNS entrant (ports UDP et TCP 53) provenant de la plage d'adresses IP de votre sous-réseau proxy réservé régional.

Validation (facultatif)

Vous pouvez éventuellement utiliser la phase de vérification pour vérifier la configuration de votre point de terminaison sortant.

  1. Créer une zone de transfert de test : créez une zone de transfert temporaire pour un domaine de test (par exemple, test.corp.example.com).
  2. Configurer pour les points de terminaison : configurez la zone de test pour qu'elle utilise les nouveaux points de terminaison sortants.
  3. Lancez une VM de test : dans un réseau VPC pertinent, lancez une VM de test temporaire.
  4. Vérifiez la résolution : à partir de la VM de test, utilisez dig ou nslookup pour interroger un hôte dans votre zone de test (par exemple, dig host.test.corp.example.com). Vérifiez que vous recevez une réponse DNS positive. Vérifiez dans les journaux de votre serveur DNS sur site ou externe que le serveur a reçu la requête d'une adresse IP source située dans le nouveau sous-réseau proxy réservé régional. Vérifiez également dans les journaux dns_query que jsonPayload.egressPath est défini sur OUTBOUND_ENDPOINT.

Migration en production

Pendant la phase de migration en production, vous mettez à jour vos zones de transfert et vos règles de serveur pour utiliser vos points de terminaison sortants, et vous examinez les journaux de requêtes pour vous assurer que les requêtes sont résolues correctement.

  1. Mettre à jour les zones de transfert et les règles de serveur : pour chaque zone de transfert ou règle de serveur que vous souhaitez migrer, modifiez la configuration et remplacez le chemin de transfert de la plage 35.199.192.0/19 par défaut par vos points de terminaison sortants.
  2. Surveiller la résolution et l'état : examinez vos journaux de requêtes Cloud DNS (en vérifiant jsonPayload.egressPath=OUTBOUND_ENDPOINT, jsonPayload.outboundEndpoint et jsonPayload.egressError) et les métriques de surveillance existantes pour les zones migrées afin de confirmer que les requêtes DNS sont résolues correctement.
    • Utilisez dns.googleapis.com/query/response_count pour suivre le volume de requêtes et les codes d'état des réponses.
  3. Stratégie de migration et de préchauffage à volume élevé :
    • Latence de l'autoscaling : il existe une latence de démarrage d'environ 10 minutes pour l'infrastructure de proxy sous-jacente gérée par Google.
    • Déploiement incrémentiel : migrez les zones de manière incrémentielle (une zone à la fois) si votre volume de requêtes agrégé dépasse 10 000 requêtes par seconde (RPS) par région afin d'éviter les requêtes supprimées lors de l'augmentation de l'autoscaling.
    • Préchauffage de l'assistance : pour les migrations de grande envergure dans une seule zone qui dépassent immédiatement 10 000 RPS par seconde par région, augmentez progressivement le trafic (par exemple, 10%, 25%, 50%, puis 100%) ou contactez l'équipe chargée de votre compte Google Cloudou l'assistance avant la migration prévue pour demander un préchauffage de l'infrastructure pendant l'intervalle de maintenance planifié. Dans votre requête, spécifiez :
      • ID du projet
      • Région(s) cible(s)
      • Nombre maximal de RPS estimé

Nettoyage

Après avoir vérifié que la migration de production a réussi, vous devez nettoyer le mécanisme de transfert précédent.

  1. Confirmer la migration complète : vérifiez que toutes les zones de transfert et règles de serveur nécessaires dans votre projet n'utilisent pas la plage 35.199.192.0/19 par défaut.
    • Examinez vos journaux DNS sur site et assurez-vous qu'aucun trafic ne provient de cette plage pendant une période de sécurité (par exemple, 24 heures).
  2. Supprimez la règle de pare-feu précédente : après avoir vérifié que tout le trafic a été déplacé vers les points de terminaison sortants, vous pouvez supprimer en toute sécurité la règle de pare-feu sur site qui autorisait le trafic DNS entrant depuis la plage 35.199.192.0/19 par défaut. Assurez-vous qu'aucun autre service Google Cloud n'utilise cette règle avant de la supprimer ou de l'ajuster.

Rollback

Si vous devez effectuer un rollback de votre migration, procédez comme suit :

  1. Rétablir les règles de zone ou de serveur de transfert : modifiez la zone ou la règle de serveur concernée, puis rétablissez la plage 35.199.192.0/19 par défaut pour le transfert.
  2. Restaurer les règles de pare-feu : assurez-vous que la règle qui autorise le trafic DNS entrant depuis 35.199.192.0/19 est toujours active. Ne supprimez pas cette règle avant la phase de nettoyage d'une migration réussie.

Étapes suivantes