Descripción general de los extremos de salida

En este documento, se proporciona una descripción general de los extremos de salida de Cloud DNS. Los extremos de salida se pueden conectar 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 con direcciones IP privadas. El uso de extremos de salida 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 múltiples nubes.

Para aprender a crear, actualizar y asociar extremos de salida con zonas de reenvío o políticas de servidor, consulta Crea y actualiza extremos de salida.

Funciones de los extremos de salida

Los extremos de salida te permiten controlar las direcciones IP de origen para el tráfico de DNS saliente, lo que habilita un comportamiento específico de la red de VPC asignando 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 de salida cuando se consultan destinos externos con la red de VPC del host. Si la red de VPC host está autorizada para una zona de reenvío de Cloud DNS global estándar o una política de servidor configurada con extremos de salida, los Pods que usan la resolución de DNS de VPC enrutan automáticamente las consultas salientes a través de extremos de salida regionales sin necesidad de realizar modificaciones a nivel del clúster ni zonas de reenvío zonales.

Para obtener más información sobre cómo migrar tu configuración de reenvío de DNS existente a extremos de salida, consulta Migra una configuración de reenvío de Cloud DNS existente a extremos de salida.

Arquitectura de extremos de salida y enrutamiento de consultas

Se crea un extremo de salida dentro de una red de VPC específica (con una subred normal en la región de destino para la dirección IP interna del extremo) y usa la subred de solo proxy regional de esa red para su dirección IP de origen.

Cuando conectas extremos de salida 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 de salida con la clasificación más alta con el algoritmo de clasificación de destino existente. Si ese extremo está en mal estado, Cloud DNS prueba el siguiente extremo con la clasificación más alta. Se prefiere el extremo de salida geográficamente más cercano, pero no se garantiza.

El algoritmo de clasificación para los servidores de destino se ejecuta de forma automática y se basa en el patrón de conmutación por error de las zonas de reenvío existentes: selección de IP con la latencia y la 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, también se incluyen las respuestas NXDOMAIN.
  • Menor latencia para comunicarse con el destino de reenvío
  • Distancia geográfica más corta al extremo de salida Si los datos de éxito y latencia no están disponibles, se prefiere el destino más cercano.

Para protegerte contra interrupciones regionales, puedes configurar extremos de salida en al menos dos regiones en las que ejecutes 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 pueden enrutarse a través de esas conexiones para llegar a tus resolutores locales.

Incluso si el extremo con la clasificación más alta se encuentra en una región diferente, Cloud DNS seguirá 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 de salida por proyecto y por región, y hasta 100 extremos de salida conectados 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 en 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 el tráfico de forma preferencial hacia el extremo de salida en 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 de salida 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 lo que debes hacer para enrutar las consultas a los 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 IP de tu servidor DNS local y aplica una política de enrutamiento de ubicación geográfica. Configura la política para que devuelva las IPs de resolución de las consultas que provengan de esa región específica. Por ejemplo, devuelve las IP de resolución europeas para las consultas provenientes de las regiones Google Cloud europeas.
  • 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 de salida: Asocia tus extremos de salida regionales (por ejemplo, uno en una región de EE.UU. y otro en una región de Europa) con esta zona de reenvío.

Cuando una VM en 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 de salida 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: Cloud DNS resuelve el FQDN de destino (onprem-resolvers.example.com) para la región del origen de la consulta. Luego, Cloud DNS reenvía la consulta original a través del extremo de salida seleccionado a la IP del servidor DNS resuelto. La política de ubicación geográfica identifica el origen de la consulta como esa región y devuelve la dirección IP específica que configuraste para esa región.

Para obtener más información, consulta el instructivo sobre el 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 VPC de Google Cloud 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 se realizará de forma correcta. La consulta se enrutará entre regiones al extremo de salida disponible con la clasificación más alta que exista dentro de la misma red de VPC y que esté configurado en la zona de reenvío o la política del 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 de salida en cada red de VPC: Para obtener más información, consulta Crea un extremo de salida.
  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 usa solo el extremo de salida 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 de salida 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 (topología de concentrador y radio)

