Descripción general de las zonas DNS

Cloud DNS admite diferentes tipos depúblico y Zonas privadas . Este documento detalla los diferentes tipos de zonas y cuándo se puede usar una u otra.

Zonas de reenvío

Las zonas de reenvío de DNS en la nube permiten configurar servidores de nombres de destino para zonas privadas específicas. Usar una zona de reenvío es una forma de implementar el reenvío de DNS saliente desde la 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, se especifica un conjunto de destinos de reenvío. Cada destino de reenvío es un nombre de dominio completo (FQDN) o una dirección IP de un servidor DNS, ubicado en su red de VPC o en una red local conectada a su red de VPC mediante Cloud VPN o Cloud Interconnect.

Objetivos de reenvío y métodos de enrutamiento

Cloud DNS admite cuatro tipos de objetivos y ofrece métodos de enrutamiento estándar o privados para la conectividad.

Puede elegir uno de los dos siguientes métodos de enrutamiento cuando agrega el destino de reenvío a la zona de reenvío:

• Enrutamiento estándar: Enruta el tráfico a través de una red VPC autorizada o por internet, según 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 lo clasifica como de Tipo 1 o Tipo 2 y enruta las solicitudes a través de una red VPC autorizada. Si el destino no es una dirección IP RFC 1918, Cloud DNS lo clasifica como de Tipo 3 y espera que sea accesible por internet.

• Enrutamiento privado: El tráfico siempre se enruta a través de una red VPC autorizada, independientemente de la dirección IP del destino (RFC 1918 o no). Por lo tanto, solo se admiten destinos de tipo 1 y tipo 2.

Si utiliza un FQDN como destino de reenvío, el método de enrutamiento debe coincidir con su tipo de red. Cuando su servidor de nombres de dominio resuelve a una dirección IP pública, debe utilizar el enrutamiento estándar.

Para acceder a un destino de reenvío de tipo 1 o tipo 2, Cloud DNS utiliza rutas en la red VPC autorizada donde se encuentra el cliente DNS. Estas rutas definen una ruta segura al destino de reenvío:

• Para enviar tráfico a destinos de tipo 1, Cloud DNS utiliza rutas de subred creadas automáticamente. Para responder, los destinos de tipo 1 utilizan una ruta de enrutamiento especial para las respuestas de Cloud DNS .

• Para enviar tráfico a destinos de tipo 2, Cloud DNS puede usar rutas dinámicas o estáticas personalizadas , excepto las rutas estáticas personalizadas con etiquetas de red. Para responder, los destinos de reenvío de tipo 2 usan rutas en su red local.

Para obtener orientación adicional sobre los requisitos de red para objetivos de tipo 1 y tipo 2, consulte Requisitos de red de destino de reenvío .

Para acceder a un destino de reenvío de Tipo 4, Cloud DNS primero resuelve el nombre de dominio y luego utiliza el método de enrutamiento de la red de origen. Por ejemplo, si subdomain.example.com se resuelve a una dirección IP de un sistema local conectado a la red VPC autorizada para consultar la zona de reenvío a través de Cloud VPN, utiliza las mismas reglas de enrutamiento que un destino de reenvío de Tipo 2.

Al usar un FQDN como destino de reenvío, solo se puede usar uno. Este destino puede resolver hasta 50 direcciones IP.

Reenvío prohibido de direcciones IP de destino

No puedes utilizar las siguientes direcciones IP para destinos de reenvío de DNS en la nube:

• 169.254.0.0/16
• 192.0.0.0/24
• 192.0.2.0/24
• 192.88.99.0/24
• 198.51.100.0/24
• 203.0.113.0/24
• 224.0.0.0/4
• 240.0.0.0/4
• ::1/128
• ::/128
• 2001:db8::/32
• fe80::/10
• fec0::/10
• ff00::/8

Orden de selección de destino de reenvío

Cloud DNS le permite configurar una lista de destinos de reenvío para una zona de reenvío.

Al configurar dos o más destinos de reenvío, Cloud DNS utiliza un algoritmo interno para seleccionar uno. Este algoritmo clasifica cada destino.

