Unbound può essere attivo in systemctl e non servire a nessuna richiesta della macchina. Su una VM Debian o Ubuntu, il sintomo è banale: il servizio è in esecuzione, ma le richieste DNS rimangono lente, o un’applicazione non risolve più nulla.
Prima di modificare /etc/resolv.conf o di disturbare systemd-resolved, esegui prima una diagnosi locale. Controlla la configurazione e la porta, poi interroga Unbound direttamente. Il DNS del sistema rimane intatto durante questi controlli.
Leggere la configurazione prima di toccare la porta 53
Su Debian e Ubuntu, la configurazione principale passa spesso attraverso /etc/unbound/unbound.conf, con inclusioni in /etc/unbound/unbound.conf.d/. Non dare per scontato che Unbound ascolti su 127.0.0.1:53.
La porta 53 potrebbe già essere occupata da systemd-resolved, dnsmasq o BIND. Il rischio è semplice: cambiando il risolutore di sistema troppo presto, puoi interrompere la risoluzione DNS della macchina mentre Unbound non ascolta nel posto giusto.
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo unbound-checkconf -o interface /etc/unbound/unbound.conf
sudo unbound-checkconf -o port /etc/unbound/unbound.conf
sudo ss -lntup 'sport = :53'unbound-checkconf legge la configurazione e restituisce un errore se una diretiva blocca il caricamento. Secondo la pagina di manuale ufficiale, un codice di ritorno 0 convalida il file. Le opzioni -o interface e -o port visualizzano i valori effettivi.
ss mostra il processo che ascolta realmente. Se vedi 127.0.0.53:53 da parte di systemd-resolved mentre Unbound dovrebbe rispondere su 127.0.0.1:53, hai un conflitto concreto da affrontare.
Prima di una modifica, conserva una copia leggibile del file principale:
sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.before-local-testInterrogare Unbound senza cambiare il DNS della macchina
Un servizio attivo non è sufficiente. Unbound può ascoltare su un’altra interfaccia, utilizzare un’altra porta, o rispondere negativamente perché i server upstream o DNSSEC pongono problemi.
Lo stato del servizio e i log dell’avvio in corso danno il primo riscontro. Invia quindi una richiesta al risolutore locale, senza passare attraverso la configurazione DNS del sistema:
sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -b -n 50 --no-pager
dig @127.0.0.1 example.net A +noall +comments +answer
dig @127.0.0.1 example.net A +noall +statsAdatta 127.0.0.1 e aggiungi -p 5335 se la tua configurazione mostra un’altra porta. Una risposta con status: NOERROR e una sezione ANSWER dimostra che Unbound ha risposto per questo nome.
connection refused rimanda al servizio o alla porta. SERVFAIL indica che il demone ha ricevuto la richiesta, ma non è riuscito a risolvere il nome. I log aiutano a separare i problemi di rete, la convalida DNSSEC e la configurazione dei server upstream.
Riavvia poi la stessa richiesta. Un tempo più breve al secondo passaggio può derivare dalla cache di Unbound. Questo test non misura le prestazioni del risolutore; conferma solo che stai parlando con la giusta istanza.
Collegare il risolutore di sistema solo dopo il test diretto
Se dig @127.0.0.1 risponde ma le applicazioni falliscono ancora, Unbound probabilmente non è nella catena utilizzata dal sistema. Controlla questa catena prima di modificare la rete.
resolvectl statusmostra i DNS conosciuti da systemd-resolved.resolvectl query example.nettesta la risoluzione dal risolutore di sistema.cat /etc/resolv.confmostra il file presentato alle applicazioni classiche.
Su un server, terrei Unbound su un indirizzo e una porta documentati, poi collego il risolutore di sistema una volta convalidati i test diretti. Su un desktop, systemd-resolved può rimanere davanti a Unbound se questo strato semplifica il Wi-Fi, il VPN o i profili di rete.
Un test locale non dice nulla sulla risoluzione pubblica del dominio. Prima di mettere un’applicazione dietro un reverse proxy Caddy con HTTPS, verifica anche la risposta vista da Internet.
La documentazione unbound-checkconf copre i controlli di configurazione. La guida ufficiale del risolutore locale dettagliando l’integrazione con il sistema. Conserva il backup finché il test diretto e il test di sistema non danno lo stesso risultato.