Descripción general de Cloud DNS

En esta página, se proporciona una descripción general de las características y capacidades de Cloud DNS. Cloud DNS es un servicio de sistema de nombres de dominio (DNS) global, resiliente y de alto rendimiento que publica sus nombres de dominio en el DNS global de una manera rentable.

DNS es una base de datos distribuida y jerárquica que te permite almacenar direcciones IP y otros datos, y buscarlos por nombre. Cloud DNS te permite publicar tus zonas y registros en el DNS sin la carga de administrar tus propios servidores y software DNS.

En Cloud DNS, se ofrecen zonas públicas y zonas de DNS administradas privadas. Una zona pública es visible para la Internet pública, mientras que una zona privada solo es visible desde una o más redes de nube privada virtual (VPC) que especifiques.

Para obtener una lista de terminología de DNS general, consulta Descripción general de DNS.

Para obtener una lista de la terminología clave en la que se basa Cloud DNS, consulta Términos clave.

Para comenzar a utilizar Cloud DNS, consulta la Guía de inicio rápido.

Pruébalo tú mismo

Si es la primera vez que usas Google Cloud, crea una cuenta para evaluar el rendimiento de Cloud DNS en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Probar Cloud DNS gratis

Consideraciones de VPC compartida

Para usar una zona privada administrada por Cloud DNS, una zona de reenvío de Cloud DNS o una zona de intercambio de tráfico de Cloud DNS con VPC compartida, debes crear la zona en el proyecto host. Luego, agrega una o más redes de VPC compartida a la lista de redes autorizadas para esa zona.

Si deseas obtener más información, consulta Prácticas recomendadas para las zonas privadas de Cloud DNS.

Métodos de reenvío de DNS

En Google Cloud, se ofrece el reenvío de DNS entrante y saliente para zonas privadas. Para configurar el reenvío de DNS, crea una zona de reenvío o una política de servidor de Cloud DNS. Los dos métodos se resumen en la siguiente tabla:

Reenvío de DNS Métodos de Cloud DNS
Entrante

Crea una política de servidor de entrada para permitir que un cliente o servidor DNS local envíe solicitudes de DNS a Cloud DNS. Luego, con el cliente o servidor DNS, se pueden resolver registros de acuerdo con el orden de resolución de nombres de una red de VPC.

Los clientes locales pueden resolver registros en zonas privadas, zonas de reenvío y zonas de intercambio de tráfico en las que se autorizó la red de VPC. Los clientes locales usan Cloud VPN o Cloud Interconnect para conectarse a la red de VPC.

Saliente

Puedes configurar las VM en una red de VPC para hacer lo siguiente:

  • Envía solicitudes de DNS a los servidores de nombres DNS que elijas. Los servidores de nombres pueden estar ubicados en la misma red de VPC, en una red local o en Internet.
  • Resolver registros alojados en servidores de nombres configurados como destinos de reenvío de una zona de reenvío autorizada para su uso mediante tu red de VPC. Para obtener información sobre cómo Google Cloud enruta el tráfico a la dirección IP de un destino de reenvío, consulta Objetivos de reenvío y métodos de enrutamiento.
  • Crea una política de servidor de salida para la red de VPC a fin de enviar todas las solicitudes de DNS en un servidor de nombres alternativo. Cuando usas un servidor de nombres alternativo, en las VM de tu red de VPC ya no se pueden resolver los registros de las zonas privadas de Cloud DNS, las zonas de reenvío, las zonas de intercambio de tráfico o las zonas de DNS internas de Compute Engine. Para obtener más detalles, consulta Orden de resolución de nombres.

Puedes configurar el reenvío entrante y saliente de DNS de forma simultánea para una red de VPC. Con el reenvío bidireccional, se pueden resolver los registros de una red local o una red alojada mediante un proveedor de servicios en la nube diferente con las VM de tu red de VPC. Con este tipo de reenvío, también se permite la resolución de los registros para tus recursos de Google Cloud con los hosts de la red local.

En el plano de control de Cloud DNS, se usa el orden de selección de destino de reenvío para seleccionar un destino de reenvío. Las consultas de reenvío de salida a veces pueden generar errores SERVFAIL si no se puede acceder a los destinos de reenvío o si no responden lo suficientemente rápido. Para obtener instrucciones sobre la solución de problemas, consulta Las consultas de reenvío de salida reciben errores SERVFAIL.

Si deseas obtener información para aplicar las políticas de servidor, consulta Crea políticas de servidor DNS. Si deseas obtener más información para crear una zona de reenvío, consulta Crea una zona de reenvío.

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.

Tipos de registros DNS compatibles

Cloud DNS admite los siguientes tipos de registros:

Tipo de registro Descripción
A

Registro de dirección, que asigna nombres de host a su dirección IPv4.

AAAA

Registro de dirección IPv6, que asigna nombres de host a su dirección IPv6.

CAA

Autorización de autoridad certificada (CA), que especifica qué CA pueden crear certificados para un dominio.

CNAME

Registro de nombre canónico, que especifica nombres de alias.

Si tienes problemas cuando creas un registro CNAME, consulta El registro CNAME definido en una zona privada no funciona.

DNSKEY

La clave de DNSSEC de otro operador para la transferencia segura. Este tipo de conjunto de registros solo se puede agregar a una zona que tenga habilitado DNSSEC en el estado de transferencia

DS

La huella digital de la clave de DNSSEC para la zona delegada segura. Este tipo de conjunto de registros no activa DNSSEC para una zona delegada, a menos que habilites (y actives) DNSSEC para ella.

IPSECKEY

Datos de puerta de enlace de túnel IPsec y claves públicas para clientes compatibles con IPsec que habilitan la encriptación oportunista.

MX

Registro de intercambio de correo electrónico, que dirige las solicitudes a los servidores de correo electrónico.

NAPTR

Registro de puntero de autoridad encargada de la asignación de nombres, definida por la RFC 3403

NS

Registro de servidor de nombres, que delega una zona de DNS a un servidor autorizado.

PTR

Registro de indicador, que suele utilizarse para búsquedas de DNS inversas.

SOA

Registro de inicio de autoridad, que especifica información autorizada sobre una zona de DNS. Cuando creas tu zona administrada, se crea un registro de recurso SOA para ti. Puedes modificar el registro según sea necesario (por ejemplo, puedes cambiar el número de serie a un número arbitrario para admitir el control de versiones basado en fechas).

SPF

Registro de Sender Policy Framework, un tipo de registro obsoleto que se utilizaba en los sistemas de validación de correo electrónico (usa un registro TXT en su lugar).

SRV

Registro de localizador de servicio, que utilizan algunos protocolos de mensajería instantánea de voz sobre IP (VoIP) y otras aplicaciones.

SSHFP

Huella digital de SSH para clientes SSH destinada a validar las claves públicas de los servidores SSH.

TLSA

Registro de autenticación de TLS para clientes TLS destinado a validar los certificados del servidor X.509

TXT

Registro de texto, que puede contener texto arbitrario y que también se puede utilizar para definir datos procesables, como información sobre seguridad o prevención de abusos.

Un registro TXT puede contener una o más strings de texto; la longitud máxima de cada string individual es de 255 caracteres. Los agentes de correo y otros agentes de software concatenan varias strings. Encierra cada string entre comillas.

Para trabajar con registros DNS, consulta Administra registros.

Registros DNS comodín

Los registros comodín son compatibles con todos los tipos de registros, excepto los registros NS.

DNSSEC

Cloud DNS admite DNSSEC administradas, que protegen tus dominios contra la falsificación de identidad y los ataques de envenenamiento de caché. Cuando usas un agente de resolución de validación como DNS público de Google, DNSSEC proporciona una autenticación sólida (pero no la encriptación) de las búsquedas de dominio. Para obtener más información sobre DNSSEC, consulta Administra la configuración de DNSSEC.

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

En Cloud DNS, se admiten tres tipos de destinos y se ofrecen métodos estándar o privados para enrutar el tráfico hacia ellos.

Destino de reenvío Descripción Compatible con el enrutamiento estándar Compatible con el enrutamiento privado Fuente de las solicitudes
Tipo 1 Es una dirección IP interna de una VM de Google Cloud en la misma red de VPC que está autorizada 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, incluidas las direcciones IP privadas que no sean RFC 1918 y las direcciones IP públicas reutilizadas de forma privada: el tráfico siempre se enruta a través de una red de VPC autorizada. 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, incluidas las direcciones IP privadas que no sean RFC 1918 y las direcciones IP públicas reutilizadas de forma privada: 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.

Orden de selección de destino de reenvío

Cloud DNS te permite configurar una lista de servidores de nombres alternativos para una política de servidor saliente y una lista de destinos de reenvío para una zona de reenvío.

En caso de varios 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. Puedes autorizar el uso de la zona de reenvío a partir de varias redes de VPC en el mismo proyecto.
  • 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 para 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.

Intercambio de tráfico de DNS

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.

Si quieres usar el intercambio de tráfico de DNS, debes autorizar a una red con la cual se use una zona de intercambio de tráfico. La red de VPC 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 crear una zona de intercambio de tráfico, debes contar con la función de IAM par de DNS en el proyecto que contiene la red del productor de DNS.

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 otra 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
foo.gcp.example.com A 5 10.128.1.35

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

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

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

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

Control de acceso

Puedes administrar los usuarios que tienen permiso para realizar cambios en tus registros DNS en la página de IAM y administración en Google Cloud Console. Para que los usuarios estén autorizados a realizar cambios, deben tener la función de editor (roles/editor) o la función Propietario (roles/owner) en la sección Permisos de Cloud Console. La función de visualizador (roles/viewer) otorga acceso de solo lectura a los registros de Cloud DNS.

Estos permisos también se aplican a las cuentas de servicios que puedes usar para administrar tus servicios del DNS.

Control de acceso para zonas administradas

Los usuarios que poseen las funciones propietario o editor de proyecto pueden administrar o ver las zonas administradas en el proyecto específico que están administrando.

Los usuarios con las funciones administrador o lector de DNS (roles/dns.admin o roles/dns.reader) pueden administrar o ver las zonas administradas de todos los proyectos a los que tienen acceso.

Los propietarios de proyectos, los editores, los administradores del DNS y los lectores de DNS pueden ver la lista de zonas privadas aplicadas a cualquier red de VPC en el proyecto actual.

Rendimiento y tiempos

Cloud DNS usa Anycast a fin de entregar tus zonas administradas desde diferentes ubicaciones en todo el mundo para una alta disponibilidad. Las solicitudes se enrutan automáticamente a la ubicación más cercana, lo que reduce la latencia y mejora el rendimiento de las búsquedas de nombres autorizadas para tus usuarios.

Propagación de cambios

Los cambios se propagan en dos partes. En primer lugar, el cambio que envías a través de la API o la herramienta de línea de comandos se debe enviar a los servidores de nombres autorizados de Cloud DNS. Segundo, los agentes de resolución del DNS deben recoger este cambio cuando su caché de registros vence.

El valor de tiempo de actividad (TTL) que estableces para tus registros, que se especifica en segundos, controla la caché del agente de resolución del DNS. Por ejemplo, si configuras un valor de TTL de 86,400 (la cantidad de segundos en 24 horas), los agentes de resolución del DNS reciben la instrucción de almacenar en caché los registros de 24 horas. Algunos agentes de resolución del DNS ignoran el valor de TTL o usan sus propios valores, lo que puede demorar la propagación total de los registros.

Si estás planeando el cambio a los servicios que requieren un período más corto, es posible que desees cambiar el TTL por un valor menor antes de hacer el cambio. Este enfoque puede ayudar a reducir el período de almacenamiento en caché y garantizar un cambio más rápido en tu nueva configuración de registro. Después del cambio, puedes volver a cambiar el valor por el valor de TTL anterior a fin de reducir la carga en los agentes de resolución del DNS.

¿Qué sigue?