Resumen

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.

Para obtener una lista de terminología de DNS general, consulta Descripción general de 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.

Terminología de Cloud DNS

La API de Cloud DNS se basa en proyectos, zonas administradas, conjuntos de registros y cambios en conjuntos de registros.

Proyecto
Un proyecto de Google Cloud Console es un contenedor de recursos, un dominio de control de acceso y el lugar en que se configura y agrega la facturación. Para obtener más detalles, consulta Crea y administra proyectos.
Zonas administradas
La zona administrada contiene registros DNS para el mismo sufijo de nombre de DNS (por ejemplo, example.com). Un proyecto puede incluir varias zonas administradas, pero cada una de ellas debe tener un nombre único. En Cloud DNS, la zona administrada es el recurso que modela una zona de DNS. Todos los registros de una zona administrada se alojan en los mismos servidores de nombres operados por Google. Estos servidores de nombres responden a las consultas del DNS con tu zona administrada, en función de la configuración de la zona. Un proyecto puede contener varias zonas administradas. Los cargos se aplican por zona y por día de existencia de la zona administrada. Las zonas administradas son compatibles con las etiquetas, que puedes usar para organizar tu facturación.
Zonas públicas

Una zona pública es visible para Internet. En Cloud DNS, se cuenta con servidores de nombres autorizados públicos para responder las consultas sobre zonas públicas, independientemente de dónde se generen las consultas. Puedes crear registros DNS en una zona pública para publicar tu servicio en Internet. Por ejemplo, puedes crear el siguiente registro en una zona pública example.com para tu sitio web público www.example.com.

Nombre del DNS Tipo TTL (segundos) Datos
www.example.com A 300 198.51.100.0

En Cloud DNS, se asigna un conjunto de servidores de nombres cuando se crea una zona pública. Para que los registros DNS de una zona pública se puedan resolver en Internet, debes actualizar la configuración del servidor de nombres de tu registro de dominio en el registrador. Si deseas obtener más información para registrar y configurar tu dominio, consulta Configura un dominio con Cloud DNS.

Zonas privadas

En las zonas privadas, puedes administrar nombres de dominio personalizados para tus máquinas virtuales, balanceadores de cargas y otros recursos de Google Cloud sin exponer los datos de DNS subyacentes a la Internet pública. Una zona privada es un contenedor de registros DNS que solo se puede consultar con una o más redes de VPC que hayas autorizado.

Una zona privada solo puede ser consultada por los recursos del mismo proyecto en el que está definida. Las redes de VPC que autorices deben estar ubicadas en el mismo proyecto que la zona privada. Si necesitas consultar registros alojados en zonas privadas administradas de otros proyectos, usa el intercambio de tráfico de DNS.

Debes especificar la lista de redes de VPC autorizadas con las que se puede consultar tu zona privada cuando la creas o actualizas. Solo se pueden realizar consultas a tu zona privada con las redes autorizadas; si no especificas ninguna red autorizada, no podrás realizar consultas en la zona privada.

Puedes usar zonas privadas con VPC compartida. Para obtener información importante sobre el uso de zonas privadas con VPC compartida, consulta Consideraciones de VPC compartida.

Las zonas privadas no admiten las extensiones de seguridad de DNS (DNSSEC) ni conjuntos de registros de recursos personalizados de tipo NS.

Las solicitudes de registros DNS en las zonas privadas se deben enviar a través del servidor de metadatos, 169.254.169.254, que es el servidor de nombres interno predeterminado para las VM creadas a partir de las imágenes suministradas por Google. Puedes enviar consultas a este servidor de nombres desde cualquier VM que utilice una red de VPC autorizada.

Por ejemplo, puedes crear una zona privada para dev.gcp.example.com a fin de alojar registros DNS internos para aplicaciones experimentales. En la siguiente tabla se muestran ejemplos de registros en esa zona. Los clientes de la base de datos pueden conectarse al servidor de la base de datos, db-01.dev.gcp.example.com, mediante su nombre del DNS interno, en lugar de su dirección IP. Los clientes de la base de datos resuelven este nombre de DNS interno mediante el agente de resolución de host de la VM, que envía la consulta de DNS al servidor de metadatos 169.254.169.254. El servidor de metadatos actúa como un agente de resolución recursivo para realizar consultas a tu zona privada.

Nombre del DNS Tipo TTL (segundos) Datos
db-01.dev.gcp.example.com A 5 10.128.1.35
instance-01.dev.gcp.example.com A 50 10.128.1.10

En las zonas privadas, puedes crear configuraciones de DNS de horizonte dividido. Esto se debe a que puedes crear una zona privada con un conjunto diferente de registros, que anulan los de una zona pública. Luego, puedes controlar con qué redes de VPC se consultan los registros en la zona privada. Por ejemplo, consulta Zonas superpuestas.

Zonas de reenvío

Las zonas de reenvío son un tipo de zona privada administrada de Cloud DNS que envía solicitudes para esa zona a las direcciones IP de sus destinos de reenvío. Para obtener más información, consulta Métodos de reenvío de DNS.

Zonas de intercambio de tráfico

Las zonas de intercambio de tráfico son un tipo de zona privada y administrada de Cloud DNS que sigue el orden de resolución de nombres de otra red de VPC y se puede usar para resolver los nombres que se definieron en la otra red de VPC.

Operaciones de zona

Cualquier cambio que realices en las zonas administradas de Cloud DNS se registra en la colección de operaciones, que enumera las actualizaciones de las zonas administradas (modificaciones de descripciones, o estado o configuración de DNSSEC).

Registrador