Cuando se utiliza un FQDN como destino de reenvío, Cloud DNS resuelve el nombre de dominio en un conjunto de hasta 50 direcciones IP y luego aplica el mismo algoritmo a esas direcciones IP.

Para procesar una solicitud, Cloud DNS primero intenta una consulta DNS contactando al servidor de reenvío con la clasificación más alta. Si ese servidor no responde, Cloud DNS repite la solicitud al siguiente servidor de reenvío con la clasificación más alta. Si ningún servidor de reenvío responde, Cloud DNS genera una respuesta SERVFAIL .

El algoritmo de clasificación es automático y los siguientes factores aumentan la clasificación de un destino de reenvío:

• Cuanto mayor sea el número de respuestas DNS correctas procesadas por el destino de reenvío. Entre las respuestas DNS correctas se incluyen las respuestas NXDOMAIN.
• Cuanto menor sea la latencia (tiempo de ida y vuelta) para comunicarse con el destino de reenvío.

Utilizar zonas de reenvío

Las máquinas virtuales en una red VPC pueden usar una zona de reenvío de DNS en la nube en los siguientes casos:

• La red de VPC ha sido autorizada para usar la zona de reenvío de Cloud DNS. Para usar esta zona, puede autorizar varias redes de VPC en el mismo proyecto o en varios proyectos, siempre que pertenezcan a la misma organización.

• El sistema operativo invitado de cada VM en la red VPC utiliza el servidor de metadatos de la VM 169.254.169.254 como su servidor de nombres.

Si utiliza un FQDN como servidor de nombres de destino, revise los siguientes elementos:

• Sólo puedes tener un único objetivo de reenvío.
• No se admite la resolución de destino FQDN a través de otra zona de reenvío.
• No se puede utilizar un FQDN como servidor de nombres alternativo en las políticas del servidor.
• Un destino FQDN puede resolver hasta 50 direcciones IP asociadas. Cualquier dirección resuelta que supere 50 se trunca.

Zonas de reenvío superpuestas

Dado que las zonas de reenvío de Cloud DNS son un tipo de zona privada administrada por Cloud DNS, puede crear varias zonas que se superpongan. Las máquinas virtuales configuradas como se describió anteriormente resuelven un registro según el orden de resolución de nombres , utilizando la zona con el sufijo más largo. Para obtener más información, consulte Zonas superpuestas .

Zonas de almacenamiento en caché y reenvío

Cloud DNS almacena en caché las respuestas a las consultas enviadas a sus zonas de reenvío. Cloud DNS mantiene en caché las respuestas de los destinos de reenvío accesibles durante el menor de los siguientes periodos:

• 60 segundos
• La duración del tiempo de vida del registro (TTL)

Cuando todos los objetivos de reenvío de una zona de reenvío se vuelven inalcanzables, Cloud DNS mantiene su caché de los registros solicitados previamente en esa zona mientras dure el TTL de cada registro.

Cuándo utilizar peering en su lugar

Cloud DNS no puede usar enrutamiento transitivo para conectarse a un destino de reenvío. Para ilustrar una configuración no válida, considere el siguiente escenario:

• Ha utilizado Cloud VPN o Cloud Interconnect para conectar una red local a una red VPC llamada vpc-net-a .

• Has usado el emparejamiento de redes VPC para conectar la red VPC vpc-net-a a vpc-net-b . Has configurado vpc-net-a para exportar rutas personalizadas y vpc-net-b para importarlas.

• Ha creado una zona de reenvío cuyos destinos se encuentran en la red local a la que está conectada vpc-net-a . Ha autorizado vpc-net-b a usar dicha zona de reenvío.

En este escenario, la resolución de un registro en una zona atendida por los destinos de reenvío falla, incluso si hay conectividad desde vpc-net-b a su red local. Para demostrar este fallo, realice las siguientes pruebas desde una máquina virtual en vpc-net-b :

• Consultar el servidor de metadatos 169.254.169.254 de la máquina virtual (VM) para un registro definido en la zona de reenvío. Esta consulta falla (como era de esperar) porque Cloud DNS no admite el enrutamiento transitivo a destinos de reenvío. Para usar una zona de reenvío, la máquina virtual debe estar configurada para usar su servidor de metadatos.

