En este documento se explica la terminología clave que se aplica a Cloud DNS. Consulta estos términos para entender mejor cómo funciona Cloud DNS y los conceptos en los que se basa.
La API Cloud DNS se basa en proyectos, zonas gestionadas, conjuntos de registros y cambios en los conjuntos de registros.
- proyecto
- Un proyecto de la consola Trusted Cloud es un contenedor de recursos, un dominio para el control de acceso y el lugar donde se configura y se agrega la facturación. Para obtener más información, consulta el artículo sobre cómo crear y gestionar proyectos.
- zona gestionada
La zona gestionada contiene registros del sistema de nombres de dominio (DNS) del mismo sufijo de nombre de DNS (por ejemplo,
example.com). Un proyecto puede tener varias zonas gestionadas, pero cada una de ellas debe tener un nombre único. En Cloud DNS, la zona gestionada es el recurso que modela una zona DNS.Todos los registros de una zona gestionada se alojan en los mismos servidores de nombres gestionados por Google. Estos servidores de nombres responden a las consultas de DNS de tu zona gestionada según la configuración que le hayas dado. Un proyecto puede contener varias zonas gestionadas. Los cargos se acumulan por cada zona y por cada día que exista la zona gestionada. Las zonas gestionadas admiten etiquetas que puede usar para organizar su facturación.
- zona privada
Las zonas privadas te permiten gestionar nombres de dominio personalizados para tus instancias de máquina virtual (VM), balanceadores de carga y otros Trusted Cloud recursos sin exponer los datos de DNS subyacentes a Internet público. Una zona privada es un contenedor de registros DNS al que solo pueden enviar consultas una o varias redes de nube privada virtual (VPC) que autorices.
Debe especificar la lista de redes de VPC autorizadas que pueden consultar su zona privada al crearla o actualizarla. Solo las redes autorizadas pueden consultar tu zona privada. Si no especificas ninguna red autorizada, no podrás consultar 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 las consideraciones sobre VPC compartida.
Las zonas privadas no admiten extensiones de seguridad de DNS (DNSSEC) ni conjuntos de registros de recursos personalizados de tipo NS. Las solicitudes de registros DNS en zonas privadas deben enviarse a través del servidor de metadatos
169.254.169.254, que es el servidor de nombres interno predeterminado de las máquinas virtuales creadas a partir de imágenes proporcionadas por Google.Puedes enviar consultas a este servidor de nombres desde cualquier VM que utilice una red VPC autorizada. Por ejemplo, puedes crear una zona privada para
dev.gcp.example.comcon el fin de alojar registros DNS internos de aplicaciones experimentales. En la tabla siguiente se muestran registros de ejemplo de esa zona. Los clientes de la base de datos pueden conectarse al servidor de la base de datosdb-01.dev.gcp.example.commediante su nombre DNS interno en lugar de su dirección IP. Los clientes de la base de datos resuelven este nombre DNS interno mediante el resolutor de hosts de la VM, que envía la consulta de DNS al servidor de metadatos169.254.169.254. El servidor de metadatos actúa como un resolvedor recursivo para consultar tu zona privada.Nombre de DNS Tipo TTL (segundos) Datos db-01.dev.gcp.example.comA 5 10.128.1.35 instance-01.dev.gcp.example.comA 50 10.128.1.10 Las zonas privadas te permiten crear configuraciones de DNS de horizonte dividido. Después, puedes controlar qué redes de VPC consultan los registros de la zona privada. Por ejemplo, consulta las zonas superpuestas.
- Directorio de servicios
Service Directory es un registro de servicios gestionado para Trusted Cloud que te permite registrar y descubrir servicios mediante HTTP o gRPC (con su API Lookup), además de usar el DNS tradicional. Puedes usar Service Directory para registrar serviciosTrusted Cloud y que no seanTrusted Cloud .
Cloud DNS te permite crear zonas respaldadas por Service Directory, que son un tipo de zona privada que contiene información sobre tus servicios y endpoints. No añades conjuntos de registros a la zona, sino que se infieren automáticamente en función de la configuración del espacio de nombres del Directorio de servicios asociado a la zona. Para obtener más información sobre Service Directory, consulta el resumen de Service Directory.
Cuando crea una zona respaldada por Directorio de servicios, no puede añadir registros a la zona directamente. Los datos proceden del registro de servicios de Directorio de servicios.
- Cloud DNS y búsqueda inversa de direcciones que no son RFC 1918
Después de configurar una red de VPC para que use direcciones que no sean RFC 1918, debes configurar una zona privada de Cloud DNS como zona de búsqueda inversa gestionada. Esta configuración permite que Cloud DNS resuelva las direcciones que no sean RFC 1918 de forma local en lugar de enviarlas a través de Internet.
Cuando creas una zona de DNS de petición inversa gestionada, no puedes añadir registros a la zona directamente. Los datos proceden de los datos de direcciones IP de Compute Engine.
Cloud DNS también admite el reenvío de salida a direcciones que no sean RFC 1918 mediante el enrutamiento privado de esas direcciones en Trusted Cloud. Para habilitar este tipo de reenvío saliente, debes configurar una zona de reenvío con argumentos de ruta de reenvío específicos. Para obtener más información, consulta Destinos de reenvío y métodos de enrutamiento.
- zona de reenvío
Una zona de reenvío es un tipo de zona privada gestionada de Cloud DNS que reenvía las solicitudes de esa zona a las direcciones IP de sus destinos de reenvío. Para obtener más información, consulta los métodos de reenvío de DNS.
Cuando crea una zona de reenvío, no puede añadir registros a la zona de reenvío directamente. Los datos proceden de uno o varios servidores de nombres o resolvers de destino configurados.
- zona de emparejamiento
Una zona de peering es un tipo de zona privada gestionada de Cloud DNS que sigue el orden de resolución de nombres de otra red de VPC. Puedes usarlo para resolver los nombres que se definen en la otra red VPC.
Cuando crea una zona de peering de DNS, no puede añadir registros a la zona directamente. Los datos proceden de la red de VPC de 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 conseguir efectos similares al concepto de borrador de zona de política de respuesta de DNS (RPZ) (IETF). La función de políticas de respuesta te permite introducir reglas personalizadas en los servidores DNS de tu red que el resolvedor de DNS consulta durante las búsquedas. Si una regla de la política de respuesta afecta a la consulta entrante, se procesa. De lo contrario, la búsqueda se realiza con normalidad. Para obtener más información, consulta Gestionar 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 un formato especial que hace que los resolvers compatibles hagan cosas especiales. Las políticas de respuesta no son zonas DNS y se gestionan por separado en la API.
- Operaciones de zona
Los cambios que hagas en las zonas gestionadas de Cloud DNS se registran en la colección de operaciones, que muestra las actualizaciones de las zonas gestionadas (modificación de descripciones o del estado o la configuración de DNSSEC). Los cambios en los conjuntos de registros 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 a los usuarios de todo el mundo usar un alfabeto o una escritura específicos de un idioma, como el árabe, el chino, el cirílico, el devanágari, el hebreo o los caracteres especiales basados en el alfabeto latino en los nombres de dominio. Esta conversión se implementa mediante Punycode, que es una representación de caracteres Unicode que usa ASCII. Por ejemplo, la representación IDN de
.ελes.xn--qxam. Es posible que algunos navegadores, clientes de correo y aplicaciones lo reconozcan y lo rendericen como.ελen tu nombre. El estándar Internacionalización de nombres de dominio en aplicaciones (IDNA) solo permite cadenas Unicode que sean lo suficientemente cortas como para representarse como una etiqueta DNS válida. Para obtener información sobre cómo usar IDNs con Cloud DNS, consulta el artículo Crear zonas con nombres de dominio internacionalizados.- registrador
Un registrador de nombres de dominio es una organización que gestiona 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 por un registro de dominio de nivel superior de código de país (ccTLD).
- DNS interno
Trusted Cloud crea nombres de DNS internos para las VMs automáticamente, aunque no utilices Cloud DNS. Para obtener más información sobre el DNS interno, consulta la documentación sobre el DNS interno.
- subzona delegada
El DNS permite que el propietario de una zona delegue un subdominio en otro servidor de nombres mediante registros NS (servidor de nombres). Los resolvers 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 componen una zona gestionada. Puedes leer un conjunto de registros de recursos, pero no modificarlo directamente. En su lugar, edita el conjunto de registros de recursos en una zona gestionada creando una solicitud
Changeen la colección changes. También puedes editar los conjuntos de registros de recursos mediante la APIResourceRecordSets. El conjunto de registros de recursos reflejará todos los cambios inmediatamente. Sin embargo, hay un retraso entre el momento en que se hacen los cambios en la API y el momento en que surten efecto en tus servidores DNS autoritativos. Para obtener información sobre cómo gestionar registros, consulta Añadir, modificar y eliminar registros.- Cambio en el conjunto de registros de recursos
Para modificar un conjunto de registros de recursos, envía una solicitud
Changeo unaResourceRecordSetsque contenga las adiciones o eliminaciones. Las adiciones y eliminaciones se pueden hacer en bloque o en una sola transacción atómica, y tienen efecto al mismo tiempo en cada servidor DNS autorizado.Por ejemplo, si tienes un registro A con este aspecto:
www A 203.0.113.1 203.0.113.2
Ejecutas un comando como este:
DEL www A 203.0.113.2 ADD www A 203.0.113.3
El registro tendrá este aspecto después del cambio en bloque:
www A 203.0.113.1 203.0.113.3
Las operaciones ADD y DEL se realizan simultáneamente.
- Formato del número de serie de SOA
Los números de serie de los registros SOA creados en zonas gestionadas de Cloud DNS aumentan de forma monótona con cada cambio transaccional que se haga en los conjuntos de registros de una zona mediante el comando
gcloud dns record-sets transaction. Sin embargo, puedes cambiar manualmente el número de serie de un registro SOA por un número arbitrario, incluida una fecha con formato ISO 8601, tal como se recomienda en RFC 1912.Por ejemplo, en el siguiente registro SOA, puede cambiar el número de serie directamente desde la consola Trusted Cloud introduciendo el valor que quiera 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 de servidor DNS
Una política de servidor DNS te permite acceder a los servicios de resolución de nombres proporcionados por Trusted Cloud en una red VPC con reenvío entrante o sustituir el orden de resolución de nombres de la VPC con una política de servidor saliente. Para obtener más información, consulta las políticas de servidores DNS.
- dominio, subdominio y delegación
La mayoría de los subdominios son solo registros de la zona gestionada del dominio principal. Los subdominios que se deleguen creando registros NS (servidor de nombres) en la zona de su dominio principal también deben tener sus propias zonas. DNSSEC
Las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) son un conjunto de extensiones de la Internet Engineering Task Force (IETF) para el DNS que autentican las respuestas a las búsquedas de nombres de dominio. DNSSEC no ofrece protección de la privacidad para esas búsquedas, pero evita que los atacantes manipulen o envenenen las respuestas a las solicitudes de DNS.
- Colección de DNSKEYs
La colección DNSKEYs contiene el estado actual de los registros DNSKEY que se usan para firmar una zona gestionada con DNSSEC habilitado. Solo puedes leer esta colección. Cloud DNS se encarga de todos los cambios en las DNSKEYs. La colección DNSKEYs contiene toda la información que necesitan los registradores de dominios para activar DNSSEC.