Descripción general de las zonas DNS

Cloud DNS admite diferentes tipos de zonas públicas y privadas. En esta página, se proporcionan detalles sobre los diferentes tipos de zona y cuándo puedes usar cada uno.

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. El uso de 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 dentro de la zona, debes especificar un conjunto de destinos de reenvío. Cada destino de reenvío es una dirección IP de un servidor DNS, ubicada 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 tres tipos de destinos y ofrece métodos de enrutamiento estándar o privados para la conectividad.

Destino de reenvío Descripción Compatible con el enrutamiento estándar Compatible con el enrutamiento privado Fuente de las solicitudes
Tipo 1 Una dirección IP interna de un una VM de Google Cloud o una balanceador de cargas de red de transferencia interno del misma red de VPC que está autorizada para usar la red de zona. 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 que no sea RFC de 1918 o una dirección IP externa reutilizada de forma privada, excepto para una dirección IP de destino de reenvío prohibida es decir, el tráfico siempre se enruta a través de una VPC autorizada en cada red. 35.199.192.0/19
Tipo 2 Una dirección IP de un sistema local, conectada 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. 35.199.192.0/19
Tipo 3 Es una dirección IP externa de un servidor de nombres de DNS accesible a Internet o la dirección IP externa de un recurso de Google Cloud, por ejemplo, la dirección IP externa de una VM en otra red de VPC. Solo direcciones IP externas enrutables de Internet: el tráfico siempre se enruta a Internet o a la dirección IP externa de un recurso de Google Cloud. El enrutamiento privado no es compatible; asegúrate de que no se seleccione el enrutamiento privado. Rangos de origen de DNS público de Google

Cuando agregues el destino de reenvío a la zona de reenvío, puedes elegir uno de los siguientes dos métodos de enrutamiento:

  • Enrutamiento estándar: Se enruta el tráfico a través de una red de VPC autorizada o a través de 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 un objetivo de Tipo 1 o 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 clasifica el objetivo como de Tipo 3 y espera a que se pueda acceder al objetivo 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). En consecuencia, solo se admiten los destinos Tipo 1 y Tipo 2.

Para acceder a un destino de reenvío de Tipo 1 o Tipo 2, Cloud DNS usa rutas que se encuentran en la red de VPC autorizada, en la que está el cliente de DNS. En estas rutas, se define una ruta de acceso segura al destino de reenvío:

Para obtener orientación adicional sobre los requisitos de red para los destinos de Tipo 1 y Tipo 2, consulta los requisitos de red de destino de reenvío.

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 un destino de reenvío. Este algoritmo clasifica cada destino de reenvío.

Para procesar una solicitud, Cloud DNS primero intenta realizar una consulta de DNS comunicándose 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 que tenga la mejor clasificación. 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 la cantidad de respuestas DNS exitosas que procesa el destino de reenvío. Entre las respuestas DNS exitosas, se incluyen las respuestas NXDOMAIN.
  • Cuanto menor sea la latencia (tiempo de ida y vuelta) para comunicarse con el destino de reenvío.

Usa zonas de reenvío

En las VM de una red de VPC, se puede usar una zona de reenvío de Cloud DNS en los siguientes casos:

  • Se autorizó el uso de la zona de reenvío de Cloud DNS mediante la red de VPC. Para usar la zona de reenvío, puedes autorizar varias redes de VPC en el mismo proyecto o en varios proyectos, siempre y cuando las redes de VPC estén dentro de la misma organización.

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

Zonas de reenvío superpuestas

Debido a que las zonas de reenvío de Cloud DNS son un tipo de zona privada administrada de Cloud DNS, puedes crear varias zonas que se superpongan. Con las VM configuradas como se describió anteriormente, se resuelve un registro de acuerdo con el orden de resolución de nombres, mediante el uso de la zona con el sufijo más largo. Para obtener más información, consulta Zonas superpuestas.

Zonas de reenvío y almacenamiento en caché

En Cloud DNS, se almacenan en caché las respuestas para las consultas enviadas a las zonas de reenvío de Cloud DNS. En Cloud DNS, se mantiene una caché de respuestas de destinos de reenvío accesibles para el más corto de los siguientes intervalos de tiempo:

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

Cuando todos los destinos de reenvío de una zona de reenvío se vuelven inaccesibles, en la caché de Cloud DNS, se mantienen los registros solicitados anteriormente en esa zona durante el TTL de cada registro.

Cuándo usar el intercambio de tráfico

Cloud DNS no puede usar enrutamiento transitivo para conectarse a un destino de reenvío. Para ilustrar una configuración no válida, considera la siguiente situación:

  • Usaste Cloud VPN o Cloud Interconnect para conectar una red local a una red de VPC llamada vpc-net-a.

  • Usaste el intercambio de tráfico entre redes de VPC para conectar la red de VPC vpc-net-a a vpc-net-b. Configuraste vpc-net-a a fin de exportar rutas personalizadas y vpc-net-b para importarlas.

  • Creaste una zona de reenvío cuyos destinos de reenvío se encuentran en la red local a la que se conectó vpc-net-a. Autorizaste a vpc-net-b para usar esa zona de reenvío.

La resolución de un registro en una zona que recibe entregas de los destinos de reenvío falla en esta situación, aunque haya conectividad de vpc-net-b a tu red local. Para demostrar este error, realiza las siguientes pruebas desde una VM en 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 se esperaba) porque Cloud DNS no es compatible con el enrutamiento transitivo a los destinos de reenvío. Si quieres usar una zona de reenvío, una VM debe estar configurada para usar su servidor de metadatos.

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

Puedes usar una zona de intercambio de tráfico de Cloud DNS para corregir esta situación no válida:

  1. Crea una zona de intercambio de tráfico de Cloud DNS autorizada para vpc-net-b que se dirija 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.

Sigue estos pasos en el orden que desees. Después de completarlos, se pueden realizar consultas en los destinos de reenvío locales con las instancias de Compute Engine en vpc-net-a y vpc-net-b.

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

Zonas de intercambio de tráfico

Con el intercambio de tráfico de DNS, puedes enviar consultas de los registros que provienen del espacio de nombres de una zona a otra red de VPC. Por ejemplo, mediante un proveedor de SaaS, se puede otorgar a un cliente de SaaS acceso a los registros DNS que en este último se administran.

Si quieres proporcionar intercambio de tráfico de DNS, debes crear una zona de intercambio de tráfico de Cloud DNS y configurarla para realizar 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 intercambio de tráfico de DNS se realizan las búsquedas se denomina red del productor de DNS.

La zona de intercambio de tráfico solo es visible para las redes de VPC que se seleccionan durante la configuración de la zona. La red de VPC que está autorizada para usar la zona de intercambio de tráfico se denomina red del consumidor del DNS.

Después de autorizar los recursos de Google Cloud en la red del consumidor del DNS, pueden realizar búsquedas de los registros en el espacio de nombres de la zona de intercambio de tráfico, como si se encontraran en la red del productor del DNS. Para las búsquedas de registros en el espacio de nombres de la zona de intercambio de tráfico, se sigue el orden de resolución de nombres de la red del productor de DNS.

Por lo tanto, los recursos de Google Cloud en la red del consumidor del DNS pueden buscar registros en el espacio de nombres de la zona desde las siguientes fuentes disponibles en la red del productor del DNS:

  • Zonas privadas y administradas de Cloud DNS que la red del productor del DNS tiene autorización para usar
  • Zonas de reenvío administradas de Cloud DNS que la red del productor del DNS tiene autorización para usar
  • Nombres de DNS internos de Compute Engine en la red del productor del DNS
  • Un servidor de nombres alternativo, si se configuró una política de DNS saliente en la red del productor del DNS

Limitaciones y puntos clave de intercambio de tráfico de DNS

Recuerda lo siguiente cuando configures el intercambio de tráfico del DNS:

  • El intercambio de tráfico del DNS es una relación unidireccional. A partir de los recursos de Google Cloud en la red del consumidor de DNS, se pueden buscar registros en el espacio de nombres de la zona de intercambio de tráfico como si los recursos de Google Cloud estuvieran en la red del productor de DNS.
  • Las redes de consumidores y productores de DNS deben ser redes de VPC.
  • Si bien, por lo general, las redes del consumidor y del productor del DNS forman parte de la misma organización, el intercambio de tráfico DNS entre organizaciones también es compatible.
  • Los servicios de intercambio de tráfico del DNS y de intercambio de tráfico entre redes de VPC son distintos. El primero se puede usar con el segundo. Sin embargo, el segundo no es obligatorio para el primero.
  • Se admite el intercambio de tráfico transitivo de DNS, pero únicamente a través de un solo salto transitivo. En otras palabras, no pueden participar más de tres redes de VPC (con la red del medio como salto transitivo). Por ejemplo, puedes crear una zona de intercambio de tráfico en vpc-net-a que se oriente a vpc-net-b y, luego, crear una zona de intercambio de tráfico en vpc-net-b que se oriente a vpc-net-c.
  • Si usas el intercambio de tráfico de DNS para orientar una zona de reenvío, la red de VPC de destino con la zona de reenvío debe contener una VM, un adjunto 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 intercambio de tráfico de DNS. Para obtener información sobre esta limitación, consulta Reenvío de consultas de VM en una red de VPC de consumidor a una red de VPC de productor que no funciona.

Si quieres obtener instrucciones para crear una zona de intercambio de tráfico, consulta Crea una zona de intercambio de tráfico.

Zonas de búsqueda inversa administradas

Una zona de búsqueda inversa administrada es una zona privada con un atributo especial que le indica a Cloud DNS que realice una búsqueda PTR en los datos de DNS de Compute Engine.

Registros PTR para direcciones RFC 1918 en zonas privadas

A fin de realizar búsquedas inversas con registros PTR personalizados para direcciones RFC 1918, debes crear una zona privada de Cloud DNS que sea, al menos, tan específica como una de las siguientes zonas de ejemplo. Esta es una consecuencia de la coincidencia con el sufijo más largo descrita en Orden de resolución de nombres.

Las zonas de ejemplo incluyen lo siguiente:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., … hasta 31.172.in-addr.arpa.

Si creas una zona privada de Cloud DNS para las direcciones RFC 1918, los registros PTR que creas para las VM en esa zona las anula los registros PTR que el DNS interno crea automáticamente. Esto se debe a que los registros PTR de DNS interno se crean en la lista anterior de zonas más específicas.

Por ejemplo, supongamos que creas una zona privada administrada destinada a in-addr.arpa. con el siguiente registro PTR para una VM cuya dirección IP es 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

Las consultas de PTR para 1.1.1.10.in-addr.arpa. se responden con la zona DNS interna más específica de 10.in-addr.arpa.. El registro PTR en tu zona privada de Cloud DNS para test.example.domain se ignora.

A fin de anular los registros PTR de DNS interno creados automáticamente para las VM, asegúrate de crear tus registros PTR personalizados en una zona privada que sea al menos tan específica como una de las zonas presentadas en esta sección. Por ejemplo, si creas el siguiente registro PTR en una zona privada para 10.in-addr.arpa., tu registro anula el que se generó automáticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain.

Si solo necesitas anular una parte de un bloque de red, puedes crear zonas privadas de Cloud DNS inversa más específicas. Por ejemplo, se puede usar una zona privada para 5.10.in-addr.arpa. a fin de conservar los registros PTR que anulan cualquier registro PTR de DNS interno que se crean automáticamente para VM con direcciones IP en la dirección 10.5.0.0/16.

Para obtener instrucciones sobre cómo crear una zona de búsqueda inversa administrada, consulta Crea una zona de búsqueda inversa administrada.

Zonas superpuestas

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

  • Una zona de gcp.example.com y otra de 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 superponen porque dev.gcp.example.com es un subdominio de gcp.example.com.

Reglas para zonas superpuestas

En Cloud DNS, se aplican las siguientes reglas para las zonas superpuestas:

  • Las zonas públicas superpuestas no están permitidas en los mismos servidores de nombres de Cloud DNS. Cuando creas zonas superpuestas, Cloud DNS intenta colocarlas en servidores de nombres diferentes. Si eso no es posible, no se podrá crear la zona superpuesta en Cloud DNS.

  • Una zona privada puede superponerse con cualquier zona pública.

  • Las zonas privadas con un alcance para redes de VPC diferentes pueden superponerse entre sí. Por ejemplo, cada una de dos redes de VPC puede tener una VM de base de datos con el nombre database.gcp.example.com en una zona gcp.example.com. En las consultas para database.gcp.example.com, se reciben respuestas diferentes según los registros de zona definidos en la zona autorizada de cada red de VPC.

  • Dos zonas privadas que han sido autorizadas para ser accesibles 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 en qué origen consultar registros en una zona determinada.

Ejemplos de resolución de consultas

En Google Cloud, se resuelven las zonas de Cloud DNS como se describe en Orden de resolución de nombres. Cuando se determina la zona para consultar en un registro determinado, se intenta encontrar una zona que coincida lo más posible con el registro solicitado (coincidencia con el sufijo más largo) en Cloud DNS.

A menos que hayas especificado un servidor de nombres alternativo en una política del servidor saliente, en Google Cloud, primero se intenta encontrar un registro en una zona privada (o zona de reenvío o zona de intercambio de tráfico) autorizada para tu red de VPC, antes de buscarlo en una zona pública.

Los siguientes ejemplos muestran el orden que utiliza el servidor de metadatos cuando realiza consultas en los registros DNS. Para cada uno de estos ejemplos, supongamos que creaste dos zonas privadas, gcp.example.com y dev.gcp.example.com, y autorizaste el acceso a ellas desde la misma red de VPC. En Google Cloud, se manejan las consultas de DNS de las VM en una red de VPC de la siguiente manera:

  • El servidor de metadatos usa servidores de nombres públicos a fin de resolver un registro de myapp.example.com. (ten en cuenta el punto final) porque no hay una zona privada para example.com que esté autorizada para la red de VPC. Usa dig de una VM de Compute Engine para consultar el servidor de nombres predeterminado de la VM como sigue:

    dig myapp.example.com.

    Para obtener más detalles, revisa Consulta el nombre del DNS con el servidor de metadatos.

  • Mediante el servidor de metadatos, se resuelve el registro myapp.gcp.example.com con la zona privada autorizada gcp.example.com porque gcp.example.com es el sufijo común más largo entre el nombre de registro solicitado y las zonas privadas autorizadas disponibles. Si no hay ningún registro para myapp.gcp.example.com definido en la zona privada gcp.example.com, se muestra NXDOMAIN, incluso si hay un registro de myapp.gcp.example.com definido en una zona pública.

  • Del mismo modo, las consultas para myapp.dev.gcp.example.com se resuelven según los registros de la zona privada autorizada dev.gcp.example.com. Si no hay ningún registro para myapp.dev.gcp.example.com en la zona dev.gcp.example.com, se muestra NXDOMAIN, incluso si hay un registro de myapp.dev.gcp.example.com en otra zona privada o pública.

  • Las consultas para myapp.prod.gcp.example.com se resuelven de acuerdo con los registros de la zona privada gcp.example.com, porque gcp.example.com es el sufijo común más largo entre el registro DNS solicitado y las zonas privadas disponibles.

Ejemplo de DNS de horizonte dividido

Puedes usar una combinación de zonas públicas y privadas en una configuración de DNS de horizonte dividido. En las zonas privadas, puedes definir diferentes respuestas a una consulta para el mismo registro cuando la consulta se origina en una VM dentro de una red de VPC autorizada. El DNS de horizonte dividido es útil cuando necesitas proporcionar registros diferentes para las mismas consultas de DNS según la red de VPC de origen.

Considera el siguiente ejemplo de horizonte dividido:

  • Creaste una zona pública, gcp.example.com, y configuraste su registrador para usar servidores de nombres de Cloud DNS.
  • Creaste una zona privada, gcp.example.com, y autorizaste a tu red de VPC a acceder a ella.

En la zona privada, creaste un solo registro como se muestra en la siguiente tabla.

Registro Tipo TTL (segundos) Datos
myrecord1.gcp.example.com A 5 10.128.1.35

En la zona pública, creaste los siguientes dos registros:

Registro Tipo TTL (segundos) Datos
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

Las siguientes consultas se resuelven como se describe a continuación:

  • Una consulta para myrecord1.gcp.example.com desde una VM de tu red de VPC muestra 10.128.1.35.
  • Una consulta para myrecord1.gcp.example.com desde Internet muestra 104.198.6.142.
  • Una consulta para myrecord2.gcp.example.com de una VM de tu red de VPC muestra un error NXDOMAIN, porque no hay ningún registro para myrecord2.gcp.example.com en la zona privada gcp.example.com.
  • Una consulta para myrecord2.gcp.example.com desde Internet muestra 104.198.7.145.

Vinculación entre proyectos

La vinculación entre proyectos te permiten 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.

Una configuración de VPC compartida típica tiene proyectos de servicio que toman la propiedad de una aplicación o servicios de máquina virtual (VM), mientras que el proyecto host toma la propiedad de la red de VPC y la infraestructura de red. A menudo, se crea un espacio de nombres de DNS a partir del espacio de nombres de la red de VPC para que coincida con los recursos del proyecto de servicio. Para esta configuración, puede ser más fácil delegar la administración del espacio de nombres DNS de cada proyecto de servicio a los administradores de cada proyecto de servicio (que suelen ser departamentos o empresas diferentes). La vinculación 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 intercambio de tráfico de DNS.

Una configuración de VPC compartida con intercambio de tráfico de DNS.
Una configuración de VPC compartida con intercambio de tráfico de DNS (haz clic para ampliar)

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

Una configuración con vinculación entre proyectos.
Una configuración con vinculación entre proyectos (haz clic para ampliar)

La vinculación entre proyectos proporciona lo siguiente:

  • Los administradores y usuarios del proyecto de servicio pueden crear y administrar sus propias zonas de DNS.
  • No es necesario crear una red de VPC con marcador de posición.
  • Los administradores del proyecto host no tienen que administrar el proyecto de servicio.
  • Las funciones de IAM aún se aplican a nivel de proyecto.
  • Todas las zonas de DNS están asociadas directamente con la red de VPC compartida.
  • La resolución de cualquier tipo puede ser cualquier DNS. Cualquier VM en la red de VPC compartida puede resolver las zonas asociadas.
  • No hay límite de salto transitivo. Puedes administrarlo en un diseño de concentrador y radio.

Si quieres obtener instrucciones para crear una zona con vinculación de proyectos cruzados habilitada, consulta Crea una zona de vinculación entre proyectos.

Zonas de Cloud DNS zonal

Cloud DNS zonal te permite crear zonas DNS privadas con alcance solo para una zona de Google Cloud. Las zonas de Cloud DNS zonal se crean para GKE cuando eliges un permiso de clúster.

El servicio predeterminado de Cloud DNS es global y los nombres de DNS son visibles de forma global dentro de tu red de VPC. Esta configuración expone tu servicio a interrupciones globales. Cloud DNS zonal es un nuevo servicio privado de Cloud DNS que existe dentro de cada zona de Google Cloud. El dominio con fallas se encuentra dentro de esa zona de Google Cloud. Las zonas privadas de Cloud DNS zonales no se ven afectadas cuando se producen interrupciones globales. Cualquier interrupción zonal de Google Cloud solo afecta a esa zona específica y a las zonas de Cloud DNS dentro de esa zona de Google Cloud. Ten en cuenta que cualquier recurso creado en un servicio zonal solo es visible para esa zona de Google Cloud.

Para aprender a configurar una zona con permiso de clúster de Cloud DNS zonal, consulta Configura una zona con permiso de clúster de GKE zonal.

Compatibilidad con Cloud DNS zonal

En la siguiente tabla, se enumeran los recursos y las funciones de Cloud DNS que se y son compatibles con los servicios zonales de Cloud DNS.

Recurso o función Disponible en Cloud DNS global Disponible en Cloud DNS zonal
Zonas públicas administradas
Zonas privadas administradas (con alcance de VPC o red)
Zonas privadas administradas (con alcance de GKE)
Zonas de reenvío1
Zonas de intercambio de tráfico
Zonas de búsqueda inversa administradas
Crear cambios o administrar registros2
Zonas del Directorio de servicios
Políticas
Políticas de respuesta (con alcance de red)
Políticas de respuesta (con alcance de clúster de GKE)
Reglas de política de respuesta

1Cloud DNS zonal solo admite zonas de reenvío con alcance a un clúster de GKE.

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

Facturación para las zonas de Cloud DNS zonal

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

¿Qué sigue?