• Consulta directamente el destino de reenvío para ese mismo registro. Aunque Cloud DNS no utiliza esta ruta, esta consulta demuestra que la conectividad transitiva es correcta.

Puede utilizar una zona de emparejamiento de Cloud DNS para solucionar este escenario no válido:

1. Cree una zona de emparejamiento de Cloud DNS autorizada para vpc-net-b que tenga como destino vpc-net-a .
2. Cree una zona de reenvío autorizada para vpc-net-a cuyos destinos de reenvío sean servidores de nombres locales.

Puede realizar estos pasos en cualquier orden. Después de completarlos, las instancias de Compute Engine en vpc-net-a y vpc-net-b podrán consultar los destinos de reenvío locales.

Para obtener información sobre cómo crear zonas de reenvío, consulte Crear una zona de reenvío .

Zonas de peering

Una zona de peering es una zona privada de Cloud DNS que permite enviar solicitudes DNS entre zonas de Cloud DNS en diferentes redes VPC. Por ejemplo, un proveedor de software como servicio (SaaS) puede dar a los clientes acceso a sus registros DNS administrados en Cloud DNS.

Para proporcionar interconexión DNS, debe crear una zona de interconexión privada de Cloud DNS y configurarla para que realice búsquedas DNS en una red de VPC donde estén disponibles los registros del espacio de nombres de esa zona. La red de VPC donde la zona de interconexión DNS realiza las búsquedas se denomina red de productor de DNS .

La zona de intercambio solo es visible para las redes VPC seleccionadas durante la configuración de la zona. La red VPC autorizada a usar la zona de intercambio se denomina red de consumidor DNS .

Después Google Cloud Los recursos de la red de consumidores DNS están autorizados y pueden buscar registros en el espacio de nombres de la zona de interconexión como si estuvieran en la red de productores DNS. Las búsquedas de registros en el espacio de nombres de la zona de interconexión siguen el orden de resolución de nombres de la red de productores DNS.

Por lo tanto, Google Cloud Los recursos en la red de consumidores de DNS pueden buscar registros en el espacio de nombres de la zona desde las siguientes fuentes disponibles en la red de productores de DNS:

• Zonas privadas administradas por Cloud DNS autorizadas para su uso por la red de productores de DNS.
• Zonas de reenvío administradas por DNS en la nube autorizadas para su uso por la red de productores de DNS.
• Nombres DNS internos de Compute Engine en la red de productores de DNS.
• Un servidor de nombres alternativo, si se ha configurado una política de servidor saliente en la red del productor de DNS.

Con el peering de DNS, es posible hacer que una red ( red de consumidor de DNS ) reenvíe solicitudes de DNS a otra red ( red de productor de DNS ), que luego realiza búsquedas de DNS.

Limitaciones y puntos clave del peering DNS

Tenga en cuenta lo siguiente al configurar el peering DNS:

• El peering de DNS es una relación unidireccional. Permite Google Cloud recursos en la red de consumidores DNS para buscar registros en el espacio de nombres de la zona de peering como si fuera el Google Cloud Los recursos estaban en la red del productor de DNS.
• Las redes de productores y consumidores de DNS deben ser redes VPC.
• Si bien las redes de productores y consumidores de DNS suelen ser parte de la misma organización, también se admite el peering de DNS entre organizaciones.
• El emparejamiento DNS y el emparejamiento de redes VPC son servicios diferentes. El emparejamiento de redes VPC no comparte automáticamente la información DNS. El emparejamiento DNS se puede usar con el emparejamiento de redes VPC, pero no es necesario para el emparejamiento DNS.
• Se admite el emparejamiento DNS transitivo, pero solo mediante un único salto transitivo. En otras palabras, no se pueden involucrar más de tres redes VPC (la red intermedia es el salto transitivo). Por ejemplo, se puede crear una zona de emparejamiento en vpc-net-a que apunte vpc-net-b y, a continuación, otra en vpc-net-b que apunte vpc-net-c .
• Si utiliza el emparejamiento DNS para dirigirse a una zona de reenvío mientras el enrutamiento dinámico global está deshabilitado en la red de VPC de productor, la red de VPC de destino con la zona de reenvío debe contener una máquina virtual, una conexión VLAN o un túnel Cloud VPN ubicado en la misma región que la máquina virtual de origen que utiliza la zona de emparejamiento DNS. Para obtener más información sobre esta limitación, consulte "El reenvío de consultas desde máquinas virtuales en una red de VPC de consumidor a una red de VPC de productor no funciona" .

