Información general sobre Cloud DNS

En esta página se ofrece una descripción general de las características y las funciones de Cloud DNS. Cloud DNS es un servicio de sistema de nombres de dominio (DNS) global, resiliente y de alto rendimiento que publica tus nombres de dominio en el DNS global de forma económica.

El DNS es una base de datos distribuida jerárquica que te permite almacenar direcciones IP y otros datos, así como buscarlos por nombre. Cloud DNS te permite publicar tus zonas y registros en DNS sin tener que gestionar tus propios servidores y software DNS.

Cloud DNS ofrece zonas públicas y zonas DNS gestionadas privadas. Las zonas públicas son visibles en Internet, mientras que las privadas solo lo son desde una o varias redes de nube privada virtual (VPC) que especifiques. Para obtener información detallada sobre las zonas, consulta el artículo Descripción general de las zonas DNS.

Cloud DNS admite permisos de Gestión de Identidades y Accesos (IAM) a nivel de proyecto y de zona DNS individual. Para obtener información sobre cómo definir permisos de gestión de identidades y accesos para recursos concretos, consulta Crear una zona con permisos de gestión de identidades y accesos específicos.

Para consultar una lista de términos generales de DNS, consulta el artículo Información general sobre DNS.

Para ver una lista de los términos clave en los que se basa Cloud DNS, consulta Términos clave.

Para empezar a usar Cloud DNS, consulta la guía de inicio rápido.

Pruébalo

Si es la primera vez que utilizas Google Cloud, crea una cuenta para evaluar el rendimiento de Cloud DNS en situaciones reales. Los nuevos clientes también reciben 300 USD en crédito gratuito para ejecutar, probar y desplegar cargas de trabajo.

Probar Cloud DNS gratis

Consideraciones sobre la VPC compartida

Para usar una zona privada gestionada de Cloud DNS, una zona de reenvío de Cloud DNS o una zona de emparejamiento de Cloud DNS con una VPC compartida, debes crear la zona en el proyecto host y, a continuación, añadir una o varias redes de VPC compartidas a la lista de redes autorizadas de esa zona. También puedes configurar la zona en un proyecto de servicio mediante la vinculación entre proyectos.

Para obtener más información, consulta las prácticas recomendadas para las zonas privadas de Cloud DNS.

Métodos de reenvío de DNS

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

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

Crea una política de servidor entrante para permitir que un cliente o servidor DNS local envíe solicitudes DNS a Cloud DNS. El cliente o el servidor DNS pueden resolver registros según el orden de resolución de nombres de una red de VPC.

Los clientes on-premise pueden resolver registros en zonas privadas, zonas de reenvío y zonas de emparejamiento para las que se haya autorizado la red VPC. Los clientes on-premise usan Cloud VPN o Cloud Interconnect para conectarse a la red de VPC.
Saliente

Puedes configurar las VMs de una red de VPC para que hagan lo siguiente:

  • Envía solicitudes DNS a los servidores de nombres DNS que elijas. Los servidores de nombres pueden estar en la misma red de VPC, en una red local o en Internet.
  • Resuelve los registros alojados en servidores de nombres configurados como destinos de reenvío de una zona de reenvío autorizada para usarla en tu red de VPC. Para obtener información sobre cómo Google Cloud dirige el tráfico a un destino de reenvío, consulta Destinos de reenvío y métodos de enrutamiento.
  • Crea una política de servidor saliente para la red de VPC con el fin de enviar todas las solicitudes de DNS a un servidor de nombres alternativo. Si utilizas un servidor de nombres alternativo, las VMs de tu red VPC ya no podrán resolver registros en zonas privadas, de reenvío o de peering de Cloud DNS, ni en zonas DNS internas de Compute Engine. Para obtener más información, consulta Orden de resolución de nombres.

Puedes configurar simultáneamente el reenvío de DNS entrante y saliente para una red de VPC. El reenvío bidireccional permite que las VMs de tu red VPC resuelvan registros en una red on-premise o en una red alojada por otro proveedor de servicios en la nube. Este tipo de reenvío también permite que los hosts de la red local resuelvan registros de tus recursos deGoogle Cloud .

El plano de control de Cloud DNS usa el orden de selección de destino de reenvío para seleccionar un destino de reenvío. Las consultas reenviadas salientes a veces pueden dar lugar a errores SERVFAIL si no se puede acceder a los destinos de reenvío o si no responden con la suficiente rapidez. Para obtener instrucciones sobre cómo solucionar este problema, consulta el artículo Las consultas reenviadas salientes reciben errores SERVFAIL.

Para obtener información sobre cómo aplicar políticas de servidor, consulta Crear políticas de servidor DNS. Para saber cómo crear una zona de reenvío, consulta el artículo Crear una zona de reenvío.

DNSSEC

Cloud DNS admite DNSSEC gestionado, que protege tus dominios frente a ataques de spoofing y envenenamiento de la caché. Cuando usas una resolución de validación como DNS público de Google, DNSSEC proporciona una autenticación sólida (pero no cifrado) de las búsquedas de dominio. Para obtener más información sobre DNSSEC, consulta Gestionar la configuración de DNSSEC.

DNS64 (vista previa)

Puedes conectar tus instancias de máquina virtual (VM) de Compute Engine solo con IPv6 (vista previa) a destinos IPv4 mediante DNS64 de Cloud DNS. DNS64 proporciona una dirección IPv6 sintetizada para cada destino IPv4. Cloud DNS crea una dirección sintetizada combinando el prefijo conocido (WKP) 64:ff9b::/96 con los 32 bits de la dirección IPv4 de destino.

