Solucionar problemas

En esta página, se proporcionan soluciones para problemas comunes que puedes encontrar cuando usas Cloud DNS a fin de crear zonas privadas, zonas de búsqueda inversa, zonas de reenvío y registros de recursos.

Zonas privadas

En esta sección, se tratan los problemas con zonas privadas.

Problemas de zonas privadas en proyectos de servicio de VPC compartida

Para obtener información importante sobre el uso de zonas privadas con redes de VPC compartidas, consulta Zonas privadas y VPC compartida.

No se puede crear una zona privada, ni enumerar o crear políticas

Debes contar con la función de Administrador de DNS para realizar varias acciones de zona privada, como enumerar las políticas del servidor del sistema de nombres de dominio (DNS) o crear una zona privada. Esta función se puede otorgar a través de la herramienta Administración de identidades y accesos (IAM).

Las zonas privadas no se resuelven en la misma red de VPC

Asegúrate de realizar la prueba desde una instancia de VM cuya interfaz principal se encuentre en la misma red en la que está la interfaz de la zona privada que creaste

Una instancia de máquina virtual (VM) envía todo el tráfico fuera de su interfaz principal, a menos que el tráfico esté destinado a una subred conectada a una de las otras interfaces; o bien que la VM tenga enrutamiento de políticas configurado. Asegúrate de que la VM de prueba tenga su interfaz principal en la misma red en la que está la de la zona privada que estás probando.

Determina que tu VM use lo siguiente:

gcloud compute instances describe ${VM_NAME} \
     --zone=${GCE_ZONE} \
     --format="csv[no-heading](networkInterfaces['network'])"

Asegúrate de que la red esté en la lista de redes autorizadas para realizar consultas en tu zona privada:

gcloud dns managed-zones describe ${PRIVATE_ZONE_NAME} \
     --format="csv(privateVisibilityConfig['networks'])"

Verifica que el nombre de DNS en la consulta coincida con tu zona

Google Cloud usa la coincidencia de sufijo más largo a fin de decidir qué zona consultar para un nombre de DNS dado. Asegúrate de que el sufijo del registro que consultas coincida con al menos una zona privada accesible en tu red de VPC. Por ejemplo, Google Cloud primero buscará myapp.dev.gcp.example.lan en una zona que entregue dev.gcp.example.lan, si se puede acceder, antes de buscarla en una zona que entregue gcp.example.lan, si se puede acceder.

La salida del siguiente comando muestra el sufijo de DNS para una zona privada determinada:

gcloud dns managed-zones describe ${PRIVATE_ZONE_NAME} \
--format="csv[no-heading](dnsName)"

Consulta el nombre de DNS mediante el servidor de metadatos

Usa dig para enviar la consulta del nombre de DNS directamente al servidor de metadatos de Google Cloud, 169.254.169.254:

dig ${DNS_NAME} @169.254.169.254

Usa dig para consultar el servidor de nombres predeterminado de la VM:

dig ${DNS_NAME}

Si el resultado de los dos comandos dig genera respuestas diferentes, marca la sección ;; SERVER: del segundo comando. El servidor que responde debe ser el servidor de metadatos, 169.254.169.254. Si no lo es, entonces configuraste el sistema operativo invitado para que utilice un servidor de nombres de DNS personalizado, en lugar del servidor de metadatos predeterminado de Google Cloud. Las zonas privadas de Cloud DNS requieren que utilices el servidor de metadatos para la resolución de nombres. Tanto el entorno invitado de Linux como el entorno invitado de Windows hacen esto por ti. Si importaste la imagen que usas para una VM, verifica que se haya instalado el entorno de invitado adecuado.

Las zonas privadas no se resuelven a través de Cloud VPN o Cloud Interconnect

Primero, asegúrate de que puedes consultar y resolver de forma correcta el nombre de DNS desde el interior de una red de VPC autorizada.

Verifica la conectividad a través de Cloud VPN o Cloud Interconnect

Asegúrate de que la conectividad de un sistema local a tu red de VPC esté operativa. Específicamente, el tráfico de TCP y UDP en el puerto 53 debe poder salir de tu red local y entregarse a tu red de VPC. Verifica la configuración de los firewalls locales para asegurarte de que ese tráfico de salida esté permitido.