Para obtener instrucciones sobre cómo crear una zona de intercambio, consulte Crear una zona de intercambio .

Zonas de búsqueda inversa administradas

Una zona de búsqueda inversa administrada es una zona privada con un atributo especial que le indica a Cloud DNS que realice una búsqueda PTR en los datos DNS de Compute Engine.

Registros PTR para direcciones RFC 1918 en zonas privadas

Para realizar búsquedas inversas con registros PTR personalizados para direcciones RFC 1918 , debe crear una zona privada de Cloud DNS que sea al menos tan específica como una de las siguientes zonas de ejemplo. Esto se debe a la coincidencia del sufijo más largo descrita en Orden de resolución de nombres .

Las zonas de ejemplo incluyen las siguientes:

• 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 crea una zona privada de Cloud DNS para direcciones RFC 1918, los registros PTR personalizados que cree para las máquinas virtuales de esa zona se sobrescribirán con los registros PTR que el DNS interno crea automáticamente. Esto se debe a que los registros PTR del DNS interno se crean en la lista anterior de zonas más específicas.

Por ejemplo, supongamos que crea una zona privada administrada para 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

En este ejemplo, se ignora el registro PTR de in-addr.arpa. en la zona privada de Cloud DNS. Cualquier consulta PTR para 1.1.1.10.in-addr.arpa. se responde mediante la zona DNS interna 10.in-addr.arpa. ., más específica.

Para anular los registros PTR DNS internos creados automáticamente para las máquinas virtuales, asegúrese de crear sus 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 crea el siguiente registro PTR en una zona privada para 10.in-addr.arpa. , su registro anula el generado automáticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain .

Si solo necesita anular una parte de un bloque de red, puede crear zonas privadas de Cloud DNS inversas más específicas. Por ejemplo, una zona privada para 5.10.in-addr.arpa. puede usarse para almacenar registros PTR que anulen cualquier registro PTR DNS interno creado automáticamente para máquinas virtuales con direcciones IP en el rango de direcciones 10.5.0.0/16 .

Para obtener instrucciones sobre cómo crear una zona de búsqueda inversa administrada, consulte Crear una zona de búsqueda inversa administrada .

Zonas superpuestas

Dos zonas se superponen cuando el nombre de dominio de origen de una zona es idéntico o un subdominio del de la otra zona. Por ejemplo:

• Una zona para gcp.example.com y otra zona para gcp.example.com se superponen porque los nombres de dominio son idénticos.
• Una zona para dev.gcp.example.com y una zona para gcp.example.com se superponen porque dev.gcp.example.com es un subdominio de gcp.example.com .

Reglas para zonas superpuestas

Cloud DNS aplica las siguientes reglas para zonas superpuestas:* No se permiten zonas públicas superpuestas en los mismos servidores de nombres de Cloud DNS. Al crear zonas superpuestas, Cloud DNS intenta colocarlas en servidores de nombres diferentes. Si esto no es posible, Cloud DNS no crea la zona superpuesta.

• Una zona privada puede superponerse con cualquier zona pública.

• Las zonas privadas asignadas a diferentes redes de VPC pueden solaparse. Por ejemplo, dos redes de VPC pueden tener cada una una máquina virtual de base de datos llamada database.gcp.example.com en una zona gcp.example.com . Las consultas a database.gcp.example.com reciben diferentes respuestas según los registros de zona definidos en la zona autorizada para cada red de VPC.

