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

Existen cuatro fases para migrar una configuración de reenvío de Cloud DNS existente y usar extremos de salida, que son las siguientes:

Preparación

En la fase de preparación, antes de comenzar la migración, debes crear las subredes de solo proxy, las subredes normales y los extremos de salida. También asegúrate de que tu red local tenga una ruta de retorno para el rango de direcciones IP de la subred de solo proxy regional y de que tus 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 pretendas 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 planees 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 de destino, 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 regional de solo proxy en la red de VPC.

  4. Actualiza los firewalls y las rutas locales: Asegúrate de que tu red local tenga una ruta de retorno para el rango de direcciones IP de la subred regional de solo proxy. Agrega reglas de firewall en tus entornos locales y externos para permitir el tráfico de DNS entrante (puerto UDP y TCP 53) que se origina en el rango de direcciones IP de tu subred regional de solo proxy.

Verificación (opcional)

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

  1. Crea una zona de reenvío de prueba: Crea una zona de reenvío temporal nueva 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 relevante, 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. Verifica en los registros del servidor DNS local o externo que el servidor haya recibido la consulta de una dirección IP de origen en la nueva subred regional de solo proxy. También verifica en los registros de dns_query que jsonPayload.egressPath esté configurado como OUTBOUND_ENDPOINT.

Migración de producción

Durante la fase de migración de producción, actualizas las zonas de reenvío y las políticas del servidor para usar los 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 quieras migrar, edita la configuración y cambia la ruta de reenvío del rango predeterminado 35.199.192.0/19 a tus extremos de salida.
  2. Supervisa la resolución y el estado: Revisa tus registros de consultas de Cloud DNS (verifica jsonPayload.egressPath=OUTBOUND_ENDPOINT, jsonPayload.outboundEndpoint y jsonPayload.egressError) y las métricas de supervisión existentes para las zonas migradas para confirmar que las consultas de DNS se resuelven de forma correcta.
    • Usa dns.googleapis.com/query/response_count para hacer un seguimiento del volumen de consultas y los códigos de estado de las respuestas.
  3. Estrategia de migración de alto volumen y precalentamiento:
    • Latencia del escalado automático: Hay una latencia de inicio del escalado automático de aproximadamente 10 minutos para la infraestructura de proxy subyacente administrada por Google.
    • Lanzamiento incremental: Migra zonas de forma incremental (una zona a la vez) si el volumen de consultas agregado 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 superen 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 equipo de cuentas de Google Cloud 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 del servidor necesarias en tu proyecto no usen el rango predeterminado 35.199.192.0/19.
    • 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 predeterminado de 35.199.192.0/19. Asegúrate de que ningún otro servicio de Google Cloud esté usando esta regla antes de quitarla o ajustarla.

Revertir

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

  1. Revierte las políticas de servidor o de zona de reenvío: Edita la política de servidor o de zona afectada y cambia su reenvío al rango predeterminado de 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 siga activa. No quites esta regla antes de la fase de limpieza de una migración exitosa.

¿Qué sigue?