En esta página se ofrecen soluciones para los problemas habituales que pueden surgir al usar Cloud DNS para crear zonas públicas, zonas privadas,zonas de búsqueda inversa, zonas de reenvío y registros de recursos.
Zonas públicas
En esta sección se tratan los problemas relacionados con las zonas públicas.
No se puede crear una zona pública
Si aparece un error attempted action failed, significa que la API Cloud DNS no está habilitada en tu proyecto.
Para habilitar la API Cloud DNS, sigue estos pasos:
En la Google Cloud consola, ve a la página Biblioteca de APIs.
En Seleccionar un proyecto reciente, selecciona el Google Cloud proyecto en el que quieras habilitar la API.
En la página Biblioteca de APIs, usa el cuadro Buscar APIs y servicios para buscar
Cloud DNS API. Aparecerá una página que describe la API.Haga clic en Habilitar.
Zonas privadas
En esta sección se tratan los problemas relacionados con las 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 compartida, consulta Zonas privadas y VPC compartida.
No se puede crear una zona privada, ni enumerar ni crear políticas
Debes tener el rol Administrador de DNS para realizar varias acciones en zonas privadas, como enumerar las políticas de servidores del sistema de nombres de dominio (DNS) o crear una zona privada. Este rol se puede conceder a través de la herramienta Gestión de Identidades y Accesos (IAM).
Las zonas privadas no se resuelven en la misma red de VPC
Primero, asegúrate de que estás realizando la prueba desde la misma red.
Verifica que la interfaz principal de tu instancia de VM esté en la misma red que la zona privada que has creado.
Una instancia de máquina virtual (VM) envía todo el tráfico a través de su interfaz principal, a menos que el tráfico esté destinado a una subred conectada a una de las otras interfaces o si la VM tiene configurado el enrutamiento por políticas. Asegúrate de que la interfaz principal de tu VM de prueba esté en la misma red que la zona privada que estás probando.
Determina que tu VM usa:
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 consultar tu zona privada:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv(privateVisibilityConfig['networks'])"
Verifica que el nombre de DNS de la consulta coincida con tu zona
Google Cloud resuelve un registro según el orden de resolución de nombres, usando la zona con el sufijo más largo para decidir qué zona consultar para un nombre de DNS determinado. Asegúrate de que el sufijo del registro que estás consultando coincida con al menos una zona privada accesible en tu red de VPC. Por ejemplo, Google Cloud
primero busca myapp.dev.gcp.example.lan en una zona que sirve
dev.gcp.example.lan, si es accesible, antes de buscarlo en una zona que
sirve gcp.example.lan, si es accesible.
El resultado del siguiente comando muestra el sufijo de DNS de una zona privada determinada:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv[no-heading](dnsName)"
Consultar el nombre de DNS mediante el servidor de metadatos
Usa dig para enviar la consulta de nombre de DNS directamente al Google Cloud
servidor de metadatos, 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 la salida de los dos comandos dig produce respuestas diferentes, consulta la sección ;; SERVER: del segundo comando. El servidor que responde debe ser el servidor de metadatos, 169.254.169.254. Si no es así, significa que has configurado el sistema operativo invitado para que use un servidor de nombres DNS personalizado en lugar delGoogle Cloud servidor de metadatos predeterminado. Las zonas privadas de Cloud DNS requieren que uses el servidor de metadatos para la resolución de nombres. Tanto el entorno de invitado de Linux como el entorno de invitado de Windows lo hacen por ti. Si has importado la imagen que vas a usar en una máquina virtual, comprueba 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 correctamente el nombre DNS desde una red VPC autorizada.
Verificar la conectividad a través de Cloud VPN o Cloud Interconnect
Comprueba que la conectividad de un sistema on-premise a tu red VPC funcione correctamente. En concreto, el tráfico TCP y UDP del puerto 53 debe poder salir de tu red local y enviarse a tu red de VPC. Verifica la configuración de los cortafuegos on-premise para asegurarte de que se permite ese tráfico de salida.
Puedes usar cualquier protocolo, como ping (ICMP), para probar la conectividad con una VM de ejemplo de tu red de VPC desde tu entorno local. Aunque las solicitudes de Cloud DNS no se envían a las máquinas virtuales de Google Cloud , probar la conectividad con una máquina virtual de ejemplo 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 cortafuegos que permita el tráfico de entrada adecuado para la VM de ejemplo, ya que la regla de denegación de entrada implícita bloquea todo el tráfico entrante.Google Cloud
Asegúrate de que el reenvío entrante esté habilitado en la red de VPC autorizada
El reenvío entrante debe estar habilitado en cada red de VPC que esté autorizada para consultar tu zona privada de Cloud DNS. Usa el siguiente comando para mostrar todas las políticas:
gcloud dns policies list
Identifica la red en la tabla de resultados y busca el campo Reenvío para ver si está habilitado.
Comprueba que la red autorizada sea una red de VPC
El reenvío de DNS requiere subredes, que solo están disponibles en las redes VPC, no en las redes antiguas.
gcloud compute networks list \
--format="csv[no-heading](name, SUBNET_MODE)"
Las redes antiguas se identifican en el resultado como LEGACY.
Asegúrate de que haya una dirección de reenvío de DNS válida 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)'
Puede añadir una cláusula AND al filtro para limitar la salida a la subred que le interese.
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 una incidencia al equipo de Asistencia deGoogle Cloud .
Ejecuta el comando dig apuntando la consulta a la dirección que has encontrado en el comando anterior. Para ello, usa una VM de la misma red. Esta prueba verifica que el reenviador entrante funciona y que el problema se encuentra en otro lugar.
dig DNS_NAME @10.150.0.1 # address returned by previous command
Repite el mismo comando dig, pero desde un host local a través de la VPN.
El registro CNAME definido en una zona privada no funciona
Cloud DNS solo sigue los registros CNAME, tal como se describe en Seguimiento de CNAME.
Zonas de búsqueda inversa
En esta sección se ofrecen consejos para solucionar problemas de 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 consejos, consulta la sección Zonas privadas.
No se resuelve la VM con una dirección que no es RFC 1918
Si tienes una dirección que no es RFC 1918, reconcilia tu VM.
Reconciliar una VM con una dirección que no sea RFC 1918
Si creaste una máquina virtual durante la versión alfa no RFC 1918 antes de que se lanzara la compatibilidad con Cloud DNS, es posible que estas máquinas virtuales no se resuelvan correctamente. Para solucionar este problema, reinicia tus VMs.
Zonas de reenvío
En esta sección se ofrecen consejos para solucionar problemas con las zonas de reenvío. Algunos problemas de las zonas privadas también se aplican a las zonas de reenvío. Para obtener más consejos, consulta la sección Zonas privadas.
Las zonas de reenvío (reenvío saliente) no funcionan
Primero, asegúrate de que puedes consultar y resolver correctamente el nombre DNS desde una red VPC autorizada.
No se pueden reenviar consultas de máquinas virtuales de una red de VPC de consumidor a una red de VPC de productor
Si usas el emparejamiento de DNS y quieres reenviar consultas de máquinas virtuales de una red de VPC de consumidor a una red de VPC de productor y, a continuación, a uno o varios servidores de nombres on-premise, asegúrate de que se cumpla uno de los siguientes requisitos:
La red de VPC del productor tiene el modo de enrutamiento dinámico configurado como
GLOBAL.La máquina virtual de la red de VPC del consumidor está en la misma región que el túnel VPN o Cloud Interconnect de la VPC del productor.
Solo VPN clásica: la red de VPC del productor tiene una ruta estática configurada para enviar el 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 VPN en la misma región que la subred utilizada por las VMs cliente.
Por ejemplo, supongamos que VPC1 usa una zona de emparejamiento que envía consultas de
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-east1de VPC1 pueda consultarexample.com., VPC2 debe tener una VM ubicada enus-east1. También se debe configurar una ruta estática que cubra los intervalos CIDR de los servidores de nombres locales, con el siguiente salto configurado como el túnel de VPN clásica.Verificar la conectividad a través de Cloud VPN o Cloud Interconnect
Puedes usar cualquier protocolo, como ping (ICMP), para probar la conectividad con una VM de ejemplo de tu red de VPC desde tu entorno local. También debe intentar consultar su servidor de nombres local directamente desde unaGoogle Cloud VM de muestra mediante una herramienta como dig:
dig DNS_NAME @192.168.x.x # address of the onprem DNS server
Comprobar las reglas de cortafuegos de tu red de VPC
La regla de cortafuegos de salida implícita permite las conexiones salientes y las respuestas establecidas de las VMs de tu red de VPC, a menos que hayas creado reglas personalizadas para denegar la salida. Si has creado reglas de denegación de salida personalizadas, tendrás que crear reglas de permiso de mayor prioridad que permitan la salida al menos a tus servidores de nombres locales.
Comprobar el cortafuegos local
Asegúrate de que tu cortafuegos local esté configurado para permitir el tráfico entrante y saliente a 35.199.192.0/19.
Consulta los registros de tu cortafuegos local y busca solicitudes de DNS de
35.199.192.0/19. Para usar una expresión regex en una búsqueda, haz lo siguiente:
"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"
Comprobar el servidor de nombres local
Verifica que no tengas ninguna ACL configurada en tu servidor de nombres local que bloquee las consultas de 35.199.192.0/19.
Comprueba tu servidor de nombres local para ver si recibe paquetes de
35.199.192.0/19. Si tienes acceso a la shell, puedes usar una herramienta como tcpdump para buscar paquetes entrantes y salientes de 35.199.192.0/19:
sudo tcpdump port 53 and tcp -vv
Verificar las rutas de retorno
Tu red on-premise debe tener una ruta al destino 35.199.192.0/19, cuyo siguiente salto sea un túnel de VPN o una conexión de interconexión de la misma red de VPC que envió la solicitud de DNS. Este comportamiento se describe en la sección Crear 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 enviarse a través del mismo túnel que la envió. Sin embargo, la respuesta debe enviarse a través de un túnel VPN con un salto siguiente en la misma red de VPC desde la que se originó la solicitud.
Si has conectado 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 de DNS que se envían a la red de VPC incorrecta. Para ver una solución recomendada, consulta nuestra guía de prácticas recomendadas.
Falla el reenvío saliente a un servidor de nombres que usa una dirección IP que no es RFC 1918
De forma predeterminada, Cloud DNS usa el enrutamiento estándar, que enruta las consultas a través de Internet público 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 sean RFC 1918 y a los que no se pueda acceder desde Internet público.
Para reenviar consultas a un servidor de nombres que utilice una dirección IP que no sea RFC 1918 a través de tu red de VPC, configura la zona de reenvío o la política de servidor de Cloud DNS para que utilice 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 haya una ruta de VPC para el servidor de nombres de destino. Las rutas de direcciones que no sean RFC 1918 no tienen ningún efecto en el comportamiento de reenvío saliente de Cloud DNS cuando se configura el enrutamiento estándar.
Falla el reenvío saliente a una NIC secundaria
Asegúrate de que has configurado correctamente tu controlador de interfaz de red (NIC) secundario.
Para obtener instrucciones sobre cómo configurar NICs adicionales, consulta Crear instancias de máquina virtual con varias interfaces de red.
Las consultas reenviadas salientes 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 ellos, devuelve un error SERVFAIL.
Para resolver este problema, compruebe que los servidores de nombres locales estén configurados correctamente. A continuación, comprueba que tus servidores de nombres locales responden a las consultas del intervalo de direcciones de Cloud DNS descrito en Abrir firewalls locales y de Cloud para permitir el tráfico DNS Google Cloud en un plazo de 4 segundos. Si tus servidores de nombres locales consultan servidores de nombres upstream (por ejemplo, porque están configurados como resolvedores de caché), comprueba que no haya ningún problema con los servidores de nombres upstream.
Además, si el destino de la redirección 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 importante excepción de que las rutas estáticas personalizadas con etiquetas de red no son válidas para reenviar consultas de DNS. Asegúrate de que la ruta utilizada para llegar al servidor de nombres local no especifique una etiqueta de red.
Registros de recursos
En esta sección se ofrecen consejos para solucionar problemas con los registros de recursos.
Datos inesperados al consultar conjuntos de registros de recursos presentes en la zona
Hay varios motivos por los que puede recibir datos inesperados al consultar conjuntos de registros de recursos presentes en una zona gestionada de Cloud DNS:
No se admiten los conjuntos de registros de recursos creados con la sintaxis
@especificada en el RFC 1035. Cloud DNS interpreta literalmente el símbolo@en los conjuntos de registros de recursos. Por lo tanto, en la zonaexample.com., un conjunto de registros creado para el QNAME@se interpreta como@.example.com.en lugar deexample.com.. Para solucionar este problema, cree conjuntos de registros sin el símbolo@. Todos los nombres son relativos al vértice de la zona.Al igual que todos los registros, los registros CNAME comodín están sujetos a las reglas de existencia descritas en RFC 4592. Por ejemplo, supongamos que define 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 de
public.srv1.images.example.com.devuelveNOERRORcon una sección de respuesta vacía. La existencia de un registro entre el CNAME y el QNAME impide que se devuelva el CNAME, pero no hay ningún registro que coincida exactamente con el QNAME, por lo que Cloud DNS devuelve una respuesta vacía. Este es el comportamiento estándar de DNS.
Google Cloud La máquina virtual muestra registros de puntero (PTR) incorrectos
Cuando se migra una VM durante un evento de mantenimiento, la lógica del registro PTR no gestiona correctamente algunos casos extremos y revierte los registros PTR de DNS al nombre de dominio completo (FQDN) googleusercontent.com. Para restaurar la funcionalidad, vuelve a aplicar el registro PTR.
Para obtener información sobre cómo aplicar registros PTR en una VM, consulta el artículo Crear un registro PTR para una instancia de VM.
Conjuntos de registros de recursos de Cloud DNS devueltos en orden aleatorio
De acuerdo con las prácticas del sector de los DNS, los servidores de nombres de Cloud DNS ahora aleatorizan el orden de los conjuntos de registros de recursos e ignoran el orden proporcionado por el servidor autorizado. Este es el comportamiento normal del DNS y se aplica a las zonas de Cloud DNS públicas y privadas.
Tipo de recurso zonal no admitido
Si introduces la marca --location en un comando gcloud o en una solicitud de API para una función que se dirige a otra zona de Cloud DNS, la solicitud se rechazará. Por ejemplo, si envía una solicitud de función solo para zonas a un servidor global o una solicitud de función solo para globales a un servidor zonal, el servidor rechazará la solicitud y devolverá un error _UNSUPPORTED_ZONAL_RESOURCETYPE.
Para ver una lista de los recursos y las funciones que admite Cloud DNS zonal, consulta Compatibilidad con Cloud DNS zonal.
Detección de amenazas avanzada
En esta sección se proporciona información sobre los problemas que puede encontrar al usar DNS Armor y se ofrecen sugerencias sobre cómo solucionarlos.
Las métricas muestran que no se envían consultas de DNS al detector de amenazas o que se envían muy pocas
Primero, comprueba que tienes un detector de amenazas de DNS.
Verificar el detector de amenazas de DNS
En la Google Cloud consola, ve a la página Detección avanzada de amenazas.
Comprueba que haya un detector de amenazas en la lista.
Verificar que tienes consultas vinculadas a Internet
Los registros de consultas solo se envían cuando se hacen consultas o solicitudes a su red que están vinculadas a Internet.
En la Google Cloud consola, ve a la página Monitoring.
En Métrica, seleccione
Cloud DNS Queryy, a continuación, elijaQueryyDNS response counts.Consulte las métricas de los tipos de destino que están vinculados a Internet.
Si has habilitado el registro en Cloud de las consultas de DNS, puedes usar el Explorador de registros para verificar que tienes consultas vinculadas a Internet.
En la Google Cloud consola, ve a la página Explorador de registros.
Consulta tus registros DNS y comprueba si hay consultas dirigidas a Internet.
No se devuelven los registros de eventos de amenazas
Si Cloud Logging no recibe eventos de amenazas, primero compruebe que haya configurado un detector de amenazas avanzado en el panel de control. Ten en cuenta que los registros de eventos de amenazas solo se devuelven cuando se detecta una amenaza.
Verificar que la detección de amenazas esté habilitada
En la Google Cloud consola, ve a la página Detección avanzada de amenazas.
Comprueba que haya un detector de amenazas en la lista.
Siguientes pasos
- Para obtener más información sobre las características de Cloud DNS, consulta la descripción general de Cloud DNS.
- Para resolver errores, consulta Mensajes de error.
- Para obtener más ayuda, consulta Asistencia.