Descripción general de los extremos de salida

En este documento, se proporciona una descripción general de los extremos salientes de Cloud DNS. Los extremos salientes se pueden adjuntar a zonas de reenvío o políticas de servidor para habilitar el reenvío directo de consultas de DNS desde redes de VPC a agentes de resolución de DNS externos y locales mediante el uso de direcciones IP privadas. El uso de extremos salientes proporciona un control detallado sobre el tráfico de DNS saliente y mejora tu capacidad para desbloquear casos de uso de resolución de DNS híbrida y de varias nubes.

Para obtener información sobre cómo crear, actualizar y asociar extremos salientes con zonas de reenvío o políticas de servidor, consulta Crea y actualiza extremos salientes.

Capacidades de los extremos salientes

Los extremos salientes te permiten controlar las direcciones IP de origen para el tráfico de DNS saliente, lo que habilita el comportamiento específico de la red de VPC mediante la asignación de un rango de salida único para cada red. El rango de salida único supera las limitaciones de enrutamiento del rango de proxy de reenvío fijo existente.

Los clústeres de GKE heredan automáticamente los extremos salientes cuando consultan destinos externos con la red de VPC host. Si la red de VPC host está autorizada para una zona de reenvío o una política de servidor de Cloud DNS global estándar configurada con extremos salientes, los pods que usan la resolución de DNS de VPC enrutan automáticamente las consultas salientes a través de extremos salientes regionales sin requerir modificaciones a nivel del clúster ni zonas de reenvío zonales.

Para obtener más información sobre la migración de tu configuración de reenvío de DNS existente a extremos salientes, consulta Migra una configuración de reenvío de Cloud DNS existente a extremos salientes.

Arquitectura y enrutamiento de consultas de extremos salientes

Se crea un extremo saliente dentro de una red de VPC específica y usa la subred de solo proxy de esa red para su dirección IP de origen.

Cuando adjuntas extremos salientes a tus zonas de reenvío o política de servidor, Cloud DNS primero intenta enrutar las consultas de DNS a través del extremo saliente mejor clasificado mediante el algoritmo de clasificación de destino existente. Si ese extremo no está en buen estado, Cloud DNS prueba el siguiente extremo mejor clasificado. Se prefiere el extremo saliente más cercano geográficamente, pero no se garantiza.

El algoritmo de clasificación para los servidores de destino se realiza automáticamente y se basa en el patrón de conmutación por error de las zonas de reenvío existentes: selección de IP de latencia y tasa de errores más bajas. Los siguientes factores aumentan la clasificación de un destino de reenvío:

  • Mayor cantidad de respuestas del DNS exitosas que procesa el destino de reenvío Entre las respuestas del DNS exitosas, se incluyen las respuestas NXDOMAIN
  • Menor latencia para comunicarse con el destino de reenvío
  • Distancia geográfica más corta al extremo saliente Si los datos de éxito y latencia no están disponibles, se prefiere el destino más cercano.

Para protegerte contra las interrupciones regionales, puedes configurar extremos salientes en al menos dos regiones en las que ejecutas cargas de trabajo de procesamiento. Este enfoque proporciona a Cloud DNS un destino de conmutación por error regional y mantiene una latencia de consulta mínima. Si tu conectividad híbrida solo se aprovisiona en regiones seleccionadas, los extremos de otras regiones de procesamiento aún pueden enrutarse a través de esas conexiones para llegar a tus agentes de resolución locales.

Incluso si el extremo mejor clasificado está en una región diferente, Cloud DNS continúa enrutando las consultas a ese extremo. Por ejemplo, si un extremo de la región A deja de estar disponible, el tráfico se enruta automáticamente a un extremo en buen estado de la región B. Cuando el extremo de la región A vuelva a estar en buen estado, el algoritmo de clasificación detectará su rendimiento mejorado y comenzará a preferirlo nuevamente para las próximas consultas.