Puedes configurar una zona de reenvío o una política de servidor para usar un extremo de salida en una red de VPC diferente y centralizada (el concentrador). No es necesaria la conectividad de red entre la red de concentrador 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 de salida 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. El intercambio de tráfico entre redes de VPC se puede usar para llegar a destinos de reenvío en otra red de VPC.

  1. Crear un extremo de salida en la red de VPC de concentrador
  2. Crea una zona de reenvío o una política de servidor en la red de VPC de radio y configúrala para que use el extremo de salida de la red de concentrador.

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

Compatibilidad con VPC compartida

Los extremos de salida admiten implementaciones de VPC compartida. El extremo, su subred normal y su subred de solo proxy asociada se crean de forma centralizada en el proyecto host. Los proyectos de servicio pueden heredar zonas de reenvío o políticas del servidor creadas en el proyecto host, o crear sus propias zonas de reenvío privadas o políticas del servidor y vincularlas entre proyectos al extremo de salida 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 de salida

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

Borra la subred de solo proxy o la red de VPC cuando un extremo de salida la esté usando

Una subred normal, una subred de solo proxy o una red de VPC que un extremo de salida usa de forma activa está protegida contra la eliminación 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 del servidor que usen el extremo de salida y quítalo de la configuración para que ya no se use.
  2. Borra el extremo de salida: Después de que el extremo ya no esté en uso, puedes borrarlo. Esta acción libera la dependencia de la subred normal y la subred de solo proxy.
  3. Borra las subredes: Después de confirmar que no hay otros recursos que la usen, borra las subredes normales y de solo proxy.
  4. Borra la red de VPC: Una vez que se quiten todas las demás dependencias de VPC, podrás borrar la red de VPC.

Modificación de subredes

No puedes modificar directamente una subred de solo proxy cuando un extremo de salida la está usando de forma activa. Esta restricción evita que edites propiedades clave, como el rango de direcciones IP, lo que ayuda a evitar interrupciones del servicio. Para modificar la subred, debes seguir los lineamientos existentes y, primero, migrar a una subred nueva.

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

  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 vaciar las conexiones activas de ella.
  3. Espera el vaciado: Deja tiempo para que se complete el proceso de vaciado de conexiones.
  4. Borra la subred anterior: Ahora puedes borrar la subred original una vez que esté en el rol BACKUP y no tenga conexiones activas.

Previsibilidad 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 para el 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 de salida) y una subred regional de solo proxy 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 infraestructura de Google Cloud, por lo que no se requiere conectividad de red directa entre estas redes de VPC.
  • Conecta la red de VPC de salida dedicada a los 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 con 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 las instalaciones locales, intercambia el tráfico de la red de VPC de DNS dedicada con 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:

  • Uso compartido de IP de origen y subred limitado a recursos en la misma región: Los extremos de salida asignan rangos de IP de origen de la subred regional de solo proxy 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 con subredes de solo proxy: No puedes intercambiar tráfico directamente con una subred de solo proxy. La conectividad de red a los servidores de nombres externos debe establecerse 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 se admite IPv4: La dirección IP de origen de un extremo de salida 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 de salida a una red en varios proyectos: No se admite la creación de un extremo de salida en un proyecto de servicio conectado a la red de VPC compartida de un proyecto host. Los extremos de salida deben residir en el mismo proyecto que la red de VPC y la subred a la que se conectan.

  • Limitado a destinos privados: Los extremos de salida solo admiten el reenvío a destinos privados (incluidos RFC 1918, RFC 6598 y direcciones que no son RFC 1918 enrutadas de forma privada configuradas con --private-forward-targets o forwardingPath: "private") y no se pueden usar como proxy de salida o ancla de IP de origen estática para el tráfico de DNS de Internet público. Las consultas a destinos de Internet públicos 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.

  • Permiso regional: Los extremos de salida son recursos regionales. Debes crear extremos en cada región en la que quieras usarlos.

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

¿Qué sigue?