• Dos zonas privadas autorizadas para ser accesibles desde la misma red VPC no pueden tener orígenes idénticos, a menos que una sea un subdominio de la otra. El servidor de metadatos utiliza la coincidencia del sufijo más largo para determinar el origen que se debe consultar para los registros de una zona determinada.

Ejemplos de resolución de consultas

Google Cloud Resuelve las zonas de Cloud DNS como se describe en Orden de resolución de nombres . Al determinar la zona que se consultará para un registro determinado, Cloud DNS busca una zona que coincida con la mayor parte posible del registro solicitado (coincidencia del sufijo más largo).

A menos que haya especificado un servidor de nombres alternativo en una política de servidor de salida, Google Cloud Primeros intentos de encontrar un registro en una zona privada (o zona de reenvío o zona de peering) autorizada para su red VPC antes de buscar el registro en una zona pública.Los siguientes ejemplos ilustran el orden que utiliza el servidor de metadatos al consultar registros DNS. Para cada uno de estos ejemplos, suponga que ha creado dos zonas privadas, gcp.example.com y dev.gcp.example.com , y ha autorizado el acceso a ellas desde la misma red de VPC. Google Cloudmaneja las consultas DNS de las máquinas virtuales en una red VPC de la siguiente manera:

• El servidor de metadatos utiliza servidores de nombres públicos para resolver un registro para myapp.example.com. (observe el punto final), ya que no existe una zona privada para example.com autorizada para la red de VPC. Utilice dig desde una máquina virtual de Compute Engine para consultar el servidor de nombres predeterminado de la máquina virtual:

  dig myapp.example.com.
  

  Para obtener más detalles, consulte Consulta del nombre DNS mediante el servidor de metadatos .

• El servidor de metadatos resuelve el registro myapp.gcp.example.com mediante la zona privada autorizada gcp.example.com ya que gcp.example.com es el sufijo común más largo entre el nombre del registro solicitado y las zonas privadas autorizadas disponibles. Se devuelve NXDOMAIN si no hay ningún registro para myapp.gcp.example.com definido en la zona privada gcp.example.com , incluso si hay un registro para myapp.gcp.example.com definido en una zona pública .

• De forma similar, las consultas para myapp.dev.gcp.example.com se resuelven según los registros de la zona privada autorizada dev.gcp.example.com . Se devuelve NXDOMAIN si no hay ningún registro para myapp.dev.gcp.example.com en la zona dev.gcp.example.com , incluso si existe un registro para myapp.dev.gcp.example.com en otra zona privada o pública .

• Las consultas para myapp.prod.gcp.example.com se resuelven según los registros en 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

Puede usar una combinación de zonas públicas y privadas en una configuración de DNS de horizonte dividido. Las zonas privadas permiten definir diferentes respuestas a una consulta para el mismo registro cuando esta se origina desde una máquina virtual dentro de una red de VPC autorizada. El DNS de horizonte dividido es útil cuando necesita proporcionar diferentes registros para las mismas consultas DNS según la red de VPC de origen.

Consideremos el siguiente ejemplo de horizonte dividido:

• Ha creado una zona pública, gcp.example.com , y ha configurado su registrador para utilizar servidores de nombres Cloud DNS.
• Ha creado una zona privada, gcp.example.com , y ha autorizado a su red VPC a acceder a esta zona.

En la zona privada, ha creado un único registro como se muestra en la siguiente tabla.

En la zona pública, has creado dos registros.

Las siguientes consultas se resuelven como se describe:

• Una consulta para myrecord1.gcp.example.com desde una VM en su red VPC devuelve 10.128.1.35 .
• Una consulta para myrecord1.gcp.example.com desde Internet devuelve 104.198.6.142 .
• Una consulta para myrecord2.gcp.example.com desde una VM en su red VPC devuelve un error NXDOMAIN porque no hay ningún registro para myrecord2.gcp.example.com en la zona privada gcp.example.com .
• Una consulta para myrecord2.gcp.example.com desde Internet devuelve 104.198.7.145 .

Vinculación entre proyectos

La vinculación entre proyectos le permite mantener la propiedad del espacio de nombres DNS del proyecto de servicio independientemente de la propiedad del espacio de nombres DNS de toda la red VPC.

