Qui gestiona 1.1.1.1? Comprovar una adreça DNS abans de confiar-hi

Heu enganxat 1.1.1.1 al camp DNS de la VPN, la pàgina s’ha carregat i ara el tutorial sembla confirmat. Aquesta observació és més estreta del que sembla: l’aplicació s’ha comportat d’una altra manera, i el canvi encara no diu res sobre qui ha respost la consulta ni per què ha fallat la configuració anterior. Un tutorial copiat sol anomenar una adreça pública coneguda «el DNS de la VPN», cosa que és una afirmació sobre la propietat, no sobre l’abast. Comprovar què representa l’adreça triga cinc minuts i evita un canvi permanent fet per la raó equivocada.

Una configuració que funciona no és una identitat

L’adreça d’un camp de configuració és un punt final, i un punt final té un operador. Aquests dos fets són separats, i el segon és el que la gent s’estalvia. Per al parell que es copia més sovint, la resposta és pública: Cloudflare publica 1.1.1.1 i 1.0.0.1 com a adreces del seu resolutor i les enumera a la seva referència oficial d’adreces. Per això el nom de l’operador va al costat de l’adreça i no en un tutorial a part.

Introduir aquest parell amb un túnel actiu no converteix l’empresa de la VPN en el seu operador, ni fa que el trànsit sigui anònim. La consulta surt de la vostra màquina cap a una empresa que publica el rang d’adreces, i aquesta empresa pot ser respectable i tot i així no ser la part que el tutorial insinuava. L’etiqueta de les instruccions i l’operador real són afirmacions diferents. Cap de les dues no diu qui gestiona el camí de xarxa entremig.

Utilitzeu la referència publicada del mateix resolutor per confirmar un parell d’adreces o un punt final xifrat. Una recomanació d’un altre proveïdor pot ser legítima, i «recomanat per», «arribat a través de» i «operat per» encara descriuen tres relacions diferents.

Compareu les tres coses que necessita un registre

Un registre a punt per a la revisió separa tres preguntes: qui ha de rebre la consulta, si l’intercanvi és en clar o xifrat, i quin camí l’ha de portar. El nom d’un proveïdor no pot omplir la segona ni la tercera, i una etiqueta de país no pot omplir cap de les tres. Escriviu les tres entrades abans del canvi i compareu-les després. Aquestes entrades no són intercanviables, i tractar-les com una sola és com una conjectura es converteix en documentació.

La comparació és el que converteix una configuració que funciona en una decisió documentada. Sense ella, la persona següent hereta una adreça sense cap motiu adjunt. Llegiu primer la tercera columna de la taula següent, perquè és on la majoria d’explicacions segures s’aturen realment.

La taula és deliberadament curta. El seu objectiu és que cada entrada respon una pregunta diferent, i cap camp sol no omple les tres.

Un reenviador local amaga l’origen real

Un dispositiu configurat per utilitzar el seu encaminador com a DNS apunta a un reenviador. Aquesta adreça identifica el següent destinatari de la consulta, no el resolutor que finalment la respon. Un resolutor stub local afegeix el mateix pas extra, i és fàcil confondre’l amb la cosa real perquè apareix a cada sortida d’estat.

L’stub reenvia a servidors d’origen que la mateixa sortida també llista, normalment més avall. Llegiu tota la cadena abans de concloure res sobre l’operador, perquè la primera línia no és tota la resposta. Si no, esteu anomenant la recepció com l’empresa.

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

La segona ordre utilitza el nom d’eco d’un resolutor, quan l’operador en publica un, per informar de l’adreça d’origen que veu. La tercera nomena el servidor que ha respost, que sovint no és l’adreça que heu configurat. Compareu les tres sortides abans d’escriure un operador.

El DNS xifrat canvia què és visible, no qui ho veu

DNS over HTTPS i DNS over TLS protegeixen l’intercanvi entre client i resolutor. El resolutor encara llegeix cada nom que se li demana, perquè respondre és la feina. El que canvia és qui pot observar l’intercanvi: la xarxa local veu una connexió a un punt final en lloc d’un flux de consultes en text pla.

El que no canvia és la relació de confiança, que continua apuntant a l’organització que gestiona aquest punt final. Un navegador amb la seva pròpia configuració de DNS segur pot evitar del tot el resolutor del sistema operatiu. Tracteu-los com dues configuracions que poden discrepar, no com una configuració aplicada dues vegades.

Els noms privats necessiten una altra vegada la seva pròpia decisió. Un túnel de feina pot encaminar dominis seleccionats cap a resolutors de l’organització, i substituir-ho per un servei públic pot trencar les cerques internes o revelar noms interns a la part equivocada. Comproveu la política de dominis abans de substituir la configuració de tot un adaptador.

Manteniu l’observació estreta

Quan compareu, preserveu la configuració antiga i canvieu una configuració alhora. Anoteu l’aplicació, l’operació, la política del resolutor i si els noms públics i els privats permesos encara es resolen després de tornar a connectar. Una comparació amb dos canvis no demostra cap dels dos. Escriviu el resultat on el trobi la persona següent, al costat de la configuració mateixa.

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

Si l’aplicació comença a funcionar, manteniu l’afirmació tan petita com permetin les proves. Aquest canvi ha ajudat una prova, i no diu res sobre si el resolutor anterior va actuar de mala fe, si el túnel estava trencat o si un altre dispositiu necessita la mateixa substitució. El resultat durador és una configuració l’operador i el propòsit de la qual podeu explicar.