Cine operează 1.1.1.1? Verificarea unei adrese DNS înainte de a avea încredere în ea

Ați lipit 1.1.1.1 în câmpul DNS al VPN-ului, pagina s-a încărcat, iar tutorialul pare acum confirmat. Observația este mai îngustă decât pare: aplicația s-a comportat diferit, iar schimbarea nu spune încă nimic despre cine a răspuns la interogare sau de ce a eșuat vechea configurare. Un tutorial copiat numește adesea „DNS-ul VPN-ului” o adresă publică cunoscută, ceea ce este o afirmație despre proprietate, nu despre accesibilitate. Verificarea a ceea ce reprezintă adresa durează cinci minute și împiedică o schimbare permanentă făcută din motivul greșit.

O setare care funcționează nu este o identitate

Adresa dintr-un câmp de setări este un punct final, iar un punct final are un operator. Aceste două fapte sunt separate, iar al doilea este cel pe care oamenii îl sar. Pentru perechea copiată cel mai des, răspunsul este public: Cloudflare publică 1.1.1.1 și 1.0.0.1 ca adrese ale resolverului său și le listează în referința oficială de adrese. De aceea numele operatorului stă lângă adresă, nu într-un tutorial separat.

Introducerea acelei perechi în timp ce un tunel este activ nu face compania VPN operatorul ei și nu face traficul anonim. Interogarea părăsește mașina dumneavoastră către o companie care publică intervalul de adrese, iar acea companie poate fi respectabilă și totuși să nu fie partea pe care o sugera tutorialul. Eticheta din instrucțiuni și operatorul din realitate sunt afirmații diferite. Niciuna nu spune cine administrează calea de rețea dintre ele.

Folosiți referința publicată a resolverului însuși pentru a confirma o pereche de adrese sau un punct final criptat. O recomandare de la alt furnizor poate fi legitimă, iar „recomandat de”, „accesat prin” și „operat de” descriu în continuare trei relații diferite.

Comparați cele trei lucruri de care are nevoie o înregistrare

O înregistrare pregătită pentru revizuire separă trei întrebări: cine ar trebui să primească interogarea, dacă schimbul este simplu sau criptat și ce cale ar trebui să o transporte. Numele unui furnizor nu poate completa a doua sau a treia, iar o etichetă de țară nu poate completa niciuna. Notați cele trei intrări înainte de schimbare și comparați-le după. Acele intrări nu sunt interschimbabile, iar tratarea lor ca una singură este felul în care o presupunere devine documentație.

Comparația este cea care transformă o setare funcțională într-o decizie documentată. Fără ea, următoarea persoană moștenește o adresă fără niciun motiv atașat. Citiți mai întâi a treia coloană a tabelului de mai jos, pentru că acolo se opresc de fapt majoritatea explicațiilor încrezătoare.

Tabelul este intenționat scurt. Ideea este că fiecare intrare răspunde la o întrebare diferită și că niciun câmp unic nu le completează pe toate trei.

Un redirector local ascunde sursa reală

Un dispozitiv configurat să folosească routerul ca DNS indică un redirector. Acea adresă identifică următorul destinatar al interogării, nu resolverul care răspunde în cele din urmă. Un resolver stub local adaugă același pas suplimentar, iar acesta este ușor de confundat cu lucrul real pentru că apare în fiecare ieșire de stare.

Stub-ul redirecționează către surse pe care aceeași ieșire le listează și ea, de obicei mai jos. Citiți întregul lanț înainte de a trage vreo concluzie despre operator, pentru că prima linie nu este întregul răspuns. Altfel, numiți recepția drept companie.

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

A doua comandă folosește numele de ecou al unui resolver, acolo unde operatorul publică unul, pentru a raporta adresa sursă pe care o vede. A treia numește serverul care a răspuns, care adesea nu este adresa pe care ați configurat-o. Comparați toate cele trei ieșiri înainte de a nota un operator.

DNS-ul criptat schimbă ce este vizibil, nu cine îl vede

DNS over HTTPS și DNS over TLS protejează schimbul dintre client și resolver. Resolverul citește în continuare fiecare nume pentru care este întrebat, pentru că a răspunde este treaba lui. Ce se schimbă este cine poate urmări schimbul: rețeaua locală vede o conexiune către un singur punct final în locul unui flux de interogări în text simplu.

Ce nu se schimbă este relația de încredere, care indică în continuare organizația care operează acel punct final. Un browser cu propria setare de DNS sigur poate ocoli complet resolverul sistemului de operare. Tratați-le ca două configurații care pot fi în dezacord, nu ca o singură setare aplicată de două ori.

Numele private au din nou nevoie de propria decizie. Un tunel de lucru poate direcționa domenii selectate către resolverele organizației, iar înlocuirea acelei soluții cu un serviciu public poate rupe căutările interne sau poate divulga nume interne părții greșite. Verificați politica de domenii înainte de a înlocui setările unui întreg adaptor.

Păstrați observația îngustă

Când comparați, păstrați configurația veche și schimbați o singură setare o dată. Notați aplicația, operațiunea, politica resolverului și dacă numele publice și cele private permise se mai rezolvă după o reconectare. O comparație cu două schimbări nu o dovedește pe niciuna. Scrieți rezultatul acolo unde îl va găsi următoarea persoană, lângă setarea însăși.

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

Dacă aplicația începe să funcționeze, păstrați afirmația atât de mică pe cât permit dovezile. Acea schimbare a ajutat un singur test și nu spune nimic despre dacă resolverul anterior a acționat cu rea-credință, dacă tunelul era stricat sau dacă un alt dispozitiv are nevoie de aceeași înlocuire. Rezultatul durabil este o configurație al cărei operator și scop le puteți explica.