Información general sobre las zonas DNS

Cloud DNS admite diferentes tipos de zonas privadas. En este documento se proporciona información sobre los distintos tipos de zonas y cuándo se puede usar uno u otro.

Zonas de reenvío

Las zonas de reenvío de Cloud DNS te permiten configurar servidores de nombres de destino para zonas privadas específicas. Usar una zona de reenvío es una forma de implementar el reenvío de DNS saliente desde tu red de VPC.

Una zona de reenvío de Cloud DNS es un tipo especial de zona privada de Cloud DNS. En lugar de crear registros en la zona, especifica un conjunto de destinos de reenvío. Cada destino de reenvío es un nombre de dominio completo (FQDN) o una dirección IP de un servidor DNS ubicado en tu red de VPC o en una red local conectada a tu red de VPC mediante Cloud VPN o Cloud Interconnect.

Destinos de reenvío y métodos de enrutamiento

Cloud DNS admite cuatro tipos de destinos y ofrece métodos de enrutamiento estándar o privado para la conectividad.

Destino de reenvío Descripción Compatibilidad con el enrutamiento estándar Compatibilidad con el enrutamiento privado Fuente de las solicitudes
TYPE. Una dirección IP interna de una Trusted Cloud VM o un balanceador de carga de red interno de tipo pasarela en la misma red de VPC que tiene autorización para usar la zona de reenvío. Solo direcciones IP RFC 1918: el tráfico siempre se enruta a través de una red de VPC autorizada. Cualquier dirección IP interna, como una dirección privada RFC 1918, una dirección IP privada que no sea RFC 1918 o una dirección IP externa reutilizada de forma privada, excepto una dirección IP de destino de reenvío prohibida: el tráfico siempre se enruta a través de una red de VPC autorizada. 177.222.82.0/25
TYPE. Una dirección IP de un sistema local conectado a la red de VPC autorizada para consultar la zona de reenvío mediante Cloud VPN o Cloud Interconnect. Solo direcciones IP RFC 1918: el tráfico siempre se enruta a través de una red de VPC autorizada. Cualquier dirección IP interna, como una dirección privada RFC 1918, una dirección IP privada que no sea RFC 1918 o una dirección IP externa reutilizada de forma privada, excepto una dirección IP de destino de reenvío prohibida: el tráfico siempre se enruta a través de una red de VPC autorizada. 177.222.82.0/25
Tipo 4 Nombre de dominio completo de un servidor de nombres de destino que se puede resolver en direcciones IPv4 e IPv6 mediante el orden de resolución de la red de VPC. En función de la red del destino de reenvío resuelto, el tráfico se enruta de una de estas dos formas:
  • Direcciones IP RFC 1918: el tráfico siempre se enruta a través de una red de VPC autorizada.
  • Direcciones IP externas enrutables por Internet: el tráfico siempre se enruta a Internet o a la dirección IP externa de un Trusted Cloud recurso.

En función de la red del destino de reenvío resuelto, el tráfico se enruta a través de cualquier dirección IP interna, como una dirección privada RFC 1918, una dirección IP privada que no sea RFC 1918 o una dirección IP externa reutilizada de forma privada, excepto una dirección IP de destino de reenvío prohibida. El tráfico siempre se enruta a través de una red de VPC autorizada.

Si el servidor de nombres DNS se ha resuelto en una dirección IP externa accesible a Internet o en la dirección IP externa, no se admite el enrutamiento privado.

Cuando añada el destino de reenvío a la zona de reenvío, podrá elegir uno de los dos métodos de enrutamiento siguientes:

  • Enrutamiento estándar: enruta el tráfico a través de una red VPC autorizada o por Internet en función de si el destino de reenvío es una dirección IP RFC 1918. Si el destino de reenvío es una dirección IP RFC 1918, Cloud DNS clasifica el destino como de tipo 1 o de tipo 2 y enruta las solicitudes a través de una red de VPC autorizada. Si el destino no es una dirección IP RFC 1918, Cloud DNS lo clasifica como de tipo 3 y espera que se pueda acceder a él a través de Internet.

  • Enrutamiento privado: siempre enruta el tráfico a través de una red de VPC autorizada, independientemente de la dirección IP de destino (RFC 1918 o no). Por lo tanto, solo se admiten los objetivos de tipo 1 y de tipo 2.