Una configuración típica de VPC compartida consta de proyectos de servicio que asumen la propiedad de una aplicación o servicios de máquina virtual (VM), mientras que el proyecto host asume la propiedad de la red y la infraestructura de red de la VPC. A menudo, se crea un espacio de nombres DNS a partir del espacio de nombres de la red de la VPC para que coincida con los recursos del proyecto de servicio. En este tipo de configuración, puede resultar más sencillo delegar la administración del espacio de nombres DNS de cada proyecto de servicio a los administradores de cada uno (que suelen ser departamentos o empresas diferentes). La vinculación entre proyectos permite separar la propiedad del espacio de nombres DNS del proyecto de servicio de la propiedad del espacio de nombres DNS de toda la red de la VPC.

La siguiente figura muestra una configuración típica de VPC compartida con emparejamiento de DNS.

La siguiente figura muestra una configuración con vinculación entre proyectos. Cloud DNS permite que cada proyecto de servicio cree y posea sus propias zonas DNS, pero que estas permanezcan vinculadas a la red compartida del proyecto anfitrión. Esto permite una mayor autonomía y un límite de permisos más preciso para la administración de zonas DNS.

La vinculación entre proyectos proporciona lo siguiente:

• Los administradores y usuarios de proyectos de servicio pueden crear y administrar sus propias zonas DNS.
• No es necesario crear una red VPC de marcador de posición.
• Los administradores del proyecto host no tienen que gestionar el proyecto de servicio.
• Los roles de IAM todavía se aplican a nivel de proyecto.
• Todas las zonas DNS están asociadas directamente con la red VPC compartida.
• La resolución DNS universal está disponible. Cualquier máquina virtual de la red VPC compartida puede resolver las zonas asociadas.
• No hay límite de saltos transitivos. Se puede gestionar con un diseño de concentrador y radio.

Para obtener instrucciones sobre cómo crear una zona con enlace entre proyectos habilitado, consulte Crear una zona de enlace entre proyectos .

Zonas DNS en la nube zonal

El DNS en la nube zonal le permite crear zonas DNS privadas que tienen un alcance de Google Cloud Solo zona. Las zonas DNS zonales en la nube se crean para GKE cuando elige un ámbito de clúster .

El servicio DNS en la nube predeterminado es global y los nombres DNS son visibles globalmente dentro de su red de VPC. Esta configuración expone su servicio a interrupciones globales. El DNS en la nube zonal es un nuevo servicio DNS en la nube privado que existe dentro de cada... Google Cloud zona. El dominio de falla está contenido dentro de esa Google Cloud Zona. Las zonas privadas de DNS en la nube zonal no se ven afectadas cuando se producen interrupciones globales. Cualquier Google Cloud Las interrupciones zonales solo afectan a esa zona específica. Google Cloud zona y zonas DNS en la nube dentro de esa Google Cloud zona. Tenga en cuenta que cualquier recurso creado en un servicio zonal solo es visible para esa Google Cloudzona.

Para saber cómo configurar una zona zonal de ámbito de clúster de Cloud DNS, consulta Configurar una zona zonal de ámbito de clúster de GKE .

Compatibilidad con DNS en la nube zonal

En la siguiente tabla se enumeran los recursos y las características de Cloud DNS que admiten los servicios zonales de Cloud DNS.

¹ Zonal Cloud DNS solo admite zonas de reenvío limitadas a un clúster de GKE.

² El controlador de GKE sobrescribe cualquier cambio en los registros cuando se reinicia.

Facturación para zonas DNS en la nube zonales

La facturación de las zonas DNS en la nube zonales y las políticas de respuesta funciona de la misma manera que sus contrapartes globales.

¿Qué sigue?

• Para trabajar con zonas administradas, consulte Crear, modificar y eliminar zonas .
• Para encontrar soluciones a problemas comunes que pueda encontrar al usar Cloud DNS, consulte Solución de problemas .
• Para obtener una descripción general de Cloud DNS, consulte Descripción general de Cloud DNS .