Come Diagnosticare e Risolvere un Loop di Forwarding DNS su Loopback

Quando si gestisce un’infrastruttura di rete o un server locale dedicato alla privacy, trovarsi di fronte a un loop di forwarding dns su interfaccia di loopback rappresenta uno scenario tanto frustrante quanto comune. Questo fenomeno si manifesta solitamente con blocchi improvvisi della navigazione, richieste di risoluzione che finiscono costantemente in timeout e un consumo anomalo delle risorse di sistema. Come abbiamo già accennato nell’articolo dedicato a come gestire gli errori di connessione Unbound, la configurazione errata delle catene di inoltro tra resolver locali e stub resolver di sistema può paralizzare l’intero stack IP della macchina.

Anatomia di un loop su interfaccia locale

L’interfaccia di loopback (tipicamente identificata come lo con indirizzo 127.0.0.1 per IPv4 o ::1 per IPv6) è progettata per consentire la comunicazione interna tra processi residenti sullo stesso host. Nel contesto della risoluzione dei nomi a dominio, spesso coesistono più demoni o servizi che tentano di gestire la porta UDP/TCP 53 o indirizzi di ascolto virtuali (come il classico 127.0.0.53 gestito da systemd-resolved sulle distribuzioni Linux più recenti).

Il problema si scatena quando un componente di inoltro invia la richiesta a un server a monte che, direttamente o indirettamente, re-inoltra la medesima richiesta all’indirizzo di partenza. In questo contesto operativo si genera un loop di forwarding dns che satura in pochi istanti la coda dei descrittori di file disponibili nel kernel, portando l’applicazione a rifiutare nuovi pacchetti e generando un evidente ServFail o un classico Connection Timed Out verso i client finali.

Un anello di inoltro circolare non solo interrompe la navigazione web dell’host, ma rischia di causare un micro DoS (Denial of Service) auto-inflitto a causa delle migliaia di query cicliche generate al secondo.

Identificare i sintomi: strumenti di analisi per sysadmin

Prima di intervenire sui file di configurazione, è fondamentale raccogliere evidenze oggettive del guasto attraverso strumenti di monitoraggio in tempo reale. Quando un’interfaccia loopback entra in sofferenza, i sintomi visibili sono molteplici e facilmente riconoscibili se si sa dove guardare.

1. Interrogazioni diagnostiche con dig ed nslookup

Il primo test consiste nell’effettuare una query mirata esplicitando l’indirizzo IP di loopback:

dig @127.0.0.1 example.com -p 53

Se la risposta richiede svariati secondi e termina con il messaggio ;; connection timed out; no servers could be reached, oppure restituisce un codice di stato SERVFAIL con flag ra (Recursion Available) assente o intermittente, siamo probabilmente davanti a una richiesta intrappolata in un percorso circolare.

2. Sniffing dei pacchetti sull’interfaccia loopback

La prova inconfutabile si ottiene analizzando il traffico che scorre su lo mediante l’utilità tcpdump. Eseguendo il seguente comando in un terminale dedicato:

sudo tcpdump -nnvv -i lo port 53

Durante la riproduzione del guasto, noterete la stessa identica transazione DNS (riconoscibile dal Transaction ID e dal nome del dominio richiesto) rimbalzare a frequenze elevatissime tra porte sorgente e porte destinazione afferenti al localhost. Questo comportamento è il sintomo tipico di un loop di forwarding dns che continua a consumare socket effimeri senza mai raggiungere una zona autoritativa o un server root.

Le cause principali dei conflitti di inoltro

Per correggere il problema alla radice occorre comprendere quali configurazioni favoriscono la nascita del loop. Negli ambienti server e desktop contemporanei, le architetture sono diventate via via più stratificate. Vediamo gli scenari più critici.

La sovrapposizione tra systemd-resolved e resolver ricorsivi

In molte distribuzioni GNU/Linux (come Ubuntu, Debian o Fedora), il gestore di rete imposta di default systemd-resolved in ascolto sull’indirizzo 127.0.0.53. Se l’amministratore decide di installare un resolver ricorsivo come Unbound, Knot Resolver o Pi-hole facendolo ascoltare su 127.0.0.1 e configura il file /etc/resolv.conf per puntare a quest’ultimo, ma configura contemporaneamente il resolver per inoltrare le richieste non risolte a monte verso l’indirizzo del sistema operativo, si chiude l’anello distruttivo.