Si usas un FQDN para tu destino de reenvío, tu método de enrutamiento debe coincidir con tu tipo de red. Cuando el servidor de nombres de tu dominio se resuelve en una dirección IP pública, debes usar el enrutamiento estándar.

Para acceder a un destino de reenvío de tipo 1 o de tipo 2, Cloud DNS usa rutas en la red de VPC autorizada en la que se encuentra el cliente DNS. Estas rutas definen una ruta segura al destino de reenvío:

Para obtener más información sobre los requisitos de red de los objetivos de tipo 1 y 2, consulta los requisitos de red de los objetivos de reenvío.

Para acceder a un destino de reenvío de tipo 4, Cloud DNS primero resuelve el nombre de dominio y, a continuación, usa el método de enrutamiento de la red de origen. Por ejemplo, si subdomain.example.com se resuelve en una dirección IP de un sistema on-premise conectado a la red VPC autorizada para consultar la zona de reenvío a través de Cloud VPN, utiliza las mismas reglas de enrutamiento que un destino de reenvío de tipo 2.

Cuando se usa un FQDN como destino de reenvío, solo se puede usar uno. El destino de reenvío puede resolverse en hasta 50 direcciones IP.

Direcciones IP de destino de reenvío prohibidas

No puedes usar las siguientes direcciones IP para los destinos de reenvío de Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Orden de selección de destino de reenvío

Cloud DNS te permite configurar una lista de destinos de reenvío para una zona de reenvío.

Cuando configuras dos o más destinos de reenvío, Cloud DNS usa un algoritmo interno para seleccionar uno. Este algoritmo clasifica cada destino de reenvío.

Cuando usas un nombre de dominio completo como destino de reenvío, Cloud DNS resuelve el nombre de dominio en un conjunto de hasta 50 direcciones IP y, a continuación, aplica el mismo algoritmo a esas direcciones IP.

Para procesar una solicitud, Cloud DNS primero intenta una consulta de DNS poniéndose en contacto con el destino de reenvío con la clasificación más alta. Si ese servidor no responde, Cloud DNS repite la solicitud al siguiente destino de reenvío con la clasificación más alta. Si no responde ningún destino de reenvío, Cloud DNS sintetiza una respuesta SERVFAIL.

El algoritmo de clasificación es automático y los siguientes factores aumentan la clasificación de un destino de reenvío:

  • Cuanto mayor sea el número de respuestas de DNS correctas procesadas por el destino de reenvío. Las respuestas DNS correctas incluyen respuestas NXDOMAIN.
  • Cuanto menor sea la latencia (tiempo de ida y vuelta) para comunicarse con el destino de reenvío.

Usar zonas de reenvío

Las máquinas virtuales de una red de VPC pueden usar una zona de reenvío de Cloud DNS en los siguientes casos:

  • Se ha autorizado a la red de VPC para usar la zona de reenvío de Cloud DNS. Para usar la zona de reenvío, puedes autorizar varias redes de VPC en el mismo proyecto o en diferentes proyectos, siempre que las redes de VPC pertenezcan a la misma organización.

  • El sistema operativo invitado de cada VM de la red de VPC usa el servidor de metadatos de la VM 169.254.169.254 como servidor de nombres.

Si usas un FQDN como servidor de nombres de destino, revisa los siguientes elementos:

  • Solo puedes tener un destino de reenvío.
  • No se admite la resolución de destinos FQDN a través de otra zona de reenvío.
  • No puedes usar un FQDN como servidor de nombres alternativo en las políticas de servidor.
  • Un destino FQDN puede resolverse en un máximo de 50 direcciones IP asociadas. Las direcciones resueltas que superen las 50 se truncarán.

Zonas de reenvío superpuestas

Como las zonas de reenvío de Cloud DNS son un tipo de zona privada gestionada de Cloud DNS, puedes crear varias zonas que se solapen. Las VMs configuradas como se ha descrito anteriormente resuelven un registro según el orden de resolución de nombres, usando la zona con el sufijo más largo. Para obtener más información, consulta Zonas superpuestas.

Zonas de almacenamiento en caché y de reenvío

Cloud DNS almacena en caché las respuestas de las consultas enviadas a las zonas de reenvío de Cloud DNS. Cloud DNS mantiene una caché de respuestas de los destinos de reenvío accesibles durante el periodo más corto de los siguientes:

  • 60 segundos
  • La duración del tiempo de vida (TTL) del registro

