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

Ce document fournit une présentation générale de la procédure à suivre pour migrer une configuration de transfert Cloud DNS existante afin d'utiliser des points de terminaison de sortie.

Migrer une configuration de transfert Cloud DNS existante

La migration d'une configuration de transfert Cloud DNS existante pour utiliser des points de terminaison de sortie comporte quatre phases :

Préparation

Lors de la phase de préparation, avant de pouvoir commencer la migration, vous devez créer les sous-réseaux proxy réservés, les sous-réseaux standards et les points de terminaison de sortie. Assurez-vous également que les 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 : si ce n'est pas déjà le cas, dans chaque région où vous prévoyez de déployer un point de terminaison de sortie, 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 de sortie, 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 de sortie : créez vos points de terminaison de sortie 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 proxy réservé régional du réseau VPC.

  4. Mettre à jour les pare-feu sur site : 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 validation pour vérifier la configuration de votre point de terminaison de sortie.

  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 les points de terminaison : configurez la zone de test pour qu'elle utilise les nouveaux points de terminaison de sortie.
  3. Lancer une VM de test : dans un réseau VPC approprié, lancez une VM de test temporaire.
  4. Vérifier 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 dans la VM de test et que le serveur a reçu la requête. Vérifiez également que le serveur a reçu la requête à partir d'une adresse IP source dans le nouveau sous-réseau proxy réservé.

Migration en production

Lors de la phase de migration en production, vous devez mettre à jour vos zones de transfert et vos règles de serveur pour utiliser vos points de terminaison de sortie, et examiner les journaux de requêtes pour vous assurer que les requêtes sont résolues.

  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 aller de la plage par défaut 35.199.192.0/19 par vos points de terminaison de sortie.
  2. Surveiller la résolution et l'état : examinez les journaux de requêtes Cloud DNS et les métriques de surveillance pour les zones migrées afin de vérifier que les requêtes DNS sont résolues.
    • 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 à volume élevé et de préchauffage:
    • Latence d'autoscaling : la latence de démarrage de l'autoscaling est d'environ 10 minutes pour l'infrastructure proxy sous-jacente gérée par Google.
    • Déploiement progressif : migrez les zones de manière progressive (une zone à la fois) si votre volume de requêtes agrégé dépasse 10 000 requêtes par seconde (RPS) par région pour éviter les requêtes abandonnées lors de l'augmentation de l'autoscaling.
    • Prise en charge du préchauffage : pour les migrations de grande envergure à zone unique qui dépassent immédiatement 10 000 RPS par région, augmentez progressivement le trafic (par exemple, 10%, 25%, 50%, puis 100%) ou contactez votre Google Cloud équipe chargée du compte ou l'assistance avant la migration prévue pour demander le préchauffage de l'infrastructure pendant votre intervalle de maintenance planifié. Dans votre demande, spécifiez :
      • l'ID du projet ;
      • la ou les régions cibles ;
      • le RPS maximal estimé.

Nettoyage

Une fois que vous avez vérifié que la migration en 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 de votre projet n'utilisent pas la plage par défaut 35.199.192.0/19.
    • 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. Supprimer la règle de pare-feu précédente : une fois que vous avez confirmé que tout le trafic a été transféré vers les points de terminaison de sortie, vous pouvez supprimer en toute sécurité la règle de pare-feu sur site qui autorisait le trafic DNS entrant provenant de la plage par défaut 35.199.192.0/19. Assurez-vous qu'aucun autre Google Cloud service n'utilise cette règle avant de la supprimer ou de la modifier.

Rollback

Si vous devez annuler votre migration, procédez comme suit :

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

Étape suivante