Configura DNS64 y la traducción de direcciones de red con NAT público (NAT64) para que tus instancias de máquina virtual solo con IPv6 (vista previa) puedan comunicarse con destinos IPv4 en Internet. Para configurar NAT64, sigue las instrucciones que se indican en el artículo Crear una pasarela de Cloud NAT.

En el siguiente ejemplo se muestra cómo una instancia de máquina virtual solo con IPv6 (Vista previa) llamada vmipv6 resuelve el nombre de un destino solo con IPv4.

  1. La instancia de VM vmipv6 inicia una solicitud de DNS para resolver el nombre de destino en una dirección IPv6.

  2. Si existe un registro AAAA (dirección IPv6), Cloud DNS devuelve la dirección IPv6 y la instancia de VM vmipv6 la usa para conectarse al destino.

  3. Si no existe ningún registro AAAA, pero has configurado DNS64, Cloud DNS buscará un registro A (dirección IPv4). Si Cloud DNS encuentra un registro A, sintetiza un registro AAAA añadiendo el prefijo 64:ff9b::/96 a la dirección IPv4.

DNS64 traduce una dirección IPv4 a una dirección IPv6 sintetizada.
DNS64 traduce una dirección IPv4 a una dirección IPv6 sintetizada (haz clic para ampliar).

Por ejemplo, si la dirección IPv4 es 32.34.50.60, la dirección IPv6 sintetizada resultante es 64:ff9b::2022:323c, donde 2022:323c es el equivalente hexadecimal de la dirección IPv4. El prefijo 64:ff9b::/96 se define en RFC 6052. Cloud DNS sintetiza estas direcciones IPv6 aunque alojes los registros DNS de forma local, siempre que habilites el reenvío de DNS en Cloud DNS.

Puedes usar DNS64 en los siguientes casos:

  • Cumplir los requisitos que exigen el cambio a direcciones IPv6 sin asignar direcciones IPv4.
  • Pasa a una infraestructura de direcciones que solo utilice IPv6 por fases y mantén el acceso a la infraestructura IPv4 actual.
  • Evita interrupciones en los servicios críticos asegurándote de que se pueda seguir accediendo a los entornos con direcciones IPv4 antiguas durante la transición a direcciones IPv6.

Para configurar DNS64 en una red de VPC, sigue las instrucciones que se indican en el artículo sobre cómo configurar DNS64.

Control de acceso

Puedes gestionar los usuarios que tienen permiso para hacer cambios en tus registros DNS en la página IAM y administrador de laGoogle Cloud consola. Para que los usuarios tengan autorización para hacer cambios, deben tener el rol Administrador de DNS (roles/dns.admin) en la sección Permisos de la consola Google Cloud . El rol Lector de DNS (roles/dns.reader) otorga acceso de solo lectura a los registros de Cloud DNS.

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

Para ver los permisos asignados a estos roles, consulta Roles.

Control de acceso para zonas gestionadas

Los usuarios con el rol de propietario o de editor (roles/owner o roles/editor) del proyecto pueden gestionar o ver las zonas gestionadas del proyecto específico que estén gestionando.

Los usuarios con el rol Administrador de DNS o Lector de DNS pueden gestionar o ver las zonas gestionadas de todos los proyectos a los que tengan acceso.

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

Acceso por permiso de recurso

Para configurar una política en un recurso de DNS, como una zona gestionada, debes tener acceso de propietario al proyecto que posee ese recurso. El rol Administrador de DNS no tiene el permiso setIamPolicy. Como propietario de un proyecto, también puedes crear roles de IAM personalizados para satisfacer tus necesidades específicas. Para obtener información detallada, consulta el artículo sobre roles personalizados de gestión de identidades y accesos.

Rendimiento y tiempos

Cloud DNS usa Anycast para servir tus zonas gestionadas desde varias ubicaciones de todo el mundo y ofrecer alta disponibilidad. Las solicitudes se dirigen automáticamente a la ubicación más cercana, lo que reduce la latencia y mejora el rendimiento de la búsqueda de nombres autoritativos para tus usuarios.

Propagación de los cambios

Los cambios se propagan en dos partes. En primer lugar, el cambio que envíes a través de la API o de la herramienta de línea de comandos debe enviarse a los servidores DNS autoritativos de Cloud DNS. En segundo lugar, los solucionadores de DNS deben detectar este cambio cuando caduque su caché de los registros.

El valor de tiempo de vida (TTL) que definas para tus registros, que se especifica en segundos, controla la caché del resolvedor de DNS. Por ejemplo, si asignas un valor TTL de 86.400 (el número de segundos que hay en 24 horas), se indica a los solucionadores de DNS que almacenen en caché los registros durante 24 horas. Algunos solucionadores de DNS ignoran el valor de TTL o usan sus propios valores, lo que puede retrasar la propagación completa de los registros.

Si tienes previsto hacer un cambio en los servicios que requiere una ventana de tiempo reducida, te recomendamos que cambies el TTL a un valor más corto antes de hacer el cambio. El nuevo valor TTL más corto se aplica después de que caduque el valor TTL anterior en la caché del resolvedor. Este enfoque puede ayudar a reducir la ventana de almacenamiento en caché y asegurar que los nuevos ajustes de registro se apliquen más rápido. Después del cambio, puedes volver a cambiar el valor al TTL anterior para reducir la carga de los resolutores DNS.

Siguientes pasos