Puedes tener hasta 10 extremos salientes por proyecto y por región, pero puedes solicitar un aumento de cuota en la Google Cloud console si es necesario. Se pueden adjuntar hasta 100 extremos salientes a una zona de reenvío o una política de servidor.

Enruta consultas a agentes de resolución locales regionales

Cloud DNS no garantiza que el tráfico se envíe al extremo de la misma región que la VM de origen, pero puedes usar políticas de enrutamiento de ubicación geográfica para enrutar el tráfico al servidor de nombres de destino más cercano. Aunque Cloud DNS enruta de forma preferencial el tráfico hacia el extremo saliente de la región más cercana a la consulta de origen y al servidor de nombres de destino, la región del servidor de nombres de destino y la región del extremo saliente no tienen un acoplamiento alto. Independientemente de la ubicación, Cloud DNS elige el extremo que históricamente proporcionó la latencia más baja.

A continuación, se proporciona una descripción general de alto nivel de lo que debes hacer para enrutar consultas a agentes de resolución locales regionales:

  • Crea una zona con una política de ubicación geográfica: Crea una nueva zona privada de Cloud DNS para un FQDN que controles (por ejemplo, onprem-resolvers.example.com) autorizado para tu red de VPC. En esta zona, crea registros A para las IPs de tu servidor DNS local y aplica una política de enrutamiento de ubicación geográfica. Configura la política para que muestre las IPs del agente de resolución para las consultas que provienen de esa región específica. Por ejemplo, muestra las IPs del agente de resolución europeo para las consultas que provienen de regiones europeas Google Cloud .
  • Usa el FQDN como destino de reenvío: En tu zona de reenvío, usa el FQDN que acabas de crear (onprem-resolvers.example.com) como el servidor DNS de destino.
  • Configura extremos salientes: Asocia tus extremos salientes regionales (por ejemplo, uno en una región de EE.UU. y otro en una región europea) con esta zona de reenvío .

Cuando una VM de una región realiza una consulta, el sistema sigue un proceso de enrutamiento de dos pasos:

  • Selección de extremos: Cloud DNS evalúa la lista de extremos salientes asociados con la zona de reenvío y selecciona el mejor extremo (por ejemplo, es probable que se elija un extremo en Europa para una consulta de una VM en Europa).
  • Resolución de destino: El extremo saliente seleccionado resuelve el FQDN de destino (onprem-resolvers.example.com). Como el extremo saliente es un recurso regional ubicado en la región especificada, la política de ubicación geográfica identifica la fuente de la consulta como esa región y muestra la dirección IP específica que configuraste para esa región. Luego, el extremo saliente reenvía la consulta original a la IP del servidor DNS de destino.

Para obtener más información, consulta el instructivo de reenvío de DNS saliente de FQDN de Cloud DNS.

Reenvío desde una región sin un extremo local en una sola red de VPC

Una red de A Google Cloud VPC es un recurso global que puede contener subredes en varias regiones. Si una VM realiza una consulta desde una región en la que no configuraste un extremo saliente, el reenvío seguirá siendo exitoso. La consulta se enrutará entre regiones al extremo saliente disponible mejor clasificado que existe dentro de la misma red de VPC y está configurado en la zona de reenvío o la política de servidor.

Reenvío desde varias redes de VPC en la misma región con aislamiento de IP de origen

Si necesitas reenviar consultas desde varias redes de VPC en la misma región y requieres que el agente de resolución local vea una dirección IP de origen distinta para cada red de VPC, sigue estos pasos:

  1. Crea un extremo saliente en cada red de VPC: Para obtener más información, consulta Crea un extremo saliente.
  2. Crea una zona de reenvío o una política de servidor en cada red de VPC: Autoriza la zona de reenvío o la política de servidor solo para esa red de VPC y solo usa el extremo saliente de esa red de VPC.

Esta acción hace que las VMs de cada red de VPC envíen consultas a través del extremo saliente de su red de VPC. Cada extremo reenvía la consulta al agente de resolución local. La red local ve la dirección IP de origen de la subred de solo proxy de cada red de VPC, lo que le permite aplicar diferentes configuraciones para el tráfico de cada red.