Puedes usar cualquier protocolo, como ping (ICMP), para probar la conectividad a una VM de muestra en tu red de VPC de forma local. Si bien las solicitudes de Cloud DNS no se envían a las VM de Google Cloud, probar la conectividad con una VM de muestra te permite verificar la conectividad a través de un túnel de Cloud VPN o una conexión de Cloud Interconnect. Asegúrate de configurar una regla de firewall de permiso de entrada apropiada para la VM de Google Cloud de muestra, puesto que la regla implícita de denegación de entrada bloquea todo el tráfico entrante.

Asegúrate de que el reenvío de entrada esté habilitado para la red de VPC autorizada

El reenvío de entrada debe estar habilitado en cada red de VPC que esté autorizada para consultar tu zona privada de Cloud DNS. Utiliza el siguiente comando para enumerar todas las políticas:

gcloud dns policies list

Identifica la red en la tabla saliente y comprueba el campo Reenvío (Forwarding) para ver si el reenvío está habilitado.

Asegúrate de que la red autorizada sea una red de VPC

El reenvío de DNS requiere subredes, que solo están disponibles para las redes de VPC, y no en redes heredadas.

gcloud compute networks list \
     --format="csv[no-heading](name, SUBNET_MODE)"

Las redes heredadas se identifican en la salida como LEGACY.

Asegúrate de que haya una dirección válida de reenvío de DNS reservada en esa red

El siguiente comando muestra todas las direcciones IP de reenvío de DNS reservadas en tu proyecto.

gcloud compute addresses list \
     --filter="purpose=DNS_RESOLVER" \
     --format='csv[no-heading](address, subnetwork)'

Puedes agregar una cláusula AND al filtro para limitar la salida solo a la subred que te interesa.

Ejemplo:

--filter="name ~ ^dns-forwarding AND subnetwork ${subnetwork-name}"

Si no ves una dirección IP en la red o la región que esperabas, envía un ticket al servicio de Asistencia de Google Cloud.

Ejecuta el comando dig y dirige la consulta a la dirección que encontraste en el comando anterior. Hazlo desde una VM en la misma red. Esta prueba verifica que el servidor de reenvío de entrada esté funcionando y que el problema esté en otra parte.

dig ${DNS_NAME} @10.150.0.1 # address returned by previous command

Repite el mismo comando dig, pero desde un host local en la VPN.

El registro CNAME definido en una zona privada no funciona

Los registros CNAME en zonas privadas de Cloud DNS son compatibles con el agente de resolución de DNS de Compute Engine cuando el destino es uno de los siguientes:

Los registros CNAME no pueden orientarse a ningún otro recurso. Para obtener más información, consulta la sección Transmisión de CNAME.

Zonas de búsqueda inversa

En esta sección, se proporcionan sugerencias para la solución de problemas de las zonas de búsqueda inversa. Algunos problemas de zonas privadas también se aplican a las zonas de búsqueda inversa. Para obtener más sugerencias, consulta la sección de solución de problemas de las zonas privadas.

No se puede resolver la VM con una dirección que no sea RFC 1918

Concilia tu VM con una dirección que no sea RFC 1918

Si creaste una VM durante la versión alfa distinta de RFC 1918 antes de que se iniciara la compatibilidad con Cloud DNS, es posible que estas VM no se resuelvan correctamente. Para resolver este problema, reinicia las VM.

Zonas de reenvío

En esta sección, se proporcionan consejos de resolución de problemas de las zonas de reenvío. Algunos problemas con las zonas privadas también aplican a las zonas de reenvío. Para obtener más sugerencias, consulta la sección de solución de problemas de las zonas privadas.

El reenvío de zonas (o el reenvío de salida) no funciona

Primero, asegúrate de que puedes consultar y resolver de forma correcta el nombre de DNS desde el interior de una red de VPC autorizada.

El reenvío de consultas de VM en una red de VPC de consumidor a una red de VPC de productor no funciona

Si utilizas el intercambio de tráfico de DNS y deseas reenviar consultas desde VM de una red de VPC de consumidor hasta una red de VPC de productor y, luego, a uno o más servidores de nombres locales, debes asegurarte de que la red de VPC de productor tenga una VM o un túnel VPN en la misma región que la subred que usan las VM del cliente.

