Perché la risoluzione DNS funziona sull’host ma non all’interno di un container?
Il DNS dell’host può funzionare mentre quello del container non funziona perché il container utilizza un percorso di risoluzione, uno spazio dei nomi, un instradamento del firewall o uno stato di inoltro di Docker differenti.
Su un home server, l’host può interrogare direttamente un router, Pi-hole o un resolver VPN, mentre un container con rete bridge invia le richieste tramite il resolver incorporato di Docker o un file resolv.conf copiato. La diagnosi più rapida verifica prima un indirizzo IP, quindi interroga esplicitamente ogni resolver dal container che presenta il problema, così da non confondere un errore DNS con un problema generale di connettività in uscita.
Distinguere un errore DNS da un problema di rete generale
Dal container che presenta il problema, verifica un IP esterno noto e l’indirizzo IP del server DNS previsto prima di testare qualsiasi nome host. Registra le route, la perdita di pacchetti e l’eventuale raggiungibilità della porta 53 tramite TCP e UDP.
Un caso relativo a un container Manjaro mostra il ramo opposto: anche il traffico verso IP diretti non funzionava, dimostrando che il problema era più ampio del DNS. Questo test di connettività verso IP diretto evita che le modifiche al resolver nascondano un bridge, un NAT o un percorso del firewall non funzionante.
Se la connettività IP non funziona, ripara prima la rete del container. Se l’IP funziona ma i nomi no, continua esaminando la configurazione del resolver e il percorso delle query.
Controllare la configurazione del resolver nel container
Leggi /etc/resolv.conf all’interno del container e confrontalo con quello dell’host. Annota gli indirizzi dei nameserver, i domini di ricerca, le opzioni, la modalità di rete e l’eventuale modifica del file dopo la ricreazione.
In un caso relativo a OpenMediaVault, le ricerche DNS del container non funzionavano tramite il resolver incorporato di Docker 127.0.0.11 dopo un aggiornamento del runtime. Questo percorso del resolver incorporato può differire da quello utilizzato con successo dall’host.
Non modificare in modo permanente il file generato all’interno di un container in esecuzione. Specifica i server DNS e i domini di ricerca desiderati nella configurazione di Compose o della piattaforma, così che vengano mantenuti dopo la ricreazione.
Interrogare separatamente il DNS di Docker e il resolver upstream
Esegui la stessa ricerca verso il resolver incorporato di Docker, il router o il server DNS locale e, quando consentito dalle policy, un resolver esterno noto. Confronta timeout, rifiuti, NXDOMAIN e indirizzi restituiti.
Un caso della community TrueNAS ha ricondotto un errore DNS limitato ai container a un profilo di accesso del router che bloccava le richieste, anche se altro traffico dell’host funzionava. L’osservazione decisiva era il blocco del DNS sul percorso del container, non un nome host non valido.
Se le query dirette verso l’upstream funzionano ma il resolver incorporato non funziona, riavvia o ripara il resolver e lo stato di rete di Docker. Se tutti i server DNS vanno in timeout, controlla l’instradamento sulla porta 53, il firewall, la VPN e il traffico di risposta.
Controllare i loop DNS locali e le risposte interne errate
Stabilisci se il container sta tentando di interrogare un servizio DNS sullo stesso host, un altro container o un nome host che viene risolto nuovamente tramite il reverse proxy. Acquisisci la risposta invece di presumere che ogni ricerca riuscita sia corretta.
Un caso della community Traefik ha rilevato che un container risolveva un dominio personalizzato verso sé stesso anziché verso il peer previsto. Questa risposta DNS errata dal container superava un test di risoluzione di base, ma impediva comunque la connessione all’API.
Usa i nomi dei servizi per il traffico tra container sulla stessa rete e il DNS split-horizon per i nomi host pubblici solo quando il percorso di ritorno è intenzionale. Evita i percorsi hairpin che inviano un container attraverso il proxy pubblico per raggiungere una dipendenza locale, a meno che tale percorso non sia stato testato esplicitamente.
Verificare le risposte UDP, il NAT e l’isolamento di rete
Acquisisci il traffico sulla porta 53 sull’interfaccia del container e sul bridge dell’host. Conferma che la query parta, che il resolver la riceva e che la risposta ritorni dall’indirizzo previsto dal client.
Gli utenti di Pi-hole hanno documentato timeout nelle query tra container sullo stesso host perché le risposte ritornavano da una sorgente tradotta inattesa. Questa sorgente DNS di risposta inattesa distingue un problema del percorso di risposta da un resolver che non risponde.
Se la richiesta e la risposta attraversano reti Docker diverse, aggiungi la rete condivisa o la route corretta invece di spostare tutti i servizi sulla rete dell’host. Controlla le zone del firewall e le policy VPN che potrebbero trattare le subnet bridge in modo diverso dall’indirizzo dell’host.
Ricreare lo stato della rete e verificare la correzione
Dopo aver corretto il resolver, il firewall o la definizione di rete, ricrea un container di test sulla rete prevista e ripeti i test verso IP, resolver diretto, resolver incorporato, nome del servizio e nome pubblico.
La guida di ZimaSpace su distinguere i problemi di indirizzi da quelli dei nomi offre il confine diagnostico complementare dal lato dell’host.
Il problema è risolto solo quando la configurazione DNS persiste dopo la ricreazione e il riavvio, i nomi dei servizi interni e i nomi pubblici autorizzati restituiscono gli indirizzi previsti e il traffico dell’applicazione funziona attraverso lo stesso percorso di rete. Se il problema ricompare solo dopo un aggiornamento di Docker, conserva la versione e i log del demone per definire il confine di una regressione del runtime.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