Reenvío unificado en diferentes redes de VPC (central y radial)

Puedes configurar una zona de reenvío o una política de servidor para usar un extremo saliente en una red de VPC centralizada diferente (el concentrador). No es necesaria la conectividad de red entre la red central y la red de VPC en la que se origina la consulta (el radio), ya que Cloud DNS controla el reenvío de consultas de forma interna.

Debes configurar la conectividad de red entre el extremo saliente y los destinos de reenvío en tu zona de reenvío o política de servidor. La conectividad se puede establecer con Cloud Interconnect o Cloud VPN para llegar a los agentes de resolución locales. Se puede usar el intercambio de tráfico entre redes de VPC para llegar a los destinos de reenvío en otra red de VPC.

  1. Crea un extremo saliente en la red de VPC central.
  2. Crea una zona de reenvío o una política de servidor en la red de VPC radial y configúrala para usar el extremo saliente de la red central.

Las VMs de las redes de VPC radiales envían consultas a través del extremo saliente de la red de VPC central. El extremo reenvía la consulta al agente de resolución local.

Compatibilidad con VPC compartida

Los extremos salientes admiten implementaciones de VPC compartida. El extremo y su subred de solo proxy asociada se crean de forma centralizada en el proyecto host. Luego, los proyectos de servicio pueden crear zonas de reenvío privadas o políticas de servidor y vincularlas entre proyectos al extremo saliente centralizado en el proyecto host (lo que requiere dns.outboundEndpoints.bindPrivateDNSZone o dns.outboundEndpoints.bindPrivateDNSPolicy en el proyecto host).

Administra los recursos de red asociados con los extremos salientes

Los extremos salientes de Cloud DNS aplican dependencias estrictas del ciclo de vida con sus redes de VPC y subredes subyacentes para ayudar a proteger el tráfico de DNS de producción de cambios accidentales en la infraestructura, como borrados o modificaciones.

Borra la subred de solo proxy o la red de VPC cuando un extremo saliente la usa

Una subred de solo proxy o una red de VPC que usa activamente un extremo saliente está protegida contra el borrado para evitar interrupciones. Si intentas borrar estos recursos, se producirá un error. Si deseas borrar estos recursos, debes seguir estos pasos en el orden exacto:

  1. Actualiza la configuración de Cloud DNS: Edita las zonas de reenvío o las políticas de servidor que usan el extremo saliente y quítalo de la configuración para que ya no esté en uso.
  2. Borra el extremo saliente: Una vez que el extremo ya no esté en uso, puedes borrarlo. Esta acción libera la dependencia de la subred de solo proxy.
  3. Borra la subred de solo proxy: Después de confirmar que ningún otro recurso la está usando, borra la subred de solo proxy.
  4. Borra la red de VPC: Una vez que se quitan todas las demás dependencias de VPC, puedes borrar la red de VPC.

Modificación de subred

No puedes modificar directamente una subred de solo proxy cuando un extremo saliente la usa de forma activa. Esta restricción te impide editar propiedades clave, como el rango de direcciones IP, lo que ayuda a evitar interrupciones del servicio. Para modificar la subred, debes seguir las instrucciones existentes y, primero, migrar a una subred nueva.

Haz lo siguiente para modificar una subred que usa un extremo saliente:

  1. Crea una subred de copia de seguridad: Crea una nueva subred de solo proxy en la misma red de VPC y región. Debes establecer el rol de esta subred en BACKUP durante la creación.
  2. Activa la subred nueva: Actualiza el rol de la subred nueva a ACTIVE. Si lo haces, se establece automáticamente la subred original en el rol BACKUP y se comienzan a agotar las conexiones activas.
  3. Espera el vaciado de conexiones: Permite que se complete el proceso de vaciado de conexiones de la conexión.
  4. Borra la subred anterior: Ahora puedes borrar la subred original una vez que esté en el rol BACKUP y no tenga conexiones activas.