Por ejemplo, supongamos que VPC1 usa una zona de intercambio de tráfico que envía consultas para example.com. a VPC2. Supongamos también que VPC2 tiene una zona de reenvío privada para example.com., que reenvía las consultas a un servidor de nombres local mediante un túnel de Cloud VPN o a través de Cloud Interconnect. Para que una VM ubicada en us-east1 en VPC1 pueda consultar example.com., VPC2 también debe tener una VM o un túnel VPN ubicado en us-east1.

Verifica la conectividad a través de Cloud VPN o Cloud Interconnect

Puedes usar cualquier protocolo, como ping (ICMP), para probar la conectividad a una VM de muestra en tu red de VPC de forma local. También debes intentar consultar tu servidor de nombres local directamente desde una VM de Google Cloud de muestra mediante una herramienta como dig:

dig ${DNS_NAME} @192.168.x.x # address of the onprem DNS server

Verifica las reglas del firewall en tu red de VPC

La regla de firewall de permiso de salida implícita permite conexiones de ida y respuestas establecidas de VM en tu red de VPC, a menos que hayas creado reglas personalizadas para denegar la salida. Si creaste reglas personalizadas de denegación de salida, deberás crear reglas de permiso de mayor prioridad que permitan la salida al menos a tus servidores de nombres locales.

Verifica el firewall local

Asegúrate de que tu firewall local esté configurado para permitir el tráfico de entrada y el tráfico de salida a 35.199.192.0/19.

Verifica los registros de tu firewall local, mediante la búsqueda de solicitudes de DNS desde 35.199.192.0/19. Para usar una expresión regex a fin de realizar una búsqueda, usa lo siguiente:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Verifica el servidor de nombres local

Verifica que no tengas ninguna LCA configurada en tu servidor de nombres local que pueda bloquear las consultas de 35.199.192.0/19.

Verifica tu servidor de nombres local para ver si recibe paquetes de 35.199.192.0/19. Si tienes acceso de shell, puedes usar una herramienta como tcpdump a fin de buscar paquetes entrantes y salientes para 35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

Verifica rutas de retorno

Tu red local debe tener una ruta al destino 35.199.192.0/19 con el túnel VPN o la conexión de interconexión para la misma red de VPC que envió la solicitud de DNS. Este comportamiento se describe en Crea zonas de reenvío.

Si utilizas varios túneles VPN para conectar la misma red de VPC a tu red local, la respuesta no tiene que ser entregada mediante el mismo túnel que la envió. Sin embargo, la respuesta debe entregarse a través de un túnel VPN con un salto siguiente en la misma red de VPC desde la cual se originó la solicitud.

Si conectaste más de una red de VPC a tu red local, debes asegurarte de que las respuestas de DNS no se envíen a la red incorrecta. Google Cloud descarta las respuestas DNS enviadas a la red de VPC incorrecta. Para obtener una solución recomendada, consulta nuestra guía de prácticas recomendadas.

El reenvío de salida a un servidor de nombres que usa una dirección IP que no es RFC 1918 genera un error

De forma predeterminada, Cloud DNS usa enrutamiento estándar, que enruta las consultas a través de la Internet pública cuando el servidor de nombres de destino tiene una dirección IP que no es RFC 1918. El enrutamiento estándar no admite el reenvío de consultas a servidores de nombres con direcciones que no son RFC 1918 y a las que no se pueda acceder desde la Internet pública.

Si deseas reenviar consultas a un servidor de nombres que usa una dirección IP que no sea RFC 1918 a través de tu red de VPC, configura la zona de reenvío de Cloud DNS o la política del servidor para usar el enrutamiento privado del servidor de nombres de destino.

Para obtener una explicación de las diferencias entre el enrutamiento estándar y el privado, consulta Destinos de reenvío y métodos de enrutamiento.

Esta limitación se aplica, aunque exista una ruta de VPC para el servidor de nombres de destino; las rutas para direcciones distintas de RFC 1918 no tienen efecto en el comportamiento de reenvío de salida de Cloud DNS cuando se configura el enrutamiento estándar.

El reenvío de salida hacia una NIC secundaria genera error

Asegúrate de haber configurado correctamente tu controlador de interfaz de red secundario (NIC).

A fin de obtener instrucciones para configurar NIC adicionales, consulta Crea instancias de máquinas virtuales con múltiples interfaces de red.

