Solución de la comunidad

DNS manual de ZimaOS: evita un bucle de dependencia de DNS autohospedado

A ZimaOS host used its own AdGuard container as the only manually configured DNS resolver, causing the AdGuard image update to fail when DNS disappeared.

Conclusión: no hagas que ZimaOS dependa de un contenedor de AdGuard que se ejecute en el mismo host ZimaOS como su único resolvedor DNS

La actualización falló por una razón predecible: ZimaOS necesitaba DNS para descargar la nueva imagen de AdGuard, pero su único servidor DNS configurado era el contenedor de AdGuard que se estaba reiniciando o reemplazando. Esto crea una dependencia circular. Un segundo campo DNS mejoraría la resiliencia, pero la arquitectura no debería depender del servicio que se está actualizando para resolver el servidor de actualización.

La documentación actual de ZimaOS todavía describe un único campo manual para el servidor DNS

La guía de configuración de red de ZimaOS de septiembre de 2026 describe el modo manual con dirección IP, máscara de subred, puerta de enlace y servidor DNS en singular. La guía pública no documenta actualmente varias entradas DNS en la interfaz gráfica, así que no des por hecho que la solicitud de funciones de 2025 se haya implementado.

Usa un resolvedor independiente para el host ZimaOS

Un diseño limpio es:

  • Host ZimaOS → router/proveedor de Internet/Cloudflare/otro resolvedor independiente.
  • Clientes de la LAN → AdGuard Home para el filtrado.
  • Servidor ascendente de AdGuard → los resolvedores en los que confíes.

Así, AdGuard puede reiniciarse o actualizarse sin impedir que el host resuelva los registros de Docker y los servicios remotos.

La guía de hardware de AdGuard Home explica el papel de la aplicación, mientras que la guía de DNS de Pi-hole refuerza la misma separación entre el filtrado DNS de los clientes y las dependencias de infraestructura del host.

El DNS secundario no siempre implica una conmutación por error estricta

Muchos sistemas operativos y resolvedores pueden consultar varios servidores DNS configurados en lugar de tratar el segundo como «solo si el primero no funciona». Por eso, si todos los clientes deben estar filtrados, proporcionarles un resolvedor público como secundario puede permitir que algunas consultas eviten AdGuard. Coloca la redundancia detrás de la capa de filtrado o mantén el resolvedor independiente únicamente en los hosts de infraestructura.

Referencias de resolvedores públicos

Cloudflare documenta sus direcciones del resolvedor 1.1.1.1, y Google documenta la configuración de Google Public DNS. Usa la opción que mejor se ajuste a tus requisitos de privacidad, filtrado y disponibilidad.

Prueba rápida antes de actualizar un contenedor DNS local

nslookup registry-1.docker.io
nslookup github.com

Después, detén temporalmente el contenedor de AdGuard y repite la consulta desde el host ZimaOS. Si el DNS deja de funcionar, el host todavía tiene una dependencia circular que puede interrumpir la próxima actualización del contenedor DNS.