Predictibilidad de la IP de origen dedicada para firewalls locales

Si tus firewalls de DNS locales requieren un rango de direcciones IP de origen dedicado y predecible aislado al tráfico de DNS, te recomendamos que apliques la siguiente arquitectura:

  • Implementa en una red de VPC de salida dedicada: Crea una red de VPC dedicada con una subred normal (para la dirección IP del extremo saliente) y una subred de solo proxy regional reservada exclusivamente para Cloud DNS (--purpose=REGIONAL_MANAGED_PROXY y --role=ACTIVE).
  • Aísla las redes de VPC de tu aplicación: No intercambies tráfico ni enrutes las redes de VPC de tu aplicación a esta red de salida dedicada. Cloud DNS enruta las consultas de forma interna dentro de la Google Cloud infraestructura, por lo que no se requiere conectividad de red directa entre estas redes de VPC.
  • Conecta la red de VPC de salida dedicada a destinos de reenvío externos: Configura la conectividad solo entre la red de VPC de salida dedicada y tus servidores de nombres de destino externos o locales. Establece esta ruta con lo siguiente:
    • Intercambio de tráfico entre redes de VPC a una VPC de tránsito existente: Este es el enfoque recomendado y el más rentable. Si tu organización ya tiene una red de VPC de tránsito central con Cloud Interconnect o Cloud VPN a la red local, intercambia tráfico entre la red de VPC de DNS dedicada y ese concentrador de tránsito. Este enfoque evita el aprovisionamiento de circuitos híbridos redundantes y minimiza los costos.
    • Conectividad híbrida directa: Interconexión dedicada, Cross‑Cloud Interconnect o Cloud VPN que finaliza directamente en la red de VPC de DNS dedicada.

Limitaciones

Los extremos salientes tienen las siguientes limitaciones:

  • El uso compartido de IP de origen y subred se limita a los recursos de la misma región: Los extremos salientes asignan rangos de IP de origen desde la subred de solo proxy regional de la red de VPC a la que están conectados. En las implementaciones estándar, esta subred de solo proxy se puede compartir con otros recursos regionales, como los balanceadores de cargas de aplicaciones regionales.

  • No se admite el intercambio de tráfico directo a subredes de solo proxy: No puedes intercambiar tráfico directamente con una subred de solo proxy. La conectividad de red a servidores de nombres externos se debe establecer a través del enrutamiento de VPC estándar, como Cloud Interconnect, Cloud VPN o el intercambio de tráfico entre redes de VPC.

  • Solo compatibilidad con IPv4: La dirección IP de origen de un extremo saliente es solo IPv4, y las consultas solo se pueden reenviar a destinos IPv4 o destinos de reenvío de FQDN en zonas de reenvío que se resuelven en direcciones IPv4.

  • No se admite la vinculación de extremos salientes a una red entre proyectos: No se admite la creación de un extremo saliente en un proyecto de servicio conectado a la red de VPC compartida de un proyecto host. Los extremos salientes deben residir en el mismo proyecto que la red de VPC y la subred a las que se conectan.

  • Limitado a destinos privados: Los extremos salientes solo admiten el reenvío a destinos privados y no se pueden usar como un proxy de salida ni un anclaje de IP de origen estático para el tráfico de DNS de Internet público. Las consultas a destinos de Internet público se resuelven directamente a través del perímetro de Anycast distribuido de Google para minimizar la latencia y evitar las dependencias de Cloud NAT.

  • Alcance regional: Los extremos salientes son recursos regionales. Debes crear extremos en cada región en la que deseas usarlos.

  • Solo mecanismo de reenvío único: Tu mecanismo de reenvío (ya sea el rango 35.199.192.0/19 predeterminado o los extremos salientes) se configura en la zona de reenvío o a nivel de la política de servidor. Sin embargo, no puedes usar ambos métodos de forma simultánea para la misma zona o política.

¿Qué sigue?