En esta página, se brindan soluciones para problemas habituales que puedes encontrar cuando usas 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 con zonas públicas.
No puedes 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 , dirígete a la página Biblioteca de APIs.
En Selecciona un proyecto reciente, elige el proyecto de Google Cloud en el que deseas 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.Haz clic en Habilitar.
Zonas privadas
En esta sección, se tratan los problemas con zonas privadas.
Problemas con 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 puedes crear una zona privada ni enumerar o crear políticas
Debes contar con el rol de administrador de DNS para realizar varias acciones de zona privada, como incluir en una ficha las políticas del servidor del sistema de nombres de dominio (DNS) o crear una zona privada. Este rol se puede otorgar a través de la herramienta de Identity and Access Management (IAM).
Zonas privadas que no se resuelven en la misma red de VPC
Primero, asegúrate de realizar 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 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 un 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 la 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 usando la zona con
el sufijo más largo con el objetivo de decidir qué zona consultar para un nombre de DNS determinado. 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 busca a 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 DNS para una zona privada determinada:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv[no-heading](dnsName)"
Consulta el nombre de DNS con el servidor de metadatos
Usa dig para enviar la consulta del nombre de DNS de forma directa 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 deGoogle Cloud predeterminado. 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 con éxito 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 VMs de Google Cloud ,
probar la conectividad a 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 apropiada de firewall de permiso de entrada para la
VM deGoogle Cloud de muestra, ya que, de otra manera,
la
regla implícita de denegación de entrada bloqueará 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 equipo de asistencia deGoogle 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 reenviador 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 que se define en una zona privada no funciona
Cloud DNS solo busca registros CNAME como se describe en la búsqueda 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
Si tienes una dirección que no es RFC 1918, concilia tu VM.
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 VMs no se resuelvan de forma correcta. Para resolver este problema, reinicia las VMs.
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.
Las zonas de reenvío (o el reenvío de salida) no funcionan
Primero, asegúrate de que puedes consultar y resolver con éxito el nombre de DNS desde el interior de una red de VPC autorizada.
El reenvío de consultas de VMs en una red de VPC de consumidor a una red de VPC de productor no funciona
Si usas el intercambio de tráfico de DNS y deseas reenviar consultas desde VMs en una red de VPC del consumidor a una del productor y, luego, a uno o más servidores de nombres locales, asegúrate de que se cumpla uno de los siguientes requisitos previos:
La red de VPC de productores tiene el 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 VPN o Cloud Interconnect en 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 que usan las VMs de cliente.
Por ejemplo, supongamos que VPC1 utiliza 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 usando un túnel de VPN clásica.Para que una VM ubicada en
us-east1en VPC1 pueda consultarexample.com., VPC2 debe tener una VM ubicada enus-east1. También se debe configurar una ruta estática que abarque 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 de forma directa desde una
VM de muestra deGoogle Cloud usando 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 con la búsqueda de solicitudes de DNS desde
35.199.192.0/19. Para usar una expresión regex con el objetivo 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 ACL 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 las rutas de retorno
Tu red local debe tener una ruta al destino 35.199.192.0/19
en la que el próximo salto sea un túnel VPN o la conexión de Interconnect 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 con el mismo túnel que la envió. Sin embargo, la respuesta debe entregarse usando un túnel VPN con un próximo salto 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 de 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 del Internet público cuando el servidor de nombres de destino tiene una dirección IP que no sea 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 las que no se pueda acceder desde el Internet público.
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 con el objetivo de usar enrutamiento privado para el 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 y las rutas para direcciones que no sean 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 un error
Asegúrate de haber configurado tu controlador de interfaz de red secundario (NIC) de forma correcta.
Si deseas obtener instrucciones para configurar NIC adicionales, consulta Crea instancias de máquinas virtuales con varias 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, devuelve 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 pueden ser dinámicas personalizadas o 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 brinda 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 realizas consultas en conjuntos de registros de recursos presentes en una zona administrada de Cloud DNS:
No se admiten los conjuntos de registros de recursos que se crearon usando la sintaxis
@especificada en RFC 1035. 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 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.devuelveNOERRORcon una sección de respuesta vacía. La existencia de un registro entre el CNAME y el QNAME evita que se devuelva el CNAME, pero no hay ningún registro que coincida con exactitud con QNAME, por lo que Cloud DNS devuelve una respuesta vacía. Este es el comportamiento estándar de DNS.
La VM deGoogle Cloud muestra registros de puntero (PTR) incorrectos
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 devueltos 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 brinda el servidor autoritativo. 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á destinada a una zona diferente de Cloud DNS, la solicitud se
rechaza. Por ejemplo, si envías una solicitud de función zonal a un servidor
global, o una solicitud de función global a un servidor zonal, el servidor rechaza
la solicitud y genera un error _UNSUPPORTED_ZONAL_RESOURCETYPE.
Para obtener una lista de los recursos y funciones que admite Cloud DNS zonal, consulta Asistencia de Cloud DNS zonal.
Detección avanzada de amenazas
En esta sección, se brinda información sobre los problemas que puedes encontrar cuando usas DNS Armor y sugerencias sobre cómo corregirlos.
Las métricas no muestran consultas de DNS, o muestran muy pocas, enviadas al detector de amenazas
Primero, verifica que tengas un detector de amenazas de DNS.
Verifica tu detector de amenazas de DNS
En la consola de Google Cloud , dirígete a la página Detección avanzada de amenazas.
Verifica que aparezca un detector de amenazas.
Verifica que tengas consultas vinculadas a Internet
Los registros de consultas solo se envían cuando se realizan consultas o solicitudes vinculadas a Internet desde tu red.
En la consola de Google Cloud , dirígete a la página Monitoring.
En Métrica, selecciona
Cloud DNS Queryy, luego, eligeQueryyDNS response counts.Consulta las métricas de los tipos de objetivos vinculados a Internet.
Como alternativa, si habilitaste Cloud Logging para las consultas de DNS, usa el Explorador de registros para verificar que tengas consultas vinculadas a Internet.
En la consola de Google Cloud , accede a la página Explorador de registros.
Consulta tus registros de DNS y verifica que haya consultas vinculadas a Internet.
No se devuelven los registros de eventos de amenazas
Si Cloud Logging no recibe eventos de amenazas, primero verifica que haya un detector de amenazas avanzado configurado en el Panel. Ten en cuenta que los registros de eventos de amenazas solo se devuelven cuando se detecta una amenaza.
Verifica que la detección de amenazas esté habilitada
En la consola de Google Cloud , dirígete a la página Detección avanzada de amenazas.
Verifica que aparezca un detector de amenazas.
No se generan eventos de amenazas de DNS para algunos dominios abusivos o maliciosos
Es posible que no se generen algunos eventos de amenazas de DNS para dominios abusivos o incorrectos obtenidos de listas públicas de dominios incorrectos en Internet, ya que los dominios de amenazas de DNS cambian con frecuencia. Los dominios antiguos o vencidos de esas listas no generan eventos de amenazas de DNS.
A continuación, se indican los dominios de prueba que puedes usar para verificar los dominios de amenazas de DNS:
- dnst-gcp-blox.com
- ftags-gcp-blox.com
- dga-gcp-blox.com
Verifica que se generen eventos de amenazas de DNS para los dominios de prueba
Accede a una VM que forme parte del proyecto que supervisas.
Abre una terminal y ejecuta un comando dig para uno de los dominios de prueba.
domain=TEST_DOMAIN
dig $domain -t AReemplaza
TEST_DOMAINpor uno de los dominios que se indican en la lista.Abre la consola de Google Cloud y dirígete a la página Explorador de registros.
Realiza la siguiente consulta:
resource.type="networksecurity.googleapis.com/DnsThreatDetector"Busca el dominio de prueba que usaste en el comando dig.
Estos dominios generan eventos de amenazas de DNS. Si no encuentras los registros de DNS de los dominios que se indican, comunícate con el equipo de asistencia.
¿Qué sigue?
- Para obtener más información sobre las funciones de Cloud DNS, consulta Descripción general de Cloud DNS.
- Para resolver los errores, consulta Mensajes de error.
- Para obtener más ayuda, consulta Equipo de asistencia.