¿Cuáles son las causas de fallos intermitentes de DNS en aplicaciones autoalojadas?
Las fallas intermitentes de DNS ocurren cuando la ruta del resolvedor de la aplicación cambia, se agota el tiempo, se sobrecarga o devuelve respuestas en caché inconsistentes.
En una pila autoalojada, la búsqueda fallida puede pasar por el tiempo de ejecución de la aplicación, el stub DNS del contenedor, el resolvedor del host, el router, Pi-hole o AdGuard Home, la política VPN y un servidor público o autoritativo ascendente. Una prueba del navegador desde el host no puede demostrar que la aplicación vea la misma ruta, por lo que el diagnóstico debe capturar el nombre fallido dentro del contenedor o servicio afectado y compararlo con una consulta exitosa en el mismo momento.
Capture la Consulta Fallida Dentro del Entorno de la Aplicación Afectada
Registre el nombre de host exacto, el texto del error, la marca de tiempo, el contenedor o proceso, y si la falla afecta nombres internos, nombres públicos o ambos. Realice búsquedas repetidas desde dentro del entorno afectado en lugar de depender solo de pruebas a nivel de host.
Un problema de Kubernetes documentó fallas intermitentes donde la primera consulta DNS agotó el tiempo mientras que consultas posteriores tuvieron éxito. Ese patrón muestra por qué una búsqueda exitosa después del incidente no puede explicar una falla transitoria del resolvedor.
Registre la duración de la consulta, el servidor que respondió, el código de respuesta y el resultado del reintento. Si solo un nombre falla, inspeccione esa zona o autoridad; si todos los nombres fallan juntos, enfoque en el stub local, el resolvedor ascendente o la ruta de red.
Compare el DNS del Host con el DNS del Contenedor o Servicio
Inspeccione la configuración del resolvedor dentro del contenedor, VM o sandbox de la aplicación y compárela con los servidores DNS activos del host. Los entornos de contenedores pueden proporcionar un stub embebido o copiar un resolv.conf generado en lugar de exponer directamente el resolvedor del host.
Un caso de la comunidad HashiCorp mostró que el DNS funcionaba en el host pero no en el contenedor porque el listener systemd-resolved del host no era accesible desde el puente, requiriendo un listener de resolvedor extra en una dirección que el contenedor pudiera consultar.
Consulte directamente el servidor de nombres configurado desde ambos entornos. Si el host tiene éxito mientras el contenedor agota el tiempo contra un stub de loopback o inaccesible, corrija la ruta del resolvedor visible desde el puente en lugar de reiniciar la aplicación repetidamente.
Separe las Fallas de Zona Interna de las Fallas de DNS Público
Pruebe un nombre público estable y un nombre de servicio interno requerido durante la misma ventana de falla. La falla solo interna apunta a DNS dividido, dominios de búsqueda, registros autoritativos locales o reenvío condicional; la falla de ambos apunta a la ruta recursiva.
Un reporte en el foro de Docker describe un DNS que debería resolverse consistentemente pero fallaba sin un patrón claro durante las compilaciones. Por lo tanto, el DNS del contenedor puede fallar incluso cuando la red de la aplicación sigue siendo accesible.
Si los nombres públicos funcionan pero falla un nombre interno de la aplicación, consulte directamente el servidor autoritativo local y use el dominio completo en lugar de un nombre corto con sufijo de búsqueda. Si ambos fallan, evite temporalmente el filtro local con un resolvedor conocido para identificar si la falla está en el upstream o dentro de la red doméstica.
Mida los Tiempos de Espera del Resolvedor, la Carga y el Comportamiento UDP a TCP
Ejecute consultas temporizadas repetidas directamente contra cada resolvedor en la cadena y compare UDP con TCP. Controle la pérdida de paquetes, tiempo de respuesta, SERVFAIL, tiempo de espera, truncamiento y si las fallas coinciden con trabajos de respaldo, actualizaciones de filtrado o alto uso de CPU.
Una guía para solucionar problemas intermitentes de DNS recomienda capturar las fallas a medida que ocurren y separar la inestabilidad del resolvedor de la pérdida de red en lugar de cambiar varios servidores DNS a la vez.
Si un resolvedor agota el tiempo mientras otro responde inmediatamente, mantenga fija la ruta de la aplicación y reemplace o repare el resolvedor que falla. Si todos los resolvedores fallan simultáneamente desde el contenedor pero no desde el host, regrese a revisar el puente, firewall, conntrack y comportamiento del namespace.
Verifique Renovaciones DHCP, Políticas VPN y Cambios en el Resolvedor a lo Largo del Tiempo
Compare la configuración DNS antes y después de la renovación DHCP, cambios en la conexión VPN, suspensión del host, reinicio del router o recreación del contenedor. Las fallas intermitentes a menudo siguen a un evento del ciclo de vida que reemplaza silenciosamente el resolvedor o el dominio de búsqueda.
Un usuario de Docker rastreó un problema aparentemente aleatorio a la renovación del arrendamiento DHCP y otro a la interacción entre Docker y Tailscale. Ese tipo de evidencia temporal es más sólida que asumir que el resolvedor falla aleatoriamente.
Guarde la lista de resolvedores, rutas, dominios de búsqueda y estado VPN antes y después del evento. Corrija la fuente que los reescribe—DHCP, NetworkManager, systemd-resolved, el cliente VPN o el entorno de contenedores—en lugar de codificar un resolvedor público que no puede responder nombres internos.
Valide la Solución Durante la Ventana Original de Fallas
Ejecute una búsqueda programada desde dentro del entorno de la aplicación por más tiempo que el intervalo que normalmente produce fallas. Registre el resolvedor usado, latencia, código de respuesta y resultado a nivel de aplicación en lugar de registrar solo consultas exitosas desde la línea de comandos.
La guía de ZimaSpace sobre resolución inconsistente de nombres NAS cubre el problema adyacente del lado cliente; esta prueba enfocada en la aplicación debe además demostrar que el contenedor y el tiempo de ejecución usan continuamente el resolvedor previsto.
El problema se considera resuelto solo cuando la operación original de la aplicación se completa a través de reinicios del router, renovaciones de arrendamiento, recreación del contenedor y cambios en el estado VPN que antes provocaban la falla. Si los reinicios solo reinician el temporizador, siga recopilando el estado en el momento de la falla en lugar de aceptar el reinicio como la reparación.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
