En esta página, se proporcionan soluciones para problemas comunes que puedes encontrar cuando usas Cloud DNS para crear zonas públicas o privadas, zonas de búsqueda inversa, zonas de reenvío y registros de recursos.
Zonas públicas
En esta sección, se abordan los problemas con las zonas públicas.
No se puede crear una zona pública
Si recibes un error attempted action failed, significa que la API de Cloud DNS
no está habilitada en tu proyecto.
Para habilitar la API de Cloud DNS, sigue estos pasos:
En la consola de Google Cloud, ve a la página Biblioteca de APIs.
En Selecciona un proyecto reciente, elige el proyecto de Google Cloud en el que en la que deseas habilitar la API.
En la página Biblioteca de la API, usa el cuadro Buscar APIs y servicios para buscar
Cloud DNS API. Aparecerá una página que describe la API.Haz clic en Habilitar.
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 resuelve un registro según el orden de resolución de nombres, con la zona que tiene el sufijo más largo para decidir qué zona consultar para un nombre de DNS determinado. Asegúrate de que
que el sufijo del registro que estás consultando coincida con al menos un registro
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 a una VM de muestra te permite verificar la conectividad mediante un túnel de Cloud VPN o 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
Cloud DNS solo busca registros CNAME como se describe en Rastreo 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 usas intercambio de tráfico de DNS y quieres reenviar consultas desde VMs en de una red de VPC del consumidor a una red de VPC de un productor y, luego, en uno o más servidores de nombres locales, asegúrate de que uno de los se cumplen los siguientes requisitos previos:
La red de VPC del productor tiene su modo de enrutamiento dinámico configurado como
GLOBAL.La VM en la red de VPC del consumidor se encuentra en la misma región que el túnel de VPN o Cloud Interconnect en la VPC del productor.
(Solo para VPN clásica) La red de VPC del productor tiene una ruta estática. configurado para enviar tráfico destinado a los servidores de nombres locales a través del Túnel de VPN clásica. La red de VPC del productor también debe tener una VM o un túnel de VPN en la misma región que la subred que usan las VMs de 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 paraexample.com.que reenvía las consultas a un servidor de nombres local mediante un Túnel de VPN clásica.Para que una VM ubicada en
us-east1en VPC1 pueda realizar consultas aexample.com., VPC2 debe tener una VM ubicada enus-east1. Una ruta estática también debe configurarse y cubrir los rangos CIDR de los servidores de nombres locales, con el próximo salto configurado como el túnel de VPN clásica.
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, 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.
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:
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 zonaexample.com., un conjunto de registros creado para el@de QNAME se interpreta como@.example.com.en lugar deexample.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.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.92Una consulta para
public.srv1.images.example.com.muestraNOERRORcon 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.
Tipo de recurso zonal no compatible
Cuando ingresas la marca --location en un comando gcloud o una solicitud a la API para una función que está orientada a una zona diferente de Cloud DNS, la solicitud se rechaza. Por ejemplo, si envías una solicitud de función solo zonal a un servidor global, o una solicitud de función global solo a un servidor zonal, el servidor rechaza la solicitud y genera un error _UNSUPPORTED_ZONAL_RESOURCETYPE.
Para obtener una lista de recursos y funciones que admite Cloud DNS zonal, consulta Asistencia de Cloud DNS zonal.
¿Qué sigue?
- Para obtener más información sobre las funciones, consulta Descripción general de Cloud DNS.
- Para resolver los errores, consulta Mensajes de error.
- Para obtener más ayuda, consulta Asistencia.