Cuando el DNS público de Google no puede resolver un dominio, a menudo se debe a un problema con ese dominio o con sus servidores de nombres autorizados. Los siguientes pasos pueden ayudar a determinar la causa del problema, de modo que los administradores de dominio puedan resolverlo por su cuenta.
Antes de comenzar con estos pasos, verifica el dominio en dns.google como se describe en la página de solución de problemas generales, que puede hacer referencia a un paso de diagnóstico en particular a continuación. De lo contrario, prueba los siguientes pasos hasta que encuentres la causa.
Paso 1: Verifica si hay problemas de validación de DNSSEC
Si las búsquedas web dns.google para el dominio muestran "Status": 2 (SERVFAIL) y las consultas sin DNSSEC se realizan correctamente, puede haber un problema de DNSSSEC con los servidores de nombres del dominio o su registro de dominio de nivel superior (TLD) (que publica registros DS para la validación de DNSSEC de dominios registrados).
- Cambios en el servicio de registrador o DNS
Los problemas de DNSSEC pueden ocurrir después de que un dominio cambia de un registrador o servicio DNS que admite DNSSEC a uno que no lo hace. Si el servicio anterior deja registros
DSinactivos en el registro TLD y el servicio nuevo no crea registrosDNSKEYnuevos con registrosDScoincidentes en el registro TLD, la validación de los agentes de resolución como el DNS público de Google no pueden resolver el dominio.Si esto sucede, solicita a tu registrador de dominio que quite los registros DS inactivos del registro de TLD.
- Las respuestas de DNSSEC son demasiado grandes
Otra causa de problemas de DNSSEC son las respuestas de DNSSEC que son demasiado grandes para caber en un paquete de IP, lo que crea respuestas fragmentadas que pueden descartarse. Si DNSViz muestra que no se recibió ninguna respuesta hasta que se redujo el tamaño de la carga útil de UDP, las fallas de DNSSEC pueden deberse a respuestas muy grandes. Los tamaños de las respuestas se pueden reducir mediante una o más de las siguientes acciones:
- Configurar &minit;respuestas mínimas para servidores de nombres autorizados
- Reduce la cantidad de registros
DNSKEYactivos a dos o tres. - Use registros
DNSKEYde 1,280 o 2,048 bits (RFC 6781, StackExchange). - Cambiar de firmas RSA a firmas ECDSA más pequeñas (RFC 8624)
También revise los otros problemas de DNSSEC que informaron las herramientas en el paso 2. Los ejemplos incluyen registros incorrectos de denegación de existencia de NSEC o NSEC3 que prueban que no hay subdominios (PowerDNS con zonas almacenadas en bases de datos externas puede tenerlas) o firmas RRSIG vencidas (con procesos de firma rotos configurados de forma manual).
Paso 2: Verifique los servidores de nombres autorizados
Si el DNS público de Google (o cualquier agente de resolución abierto) tiene un problema para resolver un dominio, DNSViz muestra los problemas del dominio y del servidor de nombres que lo causan. Ve a la página web de DNSViz e ingresa el nombre del dominio problemático. Si DNSViz no tiene datos históricos o solo tiene datos que tengan más de un día de antigüedad (como se muestra en la página aquí), haz clic en el botón Analizar grande para mostrar un botón Analizar más pequeño a continuación (si aún no está visible) y haz clic en él. Cuando se complete el análisis, haga clic en "Continuar" para mostrar los resultados. Haz clic en los errores rojos y las advertencias amarillas en la barra lateral izquierda para revelar detalles o mantén el puntero sobre los objetos del diagrama a fin de mostrar esa información en contexto.
Si en un diagnóstico anterior se indicaron posibles problemas de DNSSEC con el dominio, ve a la página web del Analizador de DNSSEC y, luego, ingresa el nombre de dominio. Si este analizador informa errores o advertencias de DNSSEC, mantén el puntero sobre los íconos rojos
La página web intoDNS informa sobre problemas que no son de DNSSEC con el dominio ingresado en la página principal y también muestra sugerencias para solucionarlos.
Los administradores de dominio deben corregir la mayoría de los errores que informan estas herramientas, ya que pueden causar problemas no solo para el DNS público de Google, sino también para otros agentes de resolución.
Paso 3: Verifica si hay problemas de delegación
El DNS público de Google es un agente de resolución “centrado en el elemento superior” que solo usa los servidores de nombres que se muestran en las referencias del dominio superior. Si los nombres del servidor de nombres y las direcciones de unión en el TLD están inactivos o son incorrectos, esto puede causar problemas de delegación.
Si DNSViz o inDNS informan advertencias sobre inconsistencias entre los servidores de nombres delegados en el TLD y los presentes en el dominio secundario, es posible que se deban abordarlos antes de que el DNS público de Google pueda resolver el dominio. Si estas herramientas informan que el dominio registrado no existe (NXDOMAIN), verifica que el dominio no esté vencido o que esté suspendido por algún motivo.
Los problemas de delegación también pueden deberse a una falla en la resolución de los nombres de los servidores de nombres de un dominio. Revisa los registros A y AAAA de los servidores de nombres en dns.google para ver si hay problemas con los servidores de nombres.
Paso 4: Verifica si hay respuestas grandes
El DNS se basa en UDP para transportar la mayor parte de su tráfico. Los datagramas UDP grandes están sujetos a fragmentación y el UDP fragmentado sufre una entrega poco confiable. Este fue el foco del Día de la Bandera de DNS 2020, un esfuerzo para mejorar la confiabilidad del DNS a nivel global. El DNS público de Google participó en este esfuerzo y limita el tamaño de las respuestas UDP que aceptará en comparación con UDP. Prueba una consulta como la que se muestra a continuación, con tu propio símbolo del sistema o con Google Cloud Shell:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
Estas consultas para varios tipos de registros especifican:
+dnssec- Habilita DNSSEC, en especial si se muestran los registros necesarios para la validación de DNSSEC cuando estén disponibles. Pueden expandir el tamaño del resultado de manera significativa. Esto emula el comportamiento del DNS público de Google.
+bufsize=1400- Limita el tamaño de búfer UDP permitido. Esto emula el comportamiento del DNS público de Google a partir del esfuerzo de la marca de DNS de 2020.
+timeout=1- Establece el tiempo de espera en un segundo. Esto emula el comportamiento del DNS público de Google.
@ns1.example.com- Qué servidor autorizado consultar: conserva el signo
@, pero reemplázalo con el servidor autorizado de tu propio dominio, como se muestra en el primer comando.
Observe el resultado. ¿Ve una línea como la siguiente?
;; Truncated, retrying in TCP mode.- Esto indica que la respuesta era más grande que el tamaño del búfer UDP solicitado, por lo que se truncó y, en respuesta, el cliente cambió a TCP. Tus servidores autorizados deben ser capaces de manejar el tráfico de DNS en el puerto TCP 53. (Consulta la RFC 7766, que exige que las implementaciones DEBEN admitir el transporte UDP y TCP).
;; MSG SIZE rcvd: 2198- ¿Para algún número superior a 1400? Una vez más, esto indica una respuesta grande.
;; Query time: 727 msec- ¿Para algún número superior a 500? Es posible que el DNS público de Google descarte las respuestas lentas (especialmente las que se encuentran cerca de 1 segundo). Esto es muy probable si se dedicó algún tiempo a un intento de UDP, seguido de un intento de TCP. La ubicación geográfica del servidor y del cliente puede afectar en gran medida la latencia.
;; connection timed out; no servers could be reached- En especial cuando se trata solo de algunas consultas, esto indica un problema por el que tu servidor no puede responder las consultas de DNS de manera oportuna.
Puedes probar las siguientes variaciones de consulta:
- Agrega un parámetro
+tcp. - Esto obliga a
diga usar TCP de forma inmediata. Puedes verificar si tu servidor autorizado controla las consultas de TCP directamente de esta manera. - Quitar el parámetro
+bufsize=1400. - Esta acción restablecerá el comportamiento predeterminado de
dig(un bufsize de 4096). Si tus consultas fallan con esta configuración, pero funcionan sin ella, esto indica que tu servidor no controla la conmutación por error de TCP. Depender de UDP para llevar respuestas grandes solo funciona a veces. El mejor procedimiento es admitir el transporte TCP para DNS. - Se repite en cada servidor de nombres.
- El ejemplo anterior tiene dos servidores de nombres autorizados (
ns1yns2). Algunos problemas son causados por diferentes servidores que muestran respuestas diferentes. Para verificar que todas respondan de manera coherente, repite las mismas consultas en todos los servidores autorizados.
Si todas las respuestas son pequeñas (1,400 bytes o menos), rápidas (preferentemente, 500 milisegundos o más rápidas) y confiables (funcionan de forma coherente en TCP y UDP), el tamaño de la respuesta no es tu preocupación; lee las otras secciones de solución de problemas. Incluso si tus respuestas son rápidas, las consultas desde lejos geográficamente podrían ser más lentas.
Si alguna de estas verificaciones falló (¿gran? ¿lenta? ¿No es confiable?), el curso de acción principal es A) asegúrate de que tu servidor responda con el truncamiento de UDP, cuando su respuesta exceda el tamaño de búfer UDP solicitado y B) que pueda manejar el reintento de consulta de TCP que sigue. Hay varias herramientas que pueden ayudarte a diagnosticar problemas de confiabilidad de DNS:
- DNSViz
- Depurador de DNSSEC
- Verificador de cumplimiento de EDNS
- DNS Checker: asegúrate de desmarcar la casilla "CD" (inhabilitar marca de DNSSEC)
Si estas herramientas revelan errores o advertencias, asegúrese de solucionarlos. Además, asegúrate de leer todas las demás instrucciones de solución de problemas de este sitio.
Paso 5: Verifica si otros agentes de resolución públicos resuelven el dominio
Si no encontraste ninguna causa del problema después de seguir los pasos anteriores, ejecuta los siguientes comandos en un símbolo del sistema y reemplaza example.test. por el dominio en cuestión (y conserva los puntos finales):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS o Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
Estos comandos usan los agentes de resolución de DNS de OpenDNS, Quad9 y Cloudflare 1.1.1.1. Si recibes fallas de resolución de dos de estos y del DNS público de Google, es probable que el problema sea con el dominio o sus servidores de nombres.
Si obtienes un resultado correcto de más de un agente de resolución público, es posible que haya un problema con el DNS público de Google. Si no se informaron problemas similares para el dominio (o su TLD) en la herramienta de seguimiento de errores, debes informarnos el problema, incluido el resultado del comando y el texto de la página de diagnóstico o capturas de pantalla.