Soluzione della community

DNS manuale di ZimaOS: evita un loop di dipendenza dal DNS autogestito

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.

In sintesi: non rendere ZimaOS dipendente da un container AdGuard in esecuzione sullo stesso host ZimaOS come unico resolver DNS

L’aggiornamento non è riuscito per un motivo prevedibile: ZimaOS aveva bisogno del DNS per scaricare la nuova immagine di AdGuard, ma l’unico server DNS configurato era il container AdGuard che stava per essere riavviato o sostituito. Questo crea una dipendenza circolare. Un secondo campo DNS migliorerebbe la resilienza, ma l’architettura non dovrebbe dipendere dal servizio in fase di aggiornamento per risolvere l’indirizzo del server di aggiornamento.

La documentazione attuale di ZimaOS descrive ancora un unico campo DNS manuale

La guida alla configurazione di rete di ZimaOS di settembre 2026 descrive la modalità manuale indicando indirizzo IP, maschera di sottorete, gateway e server DNS al singolare. La guida pubblica non documenta attualmente più voci DNS nell’interfaccia grafica, quindi non presumere che la richiesta di funzionalità del 2025 sia stata implementata.

Usa un resolver indipendente per l’host ZimaOS

Una configurazione corretta è:

  • Host ZimaOS → router/provider Internet/Cloudflare/un altro resolver indipendente.
  • Client della LAN → AdGuard Home per il filtraggio.
  • Upstream di AdGuard → i resolver di cui ti fidi.

In questo modo AdGuard può essere riavviato o aggiornato senza impedire all’host di risolvere i nomi dei registri Docker e dei servizi remoti.

La guida ai requisiti hardware di AdGuard Home descrive il ruolo dell’app, mentre la guida DNS di Pi-hole ribadisce la stessa separazione tra il filtraggio DNS dei client e le dipendenze dell’infrastruttura dell’host.

Il DNS secondario non garantisce sempre un failover rigoroso

Molti sistemi operativi e resolver possono interrogare più server DNS configurati invece di trattare il secondo come “da usare solo se il primo non è disponibile”. Quindi, se vuoi che ogni client venga filtrato, configurare un resolver pubblico come DNS secondario può consentire ad alcune richieste di bypassare AdGuard. Colloca la ridondanza dietro il livello di filtraggio oppure mantieni il resolver indipendente solo sugli host dell’infrastruttura.

Riferimenti ai resolver pubblici

Cloudflare documenta gli indirizzi del resolver 1.1.1.1, mentre Google documenta la configurazione di Google Public DNS. Usa quello più adatto ai tuoi requisiti di privacy, filtraggio e disponibilità.

Test rapido prima di aggiornare un container DNS locale

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

Quindi arresta temporaneamente il container AdGuard e ripeti la ricerca dall’host ZimaOS. Se il DNS smette di funzionare, l’host ha ancora una dipendenza circolare che può interrompere il prossimo aggiornamento del container DNS.