La direttiva forward-zone e l’opzione do-not-query-localhost

Prendiamo come esempio Unbound. Di default, per motivi di sicurezza, questo software possiede una protezione attiva denominata do-not-query-localhost: yes. Se questa direttiva viene disattivata incautamente nel file di configurazione e al contempo viene definita una forward-zone che include 127.0.0.1 o 127.0.0.53, il demone tenterà di interrogare se stesso all’infinito per ciascun dominio ricorsivo.

Procedura passo-passo per bonificare la configurazione

Vediamo ora una procedura metodica ed efficace per eliminare i conflitti e ristabilire una risoluzione stabile e veloce.

Passo 1: Disaccoppiare o disattivare il resolver secondario

Se intendete utilizzare un resolver locale dedicato ad alte prestazioni come unico motore di risoluzione della macchina, è raccomandabile disabilitare il servizio stub di systemd-resolved o riconfigurarlo in modalità pass-through.

1. Aprite il file di configurazione principale: sudo nano /etc/systemd/resolved.conf
2. Modificate o aggiungete le seguenti impostazioni:
   [Resolve]
DNSStubListener=no
3. Riavviate il servizio: sudo systemctl restart systemd-resolved

Disabilitando lo stub listener, il socket sulla porta 127.0.0.53:53 viene rilasciato, impedendo che i client di sistema inoltrino richieste al wrapper interno.

Passo 2: Configurare correttamente il file resolv.conf

Verificate a quale destinazione punta il file di configurazione dei resolver di sistema. Spesso /etc/resolv.conf è un collegamento simbolico a un file temporaneo gestito da NetworkManager o systemd.

Per renderlo statico e univoco verso il vostro resolver di fiducia su loopback:

1. Rimuovete il symlink esistente: sudo rm -f /etc/resolv.conf
2. Create un nuovo file statico: sudo nano /etc/resolv.conf
3. Inserite esclusivamente la riga: nameserver 127.0.0.1 (o l’eventuale porta dedicata configurata nei vostri strumenti).
4. Salvate e rendete il file immutabile se necessario con: sudo chattr +i /etc/resolv.conf

Passo 3: Blindare il resolver ricorsivo principale

Accedete al file di configurazione del vostro software (ad esempio /etc/unbound/unbound.conf) e isolate le interfacce di rete. È indispensabile accertarsi che le zone di inoltro (forward-zone) non contengano riferimenti al localhost:

• Accertatevi che do-not-query-localhost sia impostato su yes all’interno del blocco server:. Questa semplice impostazione blocca le query accidentali verso la loopback e interrompe sul nascere qualunque catena circolare.
• Verificate le sezioni forward-zone: gli indirizzi specificati sotto forward-addr devono appartenere unicamente a server esterni affidabili (quali 9.9.9.9, 1.1.1.1 o i DNS del vostro provider upstream).

Questa separazione architetturale pulita è ciò che impedisce l’insorgere di un loop di forwarding dns ricorsivo tra i processi interni del server, garantendo che le richieste destinate all’esterno non vengano mai rigettate verso l’interno dell’host.

Verifica finale e testing del resolver

Completati i passaggi correttivi, riavviate il resolver con il comando dedicato (ad esempio sudo systemctl restart unbound) ed eseguite una batteria di verifiche:

1. Eseguite un test di lookup sul localhost: dig @127.0.0.1 nicolacasalini.it.
2. Controllate il tempo di risposta (Query time) nei metadati: deve attestarsi su pochi millisecondi e restituire uno stato di NOERROR.
3. Ripetete l’ispezione con tcpdump -i lo port 53 per verificare che il flusso di pacchetti sia ordinato, con una singola richiesta e una singola risposta per ciascuna interrogazione effettuata.

Seguendo questo approccio metodico e mantenendo una netta demarcazione tra resolver locali e configurazioni di sistema, riuscirete a eliminare alla radice ogni loop di forwarding dns garantendo la massima rapidità e resilienza a tutta la vostra infrastruttura informatica.