Un registrador de nombres de dominio es una organización en la que se administra la reserva de nombres de dominio de Internet. Un registrador debe estar acreditado mediante un registro de dominio de nivel superior genérico (gTLD) o un registro de dominio de nivel superior de código de país (ccTLD).

DNS interno

En Google Cloud, se crean nombres de DNS internos para VM de forma automática, incluso si no usas Cloud DNS. Para obtener más información sobre el DNS interno, consulta la documentación de DNS interno.

Subzonas delegadas

El DNS permite al propietario de una zona delegar un subdominio a un servidor de nombres diferente mediante registros NS. Los agentes de resolución siguen estos registros y envían consultas para el subdominio al servidor de nombres de destino especificado en la delegación.

Colección de conjuntos de registros de recursos

La colección de conjuntos de registros de recursos conserva el estado actual de los registros DNS que integran una zona administrada. Puedes leer esta colección, pero no puedes modificarla directamente. En su lugar, edita los conjuntos de registros de recursos en una zona administrada; para ello, crea una solicitud Change en la colección de cambios. La colección de conjuntos de registros de recursos refleja todos tus cambios inmediatamente. No obstante, hay una demora entre el momento en el que se realizan los cambios en la API y el momento en el que tienen efecto en tus servidores del DNS autorizados. En Administra registros, se explica el modo de administrar los registros.

Cambios en los registros de recursos

Para realizar un cambio en la colección de conjuntos de registros de recursos, envía una solicitud Change que contenga incorporaciones o eliminaciones. Las incorporaciones y eliminaciones se pueden realizar de forma masiva o en una sola transacción atómica, y se aplican al mismo tiempo en cada servidor DNS autorizado.

Por ejemplo, si tienes un registro A que se ve de esta manera:

www  A  203.0.113.1 203.0.113.2

Y ejecutas un comando que se ve de esta manera:

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

Tu registro se ve de esta manera después del cambio masivo:

www  A  203.0.113.1 203.0.113.3

Los ADD y DEL suceden simultáneamente.

Formato de número de serie SOA

Los números de serie de los registros SOA creados en las zonas administradas de Cloud DNS aumentan monótonamente con cada cambio transaccional a los conjuntos de registros de una zona realizados con el comando gcloud dns record-sets transaction. Eres libre de cambiar manualmente el número de serie de un registro SOA a un número arbitrario; sin embargo, debes incluir una fecha con formato ISO 8601 como se recomienda en RFC 1912. Por ejemplo, en el siguiente registro SOA:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

Para cambiar el número de serie directamente desde Google Cloud Console, ingresa el valor deseado en el tercer campo delimitado por espacios del registro.

Política del servidor DNS

Mediante una política del servidor DNS, puedes acceder a los servicios de resolución de nombres que se proporcionan con Google Cloud en una red de VPC con reenvío entrante o cambiar el orden de resolución de nombres de VPC con reenvío saliente.

Dominios, subdominios y delegación

La mayoría de los subdominios son solo registros en la zona administrada del dominio superior. Los subdominios que se delegan mediante la creación de registros NS (de servidor de nombres) en la zona de su dominio superior también deben tener sus propias zonas. Crea zonas administradas para los dominios superiores en Cloud DNS antes de crear zonas destinadas a sus subdominios delegados. Hazlo aunque alojes el dominio superior en otro servicio de DNS. Si tienes varias zonas de subdominio, pero no creas la zona superior, puede ser complicado crear la zona superior más adelante al decidir moverla a Cloud DNS.

DNSSEC

Las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) son un conjunto de extensiones de Internet Engineering Task Force (IETF) para el DNS que autentican las respuestas de las búsquedas de nombres de dominios. Las DNSSEC no proporcionan protecciones de privacidad para esas búsquedas, pero impiden que los atacantes manipulen o envenenen las respuestas a las solicitudes del DNS.

Colección de DNSKEY

La colección de DNSKEY conserva el estado actual de los registros DNSKEY que se usan a fin de firmar una zona administrada habilitada para DNSSEC. Solo puedes leer esta colección; todos los cambios en los DNSKEY se realizan mediante Cloud DNS. La colección de DNSKEY posee toda la información que requieren los registradores de dominios para activar DNSSEC.

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.En
Cloud DNS, no se 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 Una dirección IP de una VM de Google Cloud en la misma red de VPC 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 Una dirección IP de un servidor de nombres de DNS disponible en Internet 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 utiliza o no una dirección RFC 1918. Los destinos Tipo 1 y Tipo 2 deben ser direcciones IP RFC 1918, y las direcciones Tipo 3 deben ser accesibles por Internet.

  • Enrutamiento privado: Siempre se enruta el tráfico a través de una red de VPC autorizada, independientemente de la dirección IP del destino. En consecuencia, solo se admiten los destinos Tipo 1 y Tipo 2.

    Con el enrutamiento privado, se realiza un seguimiento de todas las consultas reenviadas por una red de VPC y se aíslan las consultas por red de VPC para ofrecer seguridad. Es por eso que debes asegurarte de que las respuestas enviadas estén en la misma red de VPC que la solicitud saliente.

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 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 tres 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 Una dirección IP de una VM de Google Cloud en la misma red de VPC en la que se define la política del servidor saliente 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 Una dirección IP de un servidor de nombres de DNS disponible en Internet 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 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: 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 servidor de nombres alternativo usa una dirección RFC 1918, o no. Los servidores de nombres alternativos Tipo 1 y Tipo 2 deben ser direcciones IP RFC 1918, y las direcciones Tipo 3 deben ser accesibles por Internet.

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

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