Migra una configuración de reenvío de Cloud DNS existente a extremos de salida

En este documento, se proporciona una descripción general de alto nivel de lo que debes hacer para migrar una configuración de reenvío de Cloud DNS existente para usar extremos de salida.

Migra una configuración de reenvío de Cloud DNS existente

La migración de una configuración de reenvío de Cloud DNS existente para usar extremos de salida tiene cuatro fases, que son las siguientes:

Preparación

En la fase de preparación, antes de que puedas iniciar la migración, crea las subredes de solo proxy, las subredes normales y los extremos de salida. También asegúrate de que las reglas de firewall locales permitan el tráfico de DNS entrante desde el rango de direcciones IP de tu subred de solo proxy regional.

  1. Crea subredes de solo proxy: Si aún no están presentes, en cada región en la que planeas implementar un extremo de salida, crea una subred de solo proxy con un tamaño mínimo de /26 (64 direcciones).
  2. Identifica o crea una subred normal: En cada región en la que planeas implementar un extremo de salida, identifica o crea una subred normal con una dirección IPv4 interna disponible en su rango de IP principal.
  3. Crea extremos de salida: Crea tus extremos de salida y asócialos con tu red de VPC, región, subred normal (--subnetwork=REGULAR_SUBNET), y una dirección IPv4 interna disponible (--endpoint-ip=IP_ADDRESS_STRING). Cloud DNS crea y administra automáticamente el recurso de reserva de IP estática y vincula el extremo a la subred de solo proxy regional en la red de VPC.

  4. Actualiza los firewalls locales: Agrega reglas de firewall en tus entornos locales y externos para permitir el tráfico de DNS entrante (UDP y TCP puerto 53) que se origina en el rango de direcciones IP de tu subred de solo proxy regional.

Verificación (opcional)

De manera opcional, puedes usar la fase de verificación para verificar la configuración de tu extremo de salida.

  1. Crea una zona de reenvío de prueba: Crea una zona de reenvío nueva y temporal para un dominio de prueba (por ejemplo, test.corp.example.com).
  2. Configura los extremos: Configura la zona de prueba para usar los nuevos extremos de salida.
  3. Inicia una VM de prueba: En una red de VPC pertinente, inicia una VM de prueba temporal.
  4. Verifica la resolución: Desde la VM de prueba, usa dig o nslookup para consultar un host dentro de tu zona de prueba (por ejemplo, dig host.test.corp.example.com). Confirma que recibes una respuesta de DNS correcta en la VM de prueba y que el servidor recibió la consulta. También verifica que el servidor haya recibido la consulta de una dirección IP de origen en la nueva subred de solo proxy.

Migración de producción

Durante la fase de migración de producción, actualiza tus zonas de reenvío y políticas de servidor para usar tus extremos de salida y revisar los registros de consultas para asegurarte de que las consultas se resuelvan correctamente.

  1. Actualiza las zonas de reenvío y las políticas de servidor: Para cada zona de reenvío o política de servidor que deseas migrar, edita la configuración y cambia la ruta de reenvío del rango 35.199.192.0/19 predeterminado a tus extremos de salida.
  2. Supervisa la resolución y el estado: Revisa los registros de consultas de Cloud DNS y las métricas de supervisión de las zonas migradas para confirmar que las consultas de DNS se resuelvan correctamente.
    • Usa dns.googleapis.com/query/response_count para hacer un seguimiento del volumen de consultas y los códigos de estado de respuesta.
  3. Estrategia de migración de gran volumen y precalentamiento:
    • Latencia de escalamiento automático: Hay una latencia de inicio de escalamiento automático de aproximadamente 10 minutos para la infraestructura de proxy subyacente administrada por Google.
    • Implementación incremental: Migra las zonas de forma incremental (una zona a la vez) si tu volumen de consultas agregadas supera las 10,000 consultas por segundo (QPS) por región para evitar que se descarten consultas durante el aumento del escalamiento automático.
    • Admite el precalentamiento: Para las migraciones grandes de una sola zona que superan de inmediato las 10,000 QPS por región, aumenta el tráfico de forma gradual (por ejemplo, 10%, 25%, 50% y, luego, 100%) o comunícate con tu Google Cloud equipo de cuentas o con el equipo de asistencia antes de la migración planificada para solicitar el precalentamiento de la infraestructura durante el período de mantenimiento programado. En tu solicitud, especifica lo siguiente:
      • ID del proyecto
      • Regiones de destino
      • QPS máximas estimadas

Limpieza

Después de verificar que la migración de producción se realizó correctamente, debes limpiar el mecanismo de reenvío anterior.

  1. Confirma la migración completa: Verifica que todas las zonas de reenvío y las políticas de servidor necesarias de tu proyecto no usen el rango 35.199.192.0/19 predeterminado.
    • Revisa tus registros de DNS locales y asegúrate de que no haya tráfico proveniente de este rango durante un período seguro (por ejemplo, 24 horas).
  2. Quita la regla de firewall anterior: Después de confirmar que todo el tráfico se movió a los extremos de salida, puedes quitar de forma segura la regla de firewall local que permitía el tráfico de DNS entrante desde el rango 35.199.192.0/19 predeterminado. Asegúrate de que ningún otro Google Cloud servicio use esta regla antes de quitarla o ajustarla.

Revertir

Si necesitas revertir la migración, haz lo siguiente:

  1. Revierte la zona de reenvío o las políticas de servidor: Edita la zona o la política de servidor afectada y cambia su reenvío al rango predeterminado 35.199.192.0/19.
  2. Restablece las reglas de firewall: Asegúrate de que la regla que permite el tráfico de DNS entrante desde 35.199.192.0/19 aún esté activa. No quites esta regla antes de la fase de limpieza de una migración exitosa.

¿Qué sigue?