DNS Cloudflare, Google o Quad9: stai davvero usando il resolver scelto?

Impostare manualmente i server DNS di Cloudflare, Google o Quad9 non assicura che le richieste arrivino sempre e comunque al resolver scelto. Il traffico DNS tradizionale viaggia generalmente in chiaro sulla porta 53 e un apparato intermedio può, almeno tecnicamente, intercettarlo e rispondere al posto del server destinatario.

È quanto ha scoperto Karthik Hegde analizzando un problema nel suo homelab: alcune query DNS inviate a resolver differenti restituivano lo stesso indirizzo IP anomalo. Ripetendo la richiesta tramite DNS over HTTPS (DoH), che abilita la cifratura delle richieste di risoluzione dei nomi di dominio via DNS, il risultato cambiava. L’indirizzo sospetto apparteneva proprio al suo provider. Come capire se qualcosa di simile accade sulla propria connessione?

Chiedere la stessa cosa a resolver DNS differenti

Il primo test consiste nell’interrogare direttamente diversi resolver DNS, evitando quello configurato automaticamente sul sistema.

Su Linux o macOS, si può ricorrere al comando dig:

dig example.com @1.1.1.1
dig example.com @8.8.8.8
dig example.com @9.9.9.9

Gli indirizzi corrispondono rispettivamente ai resolver pubblici di Cloudflare, Google e Quad9. Con Windows si può effettuare una verifica analoga usando nslookup:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8
nslookup example.com 9.9.9.9

Al posto di example.com, indichiamo il nome di dominio da verificare: CDN, bilanciamento geografico, record DNS multipli e politiche del resolver possono esporre indirizzi IP diversi. Il segnale interessante emerge quando resolver indipendenti restituiscono sistematicamente una risposta inattesa o un indirizzo riconducibile all’operatore, soprattutto per un dominio del quale si conosce il comportamento atteso.

Abbiamo spiegato in un altro articolo come cambiare DNS in Windows, Linux, macOS e Android. Il tema, in questo caso, è differente: non vogliamo configurare un resolver, ma verificare che il traffico destinato a quel resolver non sia deviato lungo il percorso.

Confrontare DNS tradizionale e DNS over HTTPS

Il controllo successivo è più significativo: ripetere la risoluzione tramite un canale cifrato. Google, ad esempio, mette a disposizione una API DNS over HTTPS documentata.

Digitando quanto segue dalla finestra del terminale, la richiesta di risoluzione del nome di dominio transita all’interno di una richiesta HTTPS, quindi crittografata, sulla porta 443:

curl "https://dns.google/resolve?name=example.com&type=A"

Un’intercettazione limitata al traffico DNS UDP/TCP sulla porta 53 non può intervenire sulla risposta a una richiesta avanzata via DNS over HTTPS ovvero in forma crittografata. Nella risposta ricevuta tramite API Google (è in formato JSON), si può leggere l’indirizzo IP del server corrispondente al nome di dominio specificato.

Se dig example.com @8.8.8.8 e il comando curl presentato in precedenza forniscono risultati fortemente difformi, abbiamo un’indicazione interessante, ma non ancora una prova. Bisogna escludere cache, CDN e altre differenze di risoluzione.

Controllare a chi appartiene l’indirizzo sospetto

Nel caso raccontato da Hegde, un passaggio decisivo è stato verificare il proprietario dell’IP restituito.

Su Linux e macOS è sufficiente usare il comando whois seguito dall’indirizzo IP da verificare. Su Windows, invece, whois non è disponibile di default. La soluzione più semplice consiste nell’interrogare direttamente un servizio RDAP, il protocollo moderno che sta progressivamente sostituendo WHOIS.

Ad esempio, con PowerShell si può usare:

Invoke-RestMethod "https://rdap.arin.net/registry/ip/203.0.113.10"

oppure, da Prompt dei comandi o PowerShell con curl:

curl https://rdap.arin.net/registry/ip/203.0.113.10

In alternativa si può utilizzare un servizio Web pubblico come ICANN Lookup, che individua automaticamente il registro competente per l’indirizzo IP, oppure RIPEstat, particolarmente utile anche per ottenere informazioni su ASN, prefissi e instradamento della rete. Se l’indirizzo che dovrebbe appartenere al servizio interrogato risulta invece assegnato al proprio provider Internet o a un’infrastruttura di filtraggio, l’anomalia inizia ad essere sospetta.

Guardare davvero cosa passa sulla porta 53

Per passare dalle supposizioni ai fatti, è possibile analizzare ciò che sta avvenendo con Wireshark oppure con tcpdump. Su Linux si può ad esempio impartire il comando seguente:

sudo tcpdump -ni any port 53

Provvedendo quindi a richiedere la risoluzione del nome di dominio da un’altra finestra del terminale:

dig example.com @1.1.1.1

I dati catturati con tcpdump permettono di verificare che la richiesta sia effettivamente diretta verso 1.1.1.1 nonché di osservare la risposta ricevuta.

Wireshark consente un’analisi ancora più comoda usando il filtro dns, come abbiamo spiegato nell’articolo dedicato agli esempi di utilizzo.

Un provider che effettua transparent DNS proxying può intercettare la richiesta anche se il pacchetto è indirizzato a un resolver esterno. Dal punto di vista del client, quindi, il semplice fatto di vedere 1.1.1.1 come destinazione non prova che sia stato realmente Cloudflare a elaborare la query.

DNSSEC non nasconde le richieste DNS

DNSSEC e DNS cifrato hanno scopi diversi. DNSSEC serve soprattutto a verificare che una risposta DNS sia autentica e non sia stata alterata lungo il percorso. Non rende però invisibili le richieste: con il DNS tradizionale, chi può osservare il traffico di rete continua a vedere quali domini vengono interrogati.

DNS over HTTPS (DoH) e DNS over TLS (DoT) fanno invece un’altra cosa: cifrano il collegamento tra il dispositivo e il resolver DNS. Un intermediario non può quindi leggere o modificare con la stessa facilità le richieste che transitano sulla rete.

La distinzione può essere riassunta così: DNSSEC aiuta a verificare che la risposta sia corretta; DoH e DoT proteggono il viaggio della richiesta e della risposta tra client e resolver. Abbiamo spiegato più nel dettaglio il funzionamento del DNS over HTTPS in Windows.

Resta comunque un aspetto da tenere in conto: usando DoH o DoT bisogna ancora fidarsi del resolver scelto, perché è quest’ultimo a ricevere le richieste DNS. La cifratura protegge da chi si trova lungo il percorso tra utente e resolver.

Cambiare DNS non basta: bisogna verificare il percorso

Specificare manualmente un resolver non garantisce, insomma, che una query DNS in chiaro arrivi indisturbata a destinazione.

Confrontare DNS tradizionale e DoH, verificare gli IP restituiti, catturare il traffico e, quando possibile, provare un resolver controllato su una porta alternativa permette di distinguere una normale differenza di risoluzione da un vero transparent DNS proxy.

L’uso di un server DNS cifrato “cambia le regole”: non rende automaticamente affidabile il resolver scelto, ma impedisce a chi si trova tra client e resolver di sostituirsi silenziosamente a quest’ultimo con la stessa facilità consentita dal vecchio DNS in chiaro.