Términos clave

En esta página, se proporciona terminología clave que se aplica a Cloud DNS. Revisa estas condiciones para comprender mejor cómo funciona Cloud DNS y los conceptos en los que se basa.

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.
zona administrada

La zona administrada contiene registros del sistema de nombres de dominio (DNS) para el mismo sufijo de nombre DNS (como example.com). Un proyecto puede tener 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 admiten etiquetas que puedes usar para organizar tu facturación.

zona pública

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 de DNS Tipo TTL (segundos) Datos
www.example.com A 300 198.51.100.0

Cloud DNS 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.

zona privada

Las zonas privadas te permiten administrar nombres de dominio personalizados para tus instancias de máquina virtual (VM), 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 puede ser consultado por una o más redes de nube privada virtual (VPC) que autorices.

Una zona privada solo se puede consultar desde redes en el 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. La tabla siguiente muestra 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 el 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 de 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 anula todo el conjunto de registros en 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.

Directorio de servicios

El Directorio de servicios es un registro de servicio administrado para Google Cloud que te permite registrar y descubrir servicios mediante HTTP o gRPC (mediante su API de Lookup) además de usar DNS tradicional. Puedes usar el Directorio de servicios para registrar servicios de Google Cloud y ajenos a Google Cloud.

Cloud DNS te permite crear zonas respaldadas por el Directorio de servicios, que son un tipo de zona privada que contiene información sobre los servicios y los extremos. No agregas conjuntos de registros a la zona. En cambio, se infieren de forma automática en función de la configuración del espacio de nombres del Directorio de servicios asociado con la zona. Para obtener más información sobre el Directorio de servicios, consulta Descripción general del Directorio de servicios.

Cuando creas una zona respaldada por el directorio de servicios, no puedes agregar registros a la zona directamente; los datos provienen del registro de servicio del directorio de servicios.

Cloud DNS y búsqueda inversa para direcciones que no sean RFC 1918

De forma predeterminada, Cloud DNS reenvía las solicitudes de registros PTR de direcciones que no son RFC 1918 a través de la Internet pública. Sin embargo, Cloud DNS también admite la búsqueda inversa de direcciones que no sean RFC 1918 mediante el uso de zonas privadas.

Una vez que configuras una red de VPC para que use direcciones que no son RFC 1918, debes configurar la zona privada de Cloud DNS como una zona de búsqueda inversa administrada. Esta configuración permite que Cloud DNS resuelva direcciones que no son RFC 1918 de manera local en lugar de enviarlas a través de Internet.

Cuando creas una zona DNS administrada de búsqueda inversa, no puedes agregar registros a la zona directamente; los datos provienen de los datos de la dirección IP de Compute Engine.

Cloud DNS también admite el reenvío saliente a direcciones que no son RFC 1918 mediante el enrutamiento privado de esas direcciones dentro de Google Cloud. Para habilitar este tipo de reenvío saliente, debes configurar una zona de reenvío con argumentos de la ruta de reenvío específicos. Para obtener más detalles, consulta Destinos de reenvío y métodos de enrutamiento.

zona de reenvío

Las zonas de reenvío son un tipo de zona privada administrada de Cloud DNS que reenví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.

Cuando creas una zona de reenvío, no puedes agregar registros a la zona de reenvío directamente; los datos provienen de uno o más agentes de resolución o servidores de nombre de destino configurados.

zona 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. Puedes usarla para resolver los nombres que se definen en la otra red de VPC.

Cuando creas una zona de intercambio de tráfico de DNS, no puedes agregar registros a la zona directamente; los datos provienen de la red de VPC del productor según su orden de resolución de nombres.

política de respuesta

Una política de respuesta es un concepto de zona privada de Cloud DNS que contiene reglas en lugar de registros. Estas reglas se pueden usar para lograr efectos similares al concepto de borrador de la zona de política de respuesta (RPZ) de DNS (IETF). La función de política de respuesta te permite ingresar reglas personalizadas en los servidores DNS de tu red que el agente de resolución de DNS consulta durante las búsquedas. Si una regla en la política de respuesta afecta la consulta entrante, se procesa. De lo contrario, la búsqueda continúa normalmente. Para obtener más información, consulta Administra políticas y reglas de respuesta.

Una política de respuesta es diferente de una RPZ, que es una zona DNS normal, con datos con formato especial que provoca que los agentes de resolución compatibles realicen acciones especiales. Las políticas de respuesta no son zonas de DNS y se administran por separado en la API.

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). Los cambios en los conjuntos de registros dentro de una zona se almacenan por separado en conjuntos de registros de recursos, que se describen más adelante en este documento.

Nombre de dominio internacionalizado (IDN)

Un nombre de dominio internacionalizado (IDN) es un nombre de dominio de Internet que permite que personas de todo el mundo usen en los nombres de dominios una secuencia de comandos o un alfabeto de un idioma específico, como el árabe, el chino, el cirílico, el de devanagari, el hebreo o los caracteres especiales basados en el alfabeto del Latín. Esta conversión se implementa mediante Punycode, que es una representación de los caracteres Unicode que usan ASCII. Por ejemplo, una representación de IDN de .ελ es .xn--qxam. Algunos navegadores, clientes de correo electrónico y aplicaciones pueden reconocerlo y procesarlo como .ελ en tu nombre. La internacionalización de nombres de dominios en aplicaciones (IDNA) estándar solo permite que las strings Unicode sean lo suficientemente cortas como para representarse como una etiqueta de DNS válida. Si deseas obtener información para usar IDN con Cloud DNS, consulta Crea zonas con nombres de dominio internacionalizados.

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 por 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

Google Cloud crea 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.

subzona delegada

El DNS permite al propietario de una zona delegar un subdominio a un servidor de nombres diferente mediante registros NS (servidor de nombres). 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.

conjuntos de registros de recursos

Un conjunto de registros de recursos es una colección de registros DNS con la misma etiqueta, clase y tipo, pero con datos diferentes. Los conjuntos de registros de recursos contienen el estado actual de los registros DNS que integran una zona administrada. Puedes leer un conjunto de registros de recursos, pero no puedes modificarlo 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. También puedes editar los conjuntos de registros de recursos usando la API de ResourceRecordSets. El conjunto de registros de recursos refleja todos tus cambios de inmediato. 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. Si deseas obtener información para administrar registros, consulta Administra registros.

cambio en un conjunto de registros de recursos

Para realizar un cambio en un conjunto de registros de recursos, envía una solicitud Change o ResourceRecordSets que contenga adiciones 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, puedes cambiar el número de serie directamente desde Google Cloud Console. Para ello, ingresa el valor deseado en el tercer campo delimitado por espacios del registro:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com.
[serial number] 21600 3600 259200 300`
Política del servidor DNS

Una política del servidor DNS te permite acceder a los servicios de resolución de nombres provistos por Google Cloud en una red de VPC con reenvío de entrada, o sustituir el orden de resolución de nombres por una política del servidor saliente. Para obtener más información, consulta las políticas de servidor DNS.

dominio, subdominio 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 públicas administradas para los dominios superiores en Cloud DNS antes de crear cualquier zona pública en sus subdominios delegados. Hazlo aunque alojes el dominio superior en otro servicio DNS. Si tienes varias zonas de subdominio, pero no creas la zona superior, puede ser complicado crear la zona superior más adelante cuando decidas moverla a Cloud DNS. Para obtener más información, consulta Límites del servidor de nombres.

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.