Esta página proporciona soluciones a problemas comunes que puede encontrar 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
Esta sección cubre problemas con zonas públicas.
No se puede crear una zona pública
Si recibe un error attempted action failed , significa que la API de Cloud DNS no está habilitada en su proyecto.
Para habilitar la API de Cloud DNS, siga estos pasos:
En el Google Cloud consola, vaya a la página Biblioteca API .
Para seleccionar un proyecto reciente , seleccione el Google Cloud Proyecto en el que desea habilitar la API.
En la página de la biblioteca de API , usa el cuadro "Buscar API y servicios" para buscar
Cloud DNS API. Aparecerá una página con la descripción de la API.Haga clic en Habilitar .
Zonas privadas
Esta sección cubre problemas con zonas privadas.
Problemas de zona privada en proyectos de servicio VPC compartido
Para obtener información importante sobre el uso de zonas privadas con redes VPC compartidas, consulte Zonas privadas y VPC compartidas .
No se puede crear una zona privada, no se pueden enumerar ni crear políticas
Debe tener el rol de Administrador de DNS para realizar diversas acciones en zonas privadas, como listar las políticas del servidor del Sistema de Nombres de Dominio (DNS) o crear una zona privada. Este rol se puede otorgar mediante la herramienta de Administración de Identidad y Acceso (IAM) .
Las zonas privadas no se resuelven en la misma red VPC
Asegúrese de estar realizando la prueba desde una instancia de VM cuya interfaz principal esté en la misma red que la zona privada que ha creado.
Una instancia de máquina virtual (VM) envía todo el tráfico desde su interfaz principal, a menos que este se dirija a una subred conectada a una de las otras interfaces o si la VM tiene configurado el enrutamiento de políticas . Asegúrese de que la VM de prueba tenga su interfaz principal en la misma red que la zona privada que está probando.
Determinar que su máquina virtual está utilizando:
gcloud compute instances describe VM_NAME \
--zone=GCE_ZONE \
--format="csv[no-heading](networkInterfaces['network'])"
Asegúrese de que la red esté en la lista de redes autorizadas para consultar su zona privada:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv(privateVisibilityConfig['networks'])"
Verifique que el nombre DNS en la consulta coincida con su zona
Google Cloud Resuelve un registro según el orden de resolución de nombres , utilizando la zona con el sufijo más largo para decidir qué zona consultar para un nombre DNS determinado. Asegúrese de que el sufijo del registro que está consultando coincida con al menos una zona privada accesible en su red de VPC. Por ejemplo, Google Cloudprimero busca myapp.dev.gcp.example.lan en una zona que sirva dev.gcp.example.lan , si es accesible, antes de buscarlo en una zona que sirva gcp.example.lan , si es accesible.
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 del nombre DNS mediante el servidor de metadatos
Utilice dig para enviar la consulta del nombre DNS directamente a Google Cloudservidor de metadatos, 169.254.169.254 :
dig DNS_NAME @169.254.169.254
Utilice dig para consultar el servidor de nombres predeterminado de la máquina virtual:
dig DNS_NAME
Si la salida de los dos comandos dig genera respuestas diferentes, revise la sección ;; SERVER: del segundo comando. El servidor que responde debe ser el servidor de metadatos, 169.254.169.254 . De no ser así, ha configurado el sistema operativo invitado para usar un servidor de nombres DNS personalizado en lugar del predeterminado.Google Cloud Servidor de metadatos. Las zonas privadas de Cloud DNS requieren el uso del servidor de metadatos para la resolución de nombres. Tanto el entorno invitado de Linux como el de Windows lo hacen automáticamente. Si ha importado la imagen que utiliza para una máquina virtual, verifique que se haya instalado el entorno invitado adecuado.
Las zonas privadas no se resuelven a través de Cloud VPN o Cloud Interconnect
Primero, asegúrese de poder consultar y resolver con éxito el nombre DNS desde una red VPC autorizada .
Verificar la conectividad a través de Cloud VPN o Cloud Interconnect
Asegúrese de que la conectividad desde un sistema local a su red de VPC esté operativa. En concreto, el tráfico TCP y UDP en el puerto 53 debe poder salir de su red local y dirigirse a su red de VPC. Verifique la configuración de los firewalls locales para asegurarse de que dicho tráfico de salida esté permitido.
Puede usar cualquier protocolo, como ping (ICMP), para probar la conectividad a una máquina virtual de muestra en su red de VPC desde las instalaciones locales. Aunque las solicitudes de DNS en la nube no se envían a... Google Cloud Máquinas virtuales: probar la conectividad con una máquina virtual de muestra permite verificar la conectividad mediante un túnel VPN en la nube o una conexión de Cloud Interconnect. Asegúrese de configurar una regla de firewall de permiso de entrada adecuada para la muestra.Google Cloud VM porque la regla de denegación de ingreso implícita bloquea todo el tráfico entrante de lo contrario.
Asegúrese de que el reenvío entrante esté habilitado para la red VPC autorizada
El reenvío entrante debe estar habilitado para cada red VPC autorizada a consultar su zona privada de Cloud DNS. Use el siguiente comando para listar todas las políticas:
gcloud dns policies list
Identifique la red en la tabla de salida y verifique el campo Reenvío para ver si el reenvío está habilitado.
Asegúrese de que la red autorizada sea una red VPC
El reenvío de DNS requiere subredes, que solo están disponibles para redes VPC , no para redes heredadas .
gcloud compute networks list \
--format="csv[no-heading](name, SUBNET_MODE)"
Las redes heredadas se identifican en la salida como LEGACY .
Asegúrese 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 su proyecto.
gcloud compute addresses list \
--filter="purpose=DNS_RESOLVER" \
--format='csv[no-heading](address, subnetwork)'
Puede agregar una cláusula AND al filtro para limitar la salida únicamente a la subred que le interesa.
Ejemplo:
--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME "
Si no ve una dirección IP en la red/región que esperaba, envíe un ticket a Google Cloud Apoyo .
Ejecute el comando dig apuntando la consulta a la dirección que encontró en el comando anterior. Hágalo desde una máquina virtual en la misma red. Esta prueba verifica que el reenvío de entrada funciona y que el problema reside en otra parte.
dig DNS_NAME @10.150.0.1 # address returned by previous command
Repita 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 busca registros CNAME como se describe en Búsqueda de CNAME .
Zonas de búsqueda inversa
Esta sección ofrece consejos para la solución de problemas de zonas de búsqueda inversa. Algunos problemas de zonas privadas también afectan a estas zonas. Para obtener más consejos, consulte la sección "Solución de problemas de zonas privadas" .
La máquina virtual con una dirección que no es RFC 1918 no se resuelve
Concilie su máquina virtual con una dirección que no sea RFC 1918
Si creó 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, reinicie las máquinas virtuales.
Zonas de reenvío
Esta sección ofrece consejos para la solución de problemas de zonas de reenvío. Algunos problemas de zonas privadas también afectan a las zonas de reenvío. Para obtener más consejos, consulte la sección "Solución de problemas de zonas privadas" .
Las zonas de reenvío (reenvío de salida) no funcionan
Primero, asegúrese de poder consultar y resolver con éxito el nombre DNS desde una red VPC autorizada .
El reenvío de consultas desde máquinas virtuales en una red VPC de consumidor a una red VPC de productor no funciona
Si está usando emparejamiento de DNS y desea reenviar consultas desde máquinas virtuales en una red de VPC de consumidor a una red de VPC de productor y, luego, a uno o más servidores de nombres locales, asegúrese de que se cumpla uno de los siguientes requisitos previos:
La red VPC del productor tiene su modo de enrutamiento dinámico configurado en
GLOBALLa máquina virtual en la red VPC del consumidor está 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 de productor tiene una ruta estática configurada para enviar el tráfico a los servidores de nombres locales a través del túnel VPN clásica. La red de VPC de productor también debe tener una máquina virtual o un túnel VPN en la misma región que la subred utilizada por las máquinas virtuales cliente.
Por ejemplo, supongamos que la VPC1 utiliza una zona de peering que envía consultas de
example.com.a la VPC2. Supongamos también que la VPC2 tiene una zona de reenvío privada deexample.com.que reenvía las consultas a un servidor de nombres local mediante un túnel VPN clásico.Para que una máquina virtual ubicada en
us-east1de la VPC1 pueda consultarexample.com., la VPC2 debe tener una máquina virtual ubicada enus-east1. También se debe configurar una ruta estática que cubra los rangos CIDR de los servidores de nombres locales, con el siguiente salto configurado como el túnel VPN clásico.
Verificar la conectividad a través de Cloud VPN o Cloud Interconnect
Puede usar cualquier protocolo, como ping (ICMP), para probar la conectividad a una máquina virtual de muestra en su red de VPC desde la configuración local. También debe intentar consultar su servidor de nombres local directamente desde una muestra.Google Cloud VM usando una herramienta como dig :
dig DNS_NAME @192.168.x.x # address of the onprem DNS server
Verifique las reglas del firewall en su red VPC
La regla de firewall de permiso de salida implícita permite conexiones salientes y respuestas establecidas desde las máquinas virtuales de su red de VPC, a menos que haya creado reglas personalizadas para denegar la salida. Si ha creado reglas personalizadas de denegación de salida, deberá crear reglas de permiso de mayor prioridad que permitan la salida, al menos, a sus servidores de nombres locales.
Comprobar el firewall local
Asegúrese de que su firewall local esté configurado para permitir el tráfico entrante y saliente hacia35.199.192.0/19 .
Verifique los registros en su firewall local, buscando solicitudes DNS de35.199.192.0/19 Para usar una expresión regex para buscar, utilice lo siguiente:
"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"
Comprobar el servidor de nombres local
Verifique que no tenga ninguna ACL configurada en su servidor de nombres local que pueda bloquear las consultas desde35.199.192.0/19 .
Verifique su servidor de nombres local para ver si está recibiendo paquetes de35.199.192.0/19 Si tiene acceso a shell, puede usar una herramienta como tcpdump para buscar paquetes entrantes y salientes.35.199.192.0/19 :
sudo tcpdump port 53 and tcp -vv
Verificar rutas de retorno
Su red local debe tener una ruta a la35.199.192.0/19 Destino, con el siguiente salto como túnel VPN o conexión de interconexión para la misma red VPC que envió la solicitud DNS. Este comportamiento se describe en la sección "Creación de zonas de reenvío" .
Si utiliza varios túneles VPN para conectar la misma red VPC a su red local, no es necesario que la respuesta se entregue mediante el mismo túnel que la envió. Sin embargo, debe entregarse mediante un túnel VPN con un siguiente salto en la misma red VPC desde la que se originó la solicitud.
Si ha conectado más de una red VPC a su red local, debe asegurarse de que las respuestas de DNS no se envíen a la red incorrecta. Google Cloud Descarta las respuestas DNS enviadas a la red VPC incorrecta. Para obtener una solución recomendada, consulte nuestra guía de prácticas recomendadas .
El reenvío saliente a un servidor de nombres que utiliza una dirección IP que no es RFC 1918 falla
De forma predeterminada, Cloud DNS utiliza el enrutamiento estándar, que enruta las consultas a través de la red pública de internet cuando el servidor de nombres de destino tiene una dirección IP distinta a la RFC 1918. El enrutamiento estándar no permite el reenvío de consultas a servidores de nombres con direcciones distintas a la RFC 1918 a las que no se puede acceder desde la red pública de internet.
Para reenviar consultas a un servidor de nombres que utiliza una dirección IP que no sea RFC 1918 a través de su red VPC, configure la zona de reenvío de DNS de Cloud o la política del servidor para utilizar enrutamiento privado para el servidor de nombres de destino.
Para obtener una explicación de las diferencias entre el enrutamiento estándar y privado, consulte destinos de reenvío y métodos de enrutamiento .
Esta limitación se aplica incluso si hay una ruta VPC para el servidor de nombres de destino; las rutas para direcciones que no sean RFC 1918 no tienen efecto en el comportamiento de reenvío saliente de Cloud DNS cuando se configura el enrutamiento estándar.
El reenvío saliente a una NIC secundaria falla
Asegúrese de haber configurado correctamente su controlador de interfaz de red secundaria (NIC).
Para obtener instrucciones sobre cómo configurar NIC adicionales, consulte Creación de instancias de máquinas virtuales con múltiples 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 los servidores de nombres de destino, devuelve un error SERVFAIL .
Para resolver este problema, verifique que sus servidores de nombres locales estén configurados correctamente. Luego, verifique que respondan a las consultas del rango de direcciones de Cloud DNS descrito en Abrir. Google Cloudy firewalls locales para permitir el tráfico DNS en 4 segundos. Si sus servidores de nombres locales consultan a los servidores de nombres ascendentes (por ejemplo, debido a que están configurados como resolutores de caché), verifique que no haya problemas con los servidores de nombres ascendentes.
Además, si el destino del reenvío es un sistema local, tenga en cuenta que las rutas configuradas para esa ruta pueden ser dinámicas o estáticas personalizadas, con la importante excepción de que las rutas estáticas personalizadas con etiquetas de red no son válidas para el reenvío de consultas DNS . Asegúrese de que la ruta utilizada para llegar al servidor de nombres local no especifique una etiqueta de red.
Registros de recursos
Esta sección proporciona sugerencias para la solución de problemas relacionados con los registros de recursos.
Datos inesperados al consultar conjuntos de registros de recursos presentes en la zona
Hay varias razones por las que podrías recibir datos inesperados al consultar conjuntos de registros de recursos presentes en una zona administrada de Cloud DNS:
No se admiten los conjuntos de registros de recursos creados con la sintaxis
@especificada en RFC 1035. Cloud DNS interpreta el símbolo@en estos conjuntos de registros de recursos de forma literal; 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, asegúrese de crear conjuntos de registros sin el símbolo@; todos los nombres son relativos al vértice de la zona.Como 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 a
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 máquina virtual 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 restablecer la funcionalidad, aplique el registro PTR de nuevo.
Para obtener detalles sobre cómo aplicar registros PTR en una máquina virtual, consulte Creación de un registro PTR para una instancia de máquina virtual .
Conjuntos de registros de recursos de Cloud DNS devueltos en orden aleatorio
De acuerdo con las prácticas de la industria DNS, los servidores de nombres DNS en la nube ahora aleatorizan el orden de los conjuntos de registros de recursos e ignoran el orden dado por el servidor autorizado. Este es un comportamiento DNS normal y se aplica a tanto públicos como Zonas DNS de nube privada.
Tipo de recurso zonal no compatible
Al introducir el indicador --location en un comando gcloud o una solicitud de API para una función que se dirige a una zona de Cloud DNS diferente, la solicitud se rechaza. Por ejemplo, si envía una solicitud de función solo zonal a un servidor global, o una solicitud de función solo global a un servidor zonal, el servidor rechaza la solicitud y genera un error _UNSUPPORTED_ZONAL_RESOURCE TYPE .
Para obtener una lista de recursos y características compatibles con el DNS en la nube zonal, consulte Compatibilidad con DNS en la nube zonal .
¿Qué sigue?
- Para obtener más información sobre las funciones, consulte Descripción general de Cloud DNS .
- Para resolver errores, consulte Mensajes de error .
- Para obtener ayuda adicional, consulte Soporte .