Las consultas de reenvío de salida reciben errores SERVFAIL

Si Cloud DNS recibe un error de todos los servidores de nombres de destino o no recibe una respuesta de ninguno de los servidores de nombres de destino, se muestra un error SERVFAIL.

Para resolver este problema, verifica que tus servidores de nombres locales estén configurados correctamente. Luego, verifica que tus servidores de nombres locales respondan a las consultas del rango de direcciones de Cloud DNS descrito en Abre Google Cloud y los firewalls locales para permitir el tráfico de DNS en 4 segundos. Si en tus servidores de nombres locales se consultan servidores de nombres ascendentes (por ejemplo, debido a que están configurados como agentes de resolución de almacenamiento en caché), verifica que no haya problemas con los servidores de nombres ascendentes.

Además, si el destino de reenvío es un sistema local, ten en cuenta que las rutas configuradas para esa ruta pueden ser rutas dinámicas personalizadas o rutas estáticas personalizadas, con la excepción importante de que las rutas estáticas personalizadas con las etiquetas de red no son válidas para el reenvío de consultas de DNS. Asegúrate de que la ruta que se usó para llegar al servidor de nombres local no especifique una etiqueta de red.

Usa balanceadores de cargas TCP/UDP internos como destinos de reenvío para las zonas de reenvío salientes

Cloud DNS no admite el uso de balanceadores de cargas TCP/UDP internos como destinos de reenvío para zonas de reenvío salientes o como servidores de nombres alternativos. Para obtener una lista de objetivos compatibles, consulta Objetivos de reenvío y métodos de enrutamiento.

El reenvío entrante falla en una red de VPC cuyas subredes usan rangos de direcciones IP que no son RFC 1918

Cloud DNS no admite el reenvío de mensajes entrantes si la red de VPC contiene subredes cuyos rangos de direcciones IP se encuentran fuera de los rangos que sean RFC 1918.

Registros de recursos

Esta sección proporciona sugerencias para solucionar problemas relacionados con los registros de recursos.

Datos inesperados cuando se realizan consultas en conjuntos de registros de recursos presentes en la zona

Existen varias razones por las que puedes recibir datos inesperados cuando se consultan conjuntos de registros de recursos presentes en una zona administrada de Cloud DNS:

  1. Los conjuntos de registros de recursos creados mediante la sintaxis @ especificada en RFC 1035 no son compatibles. Cloud DNS interpreta el símbolo @ de esos conjuntos de registros de recursos de manera literal. Por lo tanto, en la zona example.com., un conjunto de registros creado para el @ de QNAME se interpreta como @.example.com. en lugar de example.com.. Para resolver este problema, asegúrate de crear conjuntos de registros sin el símbolo @. Todos los nombres son relativos a la raíz de la zona.

  2. Al igual que todos los registros, los registros CNAME de comodín están sujetos a las reglas de existencia descritas en RFC 4592. Por ejemplo, supongamos que defines los siguientes conjuntos de registros en la zona example.com.:

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    Una consulta para public.srv1.images.example.com. muestra NOERROR con una sección de respuesta vacía. La existencia de un registro entre el CNAME y el QNAME evita que se muestre el CNAME, pero no hay ningún registro que coincida con exactitud con QNAME, por lo que Cloud DNS muestra una respuesta vacía. Este es el comportamiento de DNS estándar.

La VM de Google Cloud muestra registros de puntero incorrectos (PTR)

Cuando se migra una VM durante un evento de mantenimiento, la lógica del registro PTR no controla algunos casos extremos de forma correcta y revierte los registros PTR de DNS al nombre de dominio completamente calificado (FQDN) googleusercontent.com. Para restablecer la funcionalidad, vuelve a aplicar el registro PTR.

Para obtener detalles sobre cómo aplicar registros PTR en una VM, consulta Crea un registro PTR para una instancia de VM.

Conjuntos de registros de recursos de Cloud DNS mostrados en orden aleatorio

De acuerdo con las prácticas del sector de DNS, los servidores de nombres de Cloud DNS ahora aleatorizan el orden de los conjuntos de registros de recursos y, también, ignoran el orden que proporciona el servidor autorizado. Este es un comportamiento normal de DNS y se aplica a las zonas públicas y privadas de Cloud DNS.

¿Qué sigue?