Chi gestisce 1.1.1.1? Verificare un indirizzo DNS prima di fidarsi

Avete incollato 1.1.1.1 nel campo DNS della VPN, la pagina si è caricata e il tutorial ora sembra confermato. Quell’osservazione è più stretta di quanto sembri: l’applicazione si è comportata diversamente, e la modifica non dice ancora nulla su chi ha risposto alla query o sul perché la vecchia configurazione abbia fallito. Un tutorial copiato chiama spesso «il DNS della VPN» un indirizzo pubblico familiare, il che è un’affermazione sulla proprietà e non sulla raggiungibilità. Verificare che cosa rappresenta l’indirizzo richiede cinque minuti ed evita un cambiamento permanente fatto per il motivo sbagliato.

Un’impostazione che funziona non è un’identità

L’indirizzo in un campo di impostazione è un endpoint, e un endpoint ha un gestore. Questi due fatti sono separati, e il secondo è quello che la gente salta. Per la coppia più spesso copiata, la risposta è pubblica: Cloudflare pubblica 1.1.1.1 e 1.0.0.1 come indirizzi del proprio resolver, e li elenca nella sua referenza ufficiale degli indirizzi. Ecco perché il nome del gestore sta accanto all’indirizzo, e non in un tutorial separato.

Inserire quella coppia con un tunnel attivo non rende l’azienda della VPN il suo gestore e non rende il traffico anonimo. La query lascia la vostra macchina verso un’azienda che pubblica l’intervallo di indirizzi, e quell’azienda può essere rispettabile e comunque non essere la parte che il tutorial lasciava intendere. L’etichetta nelle istruzioni e il gestore reale sono affermazioni diverse. Nessuna delle due dice chi gestisce il percorso di rete intermedio.

Usate la referenza pubblicata dal resolver stesso per confermare una coppia di indirizzi o un endpoint cifrato. Una raccomandazione di un altro fornitore può essere legittima, e «raccomandato da», «raggiunto tramite» e «gestito da» descrivono ancora tre relazioni diverse.

Confrontate le tre cose che un record richiede

Un record pronto per la revisione separa tre domande: chi deve ricevere la query, se lo scambio è in chiaro o cifrato e quale percorso deve trasportarla. Il nome di un fornitore non può riempire la seconda o la terza, e un’etichetta di paese non può riempire nessuna delle tre. Annotate le tre voci prima della modifica e confrontatele dopo. Quelle voci non sono intercambiabili, e trattarle come una sola è il modo in cui un’ipotesi diventa documentazione.

È il confronto che trasforma un’impostazione funzionante in una decisione documentata. Senza di esso, la persona successiva eredita un indirizzo senza alcun motivo allegato. Leggete prima la terza colonna della tabella qui sotto, perché è lì che la maggior parte delle spiegazioni sicure si ferma davvero.

La tabella è volutamente breve. Il suo punto è che ogni voce risponde a una domanda diversa e che nessun singolo campo riempie tutte e tre.

Un inoltro locale nasconde la sorgente reale

Un dispositivo configurato per usare il proprio router come DNS punta a un inoltro. Quell’indirizzo identifica il prossimo destinatario della query, non il resolver che alla fine risponde. Un resolver stub locale aggiunge lo stesso passaggio extra, ed è facile confonderlo con la cosa reale perché compare in ogni output di stato.

Lo stub inoltra a sorgenti che lo stesso output elenca, di solito più in basso. Leggete l’intera catena prima di concludere qualcosa sul gestore, perché la prima riga non è tutta la risposta. Altrimenti state chiamando la reception l’azienda.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

Il secondo comando usa il nome di eco di un resolver, quando il gestore ne pubblica uno, per riportare l’indirizzo di origine che vede. Il terzo nomina il server che ha risposto, che spesso non è l’indirizzo che avete configurato. Confrontate tutti e tre gli output prima di annotare un gestore.

Il DNS cifrato cambia ciò che è visibile, non chi lo vede

DNS over HTTPS e DNS over TLS proteggono lo scambio tra client e resolver. Il resolver legge comunque ogni nome che gli viene chiesto, perché rispondere è il suo lavoro. Ciò che cambia è chi può osservare lo scambio: la rete locale vede una connessione verso un solo endpoint invece di un flusso di query in chiaro.

Ciò che non cambia è la relazione di fiducia, che punta ancora all’organizzazione che gestisce quell’endpoint. Un browser con la propria impostazione DNS sicuro può aggirare del tutto il resolver del sistema operativo. Trattateli come due configurazioni che possono dissentire, non come un’unica impostazione applicata due volte.

I nomi privati hanno di nuovo bisogno della propria decisione. Un tunnel di lavoro può instradare domini selezionati verso resolver organizzativi, e sostituirlo con un servizio pubblico può rompere le ricerche interne o divulgare nomi interni alla parte sbagliata. Controllate la politica dei domini prima di sostituire le impostazioni di un intero adattatore.

Mantenete stretta l’osservazione

Quando confrontate, conservate la vecchia configurazione e cambiate un’impostazione alla volta. Annotate l’applicazione, l’operazione, la politica del resolver e se i nomi pubblici e quelli privati consentiti si risolvono ancora dopo una riconnessione. Un confronto con due modifiche non ne dimostra nessuna. Scrivete il risultato dove lo troverà la persona successiva, accanto all’impostazione stessa.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Se l’applicazione inizia a funzionare, mantenete l’affermazione tanto piccola quanto le prove consentono. Quella modifica ha aiutato un test, e non dice nulla sul fatto che il resolver precedente abbia agito in mala fede, che il tunnel fosse rotto o che un altro dispositivo abbia bisogno della stessa sostituzione. Il risultato duraturo è una configurazione di cui potete spiegare il gestore e lo scopo.