Cuando todos los destinos de reenvío de una zona de reenvío dejan de estar disponibles, Cloud DNS mantiene en caché los registros solicitados anteriormente en esa zona durante el tiempo de vida (TTL) de cada registro.

Cuándo usar el peer-to-peer

Cloud DNS no puede usar el enrutamiento transitivo para conectarse a un destino de reenvío. Para ilustrar una configuración no válida, vamos a ver el siguiente caso práctico:

  • Has usado Cloud VPN o Cloud Interconnect para conectar una red on-premise a una red de VPC llamada vpc-net-a.

  • Has usado el emparejamiento entre redes de VPC para conectar la red de VPC vpc-net-a con vpc-net-b. Has configurado vpc-net-a para exportar rutas personalizadas y vpc-net-b para importarlas.

  • Has creado una zona de reenvío cuyos objetivos de reenvío se encuentran en la red local a la que está conectada vpc-net-a. Has autorizado a vpc-net-b para que use esa zona de reenvío.

En este caso, no se puede resolver un registro en una zona servida por los destinos de reenvío, aunque haya conectividad de vpc-net-b a tu red local. Para demostrar este fallo, realiza las siguientes pruebas desde una máquina virtual de vpc-net-b:

  • Consulta el servidor de metadatos de la VM 169.254.169.254 para obtener un registro definido en la zona de reenvío. Esta consulta falla (como es de esperar) porque Cloud DNS no admite el enrutamiento transitivo a destinos de reenvío. Para usar una zona de reenvío, una VM debe configurarse para usar su servidor de metadatos.

  • Consulta directamente el destino de reenvío para obtener ese mismo registro. Aunque Cloud DNS no usa esta ruta, esta consulta demuestra que la conectividad transitiva se realiza correctamente.

Puedes usar una zona de emparejamiento de Cloud DNS para solucionar este escenario no válido:

  1. Crea una zona de emparejamiento de Cloud DNS autorizada para vpc-net-b que apunte a vpc-net-a.
  2. Crea una zona de reenvío autorizada para vpc-net-a cuyos destinos de reenvío sean servidores de nombres locales.

Puedes seguir estos pasos en el orden que prefieras. Una vez completados estos pasos, las instancias de Compute Engine de vpc-net-a y vpc-net-b podrán consultar los destinos de reenvío locales.

Para obtener información sobre cómo crear zonas de reenvío, consulta Crear una zona de reenvío.

Zonas de emparejamiento

Una zona de emparejamiento es una zona privada de Cloud DNS que te permite enviar solicitudes de DNS entre zonas de Cloud DNS de diferentes redes de VPC. Por ejemplo, un proveedor de software como servicio (SaaS) puede dar acceso a sus clientes a sus registros DNS gestionados en Cloud DNS.

Para proporcionar el peering de DNS, debes crear una zona de peering privado de Cloud DNS y configurarla para que realice búsquedas de DNS en una red de VPC en la que estén disponibles los registros del espacio de nombres de esa zona. La red de VPC en la que la zona de emparejamiento de DNS realiza las búsquedas se denomina red de productor de DNS.

La zona de peering solo es visible para las redes VPC seleccionadas durante la configuración de la zona. La red de VPC que tiene autorización para usar la zona de emparejamiento se denomina red de consumidor de DNS.

Una vez que se hayan autorizado los recursos de la red de consumidor de DNS, podrán realizar búsquedas de registros en el espacio de nombres de la zona de emparejamiento como si estuvieran en la red de productor de DNS. Trusted Cloud Las búsquedas de registros en el espacio de nombres de la zona de peering siguen el orden de resolución de nombres de la red del productor de DNS.

Por lo tanto,los recursos de Trusted Cloud en la red de consumidores de DNS pueden buscar registros en el espacio de nombres de la zona en las siguientes fuentes disponibles en la red de productores de DNS:

  • Zonas privadas gestionadas de Cloud DNS autorizadas para su uso por la red del productor de DNS.
  • Zonas de reenvío gestionadas de Cloud DNS autorizadas para su uso por la red del productor de DNS.
  • Nombres de DNS internos de Compute Engine en la red del productor de DNS.
  • Un servidor de nombres alternativo, si se ha configurado una política de servidor saliente en la red del productor de DNS.

Con el emparejamiento de DNS, puedes hacer que una red (red de consumidor de DNS) reenvíe solicitudes de DNS a otra red (red de productor de DNS), que luego realiza las búsquedas de DNS.

Limitaciones y puntos clave del emparejamiento de DNS

Ten en cuenta lo siguiente al configurar el peering de DNS:

  • El emparejamiento de DNS es una relación unidireccional. Permite que los recursos de la red de consumidor de DNS busquen registros en el espacio de nombres de la zona de peering como si los recursos estuvieran en la red de productor de DNS. Trusted Cloud Trusted Cloud
  • Las redes de productor y consumidor de DNS deben ser redes de VPC.
  • Aunque las redes de productores y consumidores de DNS suelen formar parte de la misma organización, también se admite el emparejamiento de DNS entre organizaciones.
  • El emparejamiento de DNS y el emparejamiento entre redes de VPC son servicios diferentes. El emparejamiento de redes VPC no comparte automáticamente la información de DNS. El emparejamiento de DNS se puede usar con el emparejamiento entre redes de VPC, pero este no es obligatorio para el emparejamiento de DNS.
  • Se admite el emparejamiento de DNS transitivo, pero solo a través de un único salto transitivo. Es decir, no pueden participar más de tres redes de VPC (la red intermedia es el salto transitivo). Por ejemplo, puedes crear una zona de peering en vpc-net-a que tenga como destino vpc-net-b y, a continuación, crear una zona de peering en vpc-net-b que tenga como destino vpc-net-c.
  • Si usas el peering de DNS para orientar una zona de reenvío mientras el enrutamiento dinámico global está inhabilitado en la red de VPC del productor, la red de VPC de destino con la zona de reenvío debe contener una VM, una vinculación de VLAN o un túnel de Cloud VPN ubicado en la misma región que la VM de origen que usa la zona de peering de DNS. Para obtener más información sobre esta limitación, consulta el artículo No se pueden reenviar consultas desde máquinas virtuales de una red de VPC de consumidor a una red de VPC de productor.

Para obtener instrucciones sobre cómo crear una zona de emparejamiento, consulta Crear una zona de emparejamiento.

Zonas superpuestas

Dos zonas se superponen cuando el nombre de dominio de origen de una zona es idéntico al origen de la otra zona o es un subdominio de este. Por ejemplo:

  • Una zona para gcp.example.com y otra para gcp.example.com se superponen porque los nombres de dominio son idénticos.
  • Una zona de dev.gcp.example.com y una zona de gcp.example.com se solapan porque dev.gcp.example.com es un subdominio de gcp.example.com.

Reglas para zonas superpuestas

Cloud DNS aplica las siguientes reglas a las zonas superpuestas:

  • Las zonas privadas cuyo ámbito se limita a diferentes redes de VPC pueden superponerse entre sí. Por ejemplo, dos redes VPC pueden tener una VM de base de datos llamada database.gcp.example.com en una zona gcp.example.com. Las consultas de database.gcp.example.com reciben respuestas diferentes según los registros de zona definidos en la zona autorizada para cada red de VPC.

  • Dos zonas privadas que se hayan autorizado para que se pueda acceder a ellas desde la misma red de VPC no pueden tener orígenes idénticos, a menos que una zona sea un subdominio de la otra. El servidor de metadatos usa la coincidencia de sufijo más largo para determinar qué origen debe consultar para obtener los registros de una zona determinada.

    • Ejemplos de resolución de consultas

    Trusted Cloud resuelve las zonas de Cloud DNS tal como se describe en Orden de resolución de nombres. Al determinar la zona en la que se debe consultar un registro determinado, Cloud DNS intenta encontrar una zona que coincida con la mayor parte posible del registro solicitado (la coincidencia de sufijo más larga).

    A menos que hayas especificado un servidor de nombres alternativo en una política de servidor saliente, Trusted Cloud primero se intenta encontrar un registro en una zona privada (o una zona de reenvío o una zona de peering) autorizada para tu red VPC.

    Enlace entre proyectos

    La vinculación entre proyectos te permite mantener la propiedad del espacio de nombres de DNS del proyecto de servicio independientemente de la propiedad del espacio de nombres de DNS de toda la red de VPC.

    En una configuración típica de VPC compartida, los proyectos de servicio se hacen cargo de una aplicación o unos servicios de máquina virtual, mientras que el proyecto host se hace cargo de la red de VPC y de la infraestructura de red. A menudo, se crea un espacio de nombres DNS a partir del espacio de nombres de la red de VPC para que coincida con los recursos del proyecto de servicio. En este tipo de configuración, puede ser más fácil delegar la administración del espacio de nombres DNS de cada proyecto de servicio en los administradores de cada proyecto de servicio (que suelen ser departamentos o empresas diferentes). El enlace entre proyectos te permite separar la propiedad del espacio de nombres de DNS del proyecto de servicio de la propiedad del espacio de nombres de DNS de toda la red de VPC.

    En la siguiente figura se muestra una configuración típica de VPC compartida con peering de DNS.

    Una configuración de VPC compartida con emparejamiento de DNS.
    Configuración de VPC compartida con emparejamiento de DNS (haz clic para ampliar)

    En la siguiente figura se muestra una configuración que usa la vinculación entre proyectos. Cloud DNS permite que cada proyecto de servicio cree y sea propietario de sus zonas DNS, pero que siga vinculado a la red compartida que posee el proyecto host. Esto permite una mayor autonomía y un límite de permisos más preciso para la administración de zonas DNS.

    Una configuración con enlace entre proyectos.
    Una configuración con vinculación entre proyectos (haz clic en la imagen para ampliarla)

    El enlace entre proyectos ofrece lo siguiente:

    • Los administradores y usuarios de proyectos de servicio pueden crear y gestionar sus propias zonas DNS.
    • No es necesario que crees una red de VPC de marcador de posición.
    • Los administradores del proyecto del host no tienen que gestionar el proyecto de servicio.
    • Los roles de gestión de identidades y accesos se siguen aplicando a nivel de proyecto.
    • Todas las zonas de DNS están asociadas directamente a la red de VPC compartida.
    • La resolución de DNS de cualquier tipo a cualquier tipo está disponible. Cualquier VM de la red de VPC compartida puede resolver las zonas asociadas.
    • No hay límite de saltos transitivos. Puedes gestionarlo con un diseño de centro y radios.

    Para ver instrucciones sobre cómo crear una zona con la vinculación entre proyectos habilitada, consulta el artículo Crear una zona de enlace multiproyecto.

    Zonas de Cloud DNS zonales

    Cloud DNS zonal te permite crear zonas DNS privadas cuyo ámbito se limita a una Trusted Cloud zona. Las zonas de Cloud DNS zonales se crean para GKE cuando eliges un ámbito de clúster.

    El servicio Cloud DNS predeterminado es de carácter global y los nombres de DNS son visibles en todo el mundo dentro de tu red de VPC. Esta configuración expone tu servicio a interrupciones globales. Cloud DNS zonal es un nuevo servicio de Cloud DNS privado que se encuentra en cada Trusted Cloud zona. El dominio de fallo se encuentra en esa zona. Trusted Cloud Las zonas privadas de Cloud DNS zonales no se ven afectadas cuando se producen interrupciones globales. Las interrupciones Trusted Cloud zonales solo afectan a esa zona Trusted Cloud y a las zonas de Cloud DNS de esa Trusted Cloud zona. Ten en cuenta que los recursos creados en un servicio zonal solo son visibles en esa zona. Trusted Cloud

    Para saber cómo configurar una zona de Cloud DNS zonal con permiso de clúster, consulta Configurar una zona de GKE zonal con permiso de clúster.

    Compatibilidad con Cloud DNS zonal

    En la siguiente tabla se enumeran los recursos y las funciones de Cloud DNS que admiten los servicios de Cloud DNS zonales.

    Recurso o función Disponible en Cloud DNS global Disponible en Cloud DNS zonal
    Zonas privadas gestionadas (con ámbito de red o de VPC)
    Zonas privadas gestionadas (con ámbito de GKE)
    Zonas de reenvío1
    Zonas de emparejamiento
    Zonas de búsqueda inversa gestionadas
    Crear cambios o gestionar registros2
    Zonas de Directorio de servicios
    Políticas
    Políticas de respuesta (con ámbito de red)
    Políticas de respuesta (con ámbito de clúster de GKE)
    Reglas de la política de respuesta

    1 Cloud DNS zonal solo admite zonas de reenvío cuyo ámbito sea un clúster de GKE.

    2El controlador de GKE sobrescribe cualquier cambio en los registros cuando se reinicia.

    Facturación de zonas de Cloud DNS zonales

    La facturación de las zonas de Cloud DNS zonales y las políticas de respuesta funciona de la misma forma que la de sus equivalentes globales.

    Siguientes pasos