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. Para comenzar a utilizar Cloud DNS, consulta la Guía de inicio rápido.

Introducción

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.

Conceptos

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 VPC especificadas.

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.

Consideraciones de VPC compartida

Para usar una zona privada administrada de Cloud DNS, una zona de reenvío de Cloud DNS o una zona de intercambio de tráfico de Cloud DNS con una VPC compartida, debes crear la zona en el proyecto host y, luego, agregar las redes de VPC compartidas adecuadas 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.

Orden de resolución de nombres de VPC

Con cada red de VPC, se proporcionan servicios de resolución de nombres de DNS a las instancias de máquina virtual (VM) que los usan. Cuando en las VM se usa el servidor de metadatos, 169.254.169.254, como el servidor de nombres, en Google Cloud, los registros DNS se buscan de acuerdo con el siguiente orden:

  • Si en tu red de VPC existe una política del servidor saliente, se reenvían todas las consultas de DNS a esos servidores alternativos con Google Cloud. Este es el único paso del orden de resolución de nombres de VPC.

  • Si tu red de VPC no tiene una política del servidor saliente, sucede lo siguiente:

    1. En Google Cloud, se intenta encontrar una zona privada que coincida lo más posible con el registro solicitado (coincidencia con el sufijo más largo). Esto incluye lo siguiente:
      • Buscar registros que creaste en zonas privadas
      • Consultar los destinos de reenvío de las zonas de reenvío
      • Consultar el orden de resolución de nombres de otra red de VPC mediante zonas de intercambio de tráfico
    2. Google Cloud busca los registros DNS internos de Compute Engine creados automáticamente para el proyecto.
    3. Google Cloud realiza consultas a las zonas disponibles públicamente, de acuerdo con el registro de inicio de autoridad (SOA) correctamente configurado. Esto incluye las zonas públicas 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.

  • El reenvío entrante consiste en la habilitación de un cliente o servidor DNS local para enviar solicitudes 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. Mediante el reenvío entrante, se permite la resolución de registros en zonas privadas, zonas de reenvío y zonas de intercambio de tráfico de los clientes locales para las que se autorizó la red de VPC. La conexión de los clientes locales a la red de VPC se realiza con Cloud VPN o Cloud Interconnect.

  • El reenvío saliente consiste en la habilitación de las VM en Google Cloud para enviar solicitudes de DNS a los servidores de nombres de DNS que elijas. Los servidores de nombres pueden estar ubicados en la misma red de VPC, en una red local o en Internet.

Para configurar el reenvío de DNS, crea una zona de reenvío o una política del servidor de Cloud DNS. Los dos métodos se resumen en la siguiente tabla:

Reenvío Métodos de Cloud DNS
Entrante Con los sistemas locales, se pueden enviar solicitudes a una red de VPC para usar el orden de resolución de nombres de VPC de esa red si creas una política del servidor entrante para esa red.
Saliente Puedes configurar varias VM en una red de VPC para hacer lo siguiente:
  • 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 importante sobre cómo Google Cloud enruta el tráfico a la dirección IP de un destino de reenvío, consulta Destinos de reenvío y métodos de enrutamiento
  • Enviar a todas las solicitudes de DNS un servidor de nombres alternativo mediante la creación de una política del servidor saliente para la red de VPC. 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 o las zonas de intercambio de tráfico. Revisa cuidadosamente la sección Orden de resolución de nombres de VPC para obtener detalles adicionales

Puedes configurar el reenvío entrante y saliente 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 un algoritmo para determinar la capacidad de respuesta de un destino de reenvío. Es posible que, a veces, se generen errores SERVFAIL en tus consultas reenviadas salientes. Para obtener información sobre cómo solucionar este problema, consulta la sección relacionada en la documentación de Soluciona problemas.

Registros PTR en zonas privadas

Registros PTR para direcciones RFC 1918

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 de VPC.

  • 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 destinada a las direcciones RFC 1918, los registros PTR personalizados que crees para las VM en esa zona se anularán mediante los registros PTR que se cree automáticamente en el DNS interno de Compute Engine. Esto se debe a que los registros PTR del DNS interno de Compute Engine se crean en la lista previa 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 de Compute Engine 10.in-addr.arpa. más específica. El registro PTR en tu zona privada de Cloud DNS para test.example.domain se ignora.

A fin de anular los registros PTR del DNS interno de Compute Engine creados automáticamente para 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

También puedes crear zonas privadas de Cloud DNS reversas más específicas si solo necesitas anular una parte de un bloqueo de red. Por ejemplo, una zona privada para 5.10.in-addr.arpa. puede contener registros PTR con los que se anula cualquier registro PTR del DNS interno de Compute Engine que se cree automáticamente para las VM con direcciones IP en el rango de direcciones 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.
Cloud DNS no admite la resolución recursiva de CNAME en diferentes zonas privadas administradas (rastreo de CNAME). Para obtener detalles, consulta Soluciona problemas.

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 indicador 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 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. El siguiente es un ejemplo:


"Hello world" "Bye world"

En Administra registros, se muestra el modo de trabajar con los registros DNS.

Registros DNS comodín

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

DNSSEC

En Cloud DNS, se admite DNSSEC administrada para proteger 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 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

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 Enrutamiento estándar Enrutamiento privado Origen 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 Deben ser direcciones IP RFC 1918: tráfico siempre enrutado a través de una red de VPC autorizada Cualquier dirección IP interna: tráfico siempre enrutado 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 Deben ser direcciones IP RFC 1918: tráfico siempre enrutado a través de una red de VPC autorizada Cualquier dirección IP interna: tráfico siempre enrutado 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 en Internet.
Incluye una dirección IP externa de un recurso de Google Cloud.
Debe ser una dirección enrutable por Internet: tráfico siempre enrutado a Internet No se admite el enrutamiento privado Rangos de origen del 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 se encuentra 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.

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 SO 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 de VPC, 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

En Cloud DNS, no se puede establecer la conexión a un destino de reenvío mediante el enrutamiento transitivo. Para ilustrar una configuración no válida, considera la siguiente situación:

  • Conectaste una red local a una red de VPC llamada vpc-net-a mediante Cloud VPN o Cloud Interconnect.

  • Conectaste la red de VPC vpc-net-a a vpc-net-b mediante el intercambio de tráfico entre redes de VPC. 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. Una VM debe estar configurada para usar su servidor de metadatos a fin de emplear una zona de reenvío.
  • Consulta el destino de reenvío directamente para ver ese mismo registro. En esta consulta, se demuestra que la conectividad transitiva funciona correctamente, aunque no se use esta ruta en Cloud DNS.

Puedes corregir esta situación no válida con una zona de intercambio de tráfico de Cloud DNS con los siguientes pasos:

  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.

Cuando se otorga la autorización, con los recursos de Google Cloud de la red del consumidor de DNS, se 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 de 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, con los recursos de Google Cloud en la red del consumidor de DNS, se pueden buscar registros en el espacio de nombres de la zona desde las siguientes fuentes disponibles en la red del productor de 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 del 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.
  • 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 junto 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 dirija a vpc-net-b y, luego, una zona de intercambio de tráfico en vpc-net-b, que se dirija 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 interconexión (VLAN) o un túnel de Cloud VPN ubicado en la misma ubicación región como VM de origen que usa la zona de intercambio de tráfico de DNS. Para ver los detalles sobre esta limitación, consulta la sección de solución de problemas.

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. Algunos ejemplos son los siguientes:

  • 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. Consulta la siguiente sección para conocer las reglas que se aplican a las zonas superpuestas.

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 utiliza la coincidencia con el 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 de VPC. 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 se utiliza en el servidor de metadatos para realizar 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:

  • En el servidor de metadatos, se usan servidores de nombres públicos a fin de resolver un registro de myapp.example.com porque no hay ninguna zona privada de example.com con autorización para la red de VPC.
  • 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 el siguiente registro único:

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.

Políticas de servidor DNS

Puedes configurar una política del servidor DNS para cada red de VPC. En la política, se pueden especificar el reenvío entrante, el reenvío saliente o ambos. En esta sección, la política del servidor entrante se refiere a una política en la que se permite el reenvío de DNS entrante y la política del servidor saliente se refiere a un método posible para implementar el reenvío de DNS saliente. Es posible que una política sea, simultáneamente, una política del servidor entrante y una política del servidor saliente, si se implementan en ella las funciones de ambas.

Si deseas obtener más información, consulta la sección para aplicar las políticas del servidor.

Política del servidor entrante

En cada red de VPC, se proporcionan servicios de resolución de nombres de DNS a las VM en las que se usan. Cuando en una VM se usa el servidor de metadatos, 169.254.169.254, como el servidor de nombres, se buscan registros DNS según el orden de resolución de nombres de VPC en Google Cloud.

De forma predeterminada, los servicios de resolución de nombres de una red de VPC, a través de su orden de resolución de nombres, solo están disponibles para esa red de VPC. Si deseas que estos servicios de resolución de nombres estén disponibles para una red local conectada mediante Cloud VPN o Cloud Interconnect, crea una política de DNS entrante en tu red de VPC.

Cuando creas una política de entrada, en Cloud DNS, se toma una dirección IP interna del rango de direcciones IP principal de una subred en cada región usada por tu red de VPC. Estas direcciones IP internas se usan como puntos de ingreso para las solicitudes DNS entrantes.

Puntos de ingreso de políticas de entrada

Las direcciones IP internas regionales que se usan en Cloud DNS para la política de DNS entrante sirven como puntos de ingreso a los servicios de resolución de nombres de la red de VPC. Para usar la política de DNS entrante, debes configurar tus sistemas o servidores de nombres locales a fin de reenviar las consultas de DNS a la dirección IP del proxy ubicada en la misma región que el túnel de Cloud VPN o el adjunto de Cloud Interconnect (VLAN) que conecta tu red local a tu red de VPC.

Si deseas obtener información sobre cómo crear políticas del servidor entrante, consulta Crea una política del servidor entrante.

Política del servidor saliente

Para cambiar el orden de resolución de nombres de VPC, crea una política de DNS saliente que especifique una lista de servidores de nombres alternativos. Cuando especificas servidores de nombres alternativos para una red de VPC, esos servidores son los únicos servidores de nombres que se consultan en Google Cloud cuando se manejan las solicitudes DNS de las VM de tu red de VPC que están configuradas para usar sus servidores de metadatos (169.254.169.254).

Si deseas obtener información sobre cómo crear políticas del servidor saliente, consulta Crea una política del servidor saliente.

Servidores de nombres alternativos y métodos de enrutamiento

Cloud DNS es compatible con cuatro tipos de servidores de nombres alternativos y ofrece métodos de enrutamiento estándar y privados para enrutar el tráfico hacia ellos.

Los servidores de nombres alternativos se definen en la siguiente tabla:

Servidor de nombres alternativo Descripción Enrutamiento estándar Enrutamiento privado Origen de las solicitudes
Tipo 1 Es una dirección IP interna de una VM de Google Cloud en la misma red de VPC en la que se define la política del servidor de salida Deben ser direcciones IP RFC 1918: tráfico siempre enrutado a través de una red de VPC autorizada Cualquier dirección IP interna: tráfico siempre enrutado 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 con la política del servidor saliente, mediante Cloud VPN o Cloud Interconnect Deben ser direcciones IP RFC 1918: tráfico siempre enrutado a través de una red de VPC autorizada Cualquier dirección IP interna: tráfico siempre enrutado 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 en Internet.
Incluye una dirección IP externa de un recurso de Google Cloud.
Debe ser una dirección enrutable por Internet: tráfico siempre enrutado a Internet No se admite el enrutamiento privado Rangos de origen de DNS público de Google
Tipo 4 Una dirección IP externa de una VM de Compute Engine en una red de VPC diferente.
Debe ser una dirección IP que no sea RFC 1918. El enrutamiento privado no es compatible. Asegúrate de que el enrutamiento privado no esté marcado. Rangos de origen del DNS público de Google

Cuando especificas el servidor de nombres alternativo de una política de reenvío saliente, puedes elegir uno de los dos métodos de enrutamiento siguientes:

  • Enrutamiento estándar: Enruta el tráfico a través de una red de VPC autorizada o a través de Internet, según si el servidor de nombres alternativo es una dirección IP RFC 1918 o no. Si el servidor de nombres alternativo es una dirección IP RFC 1918, Cloud DNS clasifica el servidor de nombres como un servidor de nombres de Tipo 1 o Tipo 2., y enruta las solicitudes a través de una red de VPC autorizada. Si el servidor de nombres alternativo no es una dirección IP RFC 1918, Cloud DNS clasifica el servidor de nombres como de Tipo 3 y espera que el servidor de nombres sea accesible a través de Internet.

  • Enrutamiento privado: Siempre se enruta el tráfico a través de una red de VPC autorizada, independientemente de la dirección IP (RFC 1918 o no) del servidor de nombres alternativo. En consecuencia, solo se admiten los servidores de nombres de Tipo 1 y de Tipo 2.

Para acceder a un servidor de nombres alternativo de Tipo 1 o Tipo 2, Cloud DNS usa rutas en la red de VPC autorizada, en la que se encuentra el cliente de DNS. En estas rutas, se define una ruta segura al servidor de nombres:

Si quieres obtener orientación adicional sobre los requisitos de red para los servidores de nombres de Tipo 1 y Tipo 2, consulta los requisitos de red para servidores de nombres alternativos.

Control de acceso

Control de acceso general

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 aparecer como editor o owner en la sección de permisos de Cloud Console. El nivel de permiso de lector 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 de proyecto 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 de DNS o lector de DNS pueden administrar o ver las zonas administradas de todos los proyectos a los que tienen acceso.

Los propietarios de proyectos, los editores, los administradores de DNS y los lectores 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.

La caché del agente de resolución del DNS es controlada por el valor de tiempo de actividad (TTL), que configuras para tus registros y que se especifica en segundos. 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 realizar 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.

Próximos pasos