DNSSEC sau VPN: care ascunde interogările tale DNS?

Două mecanisme primesc aceeași sarcină și niciunul nu o îndeplinește. DNSSEC răspunde dacă datele primite provin într-adevăr din zona care le publică, iar un VPN decide pe ce drum merg pachetele tale. Niciunul nu ascunde în toate cazurile numele pe care l-ai întrebat, iar setările care par că ar trebui să facă asta privesc de obicei transportul sau rutarea, nu validarea. Dacă numești mai întâi nivelul, o întrebare vagă despre confidențialitate devine una concretă.

Trei afirmații topite într-una

Autenticitatea este afirmația că răspunsul este cel publicat de zonă și că nu a fost modificat pe drum. Confidențialitatea este afirmația că nimeni de pe drum nu poate citi interogarea sau răspunsul. Rutarea este afirmația că pachetele urmează un drum pe care l-ai ales, iar asta oferă exact un tunel.

DNSSEC se ocupă de prima și nu spune nimic despre celelalte două. DoT și DoH se ocupă de a doua pentru saltul până la resolver. Un VPN se ocupă de a treia și poate afecta și a doua, dar numai ca efect secundar al locului în care merge traficul.

Traficul aplicațiilor este un al patrulea caz: HTTPS protejează și autentifică schimbul web dintre clientul tău și site, iar niciun nivel DNS nu îl înlocuiește.

Ce poate și ce nu poate face validarea semnăturilor

Un resolver care validează verifică lanțul de semnături de la zonă până la o ancoră de încredere configurată, apoi returnează un răspuns cu steagul datelor autentificate setat atunci când verificarea reușește. Acel steag este o dovadă despre date, nu despre conexiune sau despre intențiile destinației.

Nu poate împiedica un proprietar legitim al unei zone să publice înregistrări autentice pentru un serviciu în care nu ar trebui să ai încredere. Un răspuns semnat corect dintr-un domeniu compromis rămâne semnat corect, iar DNSSEC nu are o părere despre dacă acel domeniu merită acreditările tale.

Nu ascunde nici nimic. Interogarea și răspunsul traversează rețeaua într-o formă pe care un resolver și orice observator de pe acel drum o pot citi, dacă un alt nivel nu protejează transportul. Un răspuns semnat și un răspuns privat sunt proprietăți diferite, iar o implementare poate avea doar una dintre ele. Testează ambele dacă vreuna contează pentru tine.

De unde vine de fapt confidențialitatea

Transportul criptat către resolver înfășoară schimbul DNS în TLS, așa că resolverul vede în continuare întrebarea, dar drumul dintre tine și el nu. Asta mută încrederea în loc să o elimine: ai mai multă încredere în resolver și mai puțină în rețeaua locală.

Un VPN poate duce interogările la un resolver de pe cealaltă parte, ceea ce schimbă atât drumul, cât și resolverul care le vede. Este o decizie de rutare cu o consecință pentru confidențialitate, iar într-o rețea administrată resolverul intern poate fi singurul care poate răspunde la nume interne.

Combinația pe care oamenii o vor cu adevărat este de obicei trei lucruri deodată: validare pornită, transport criptat către un resolver ales de ei și TLS al aplicației la destinație. Fiecare este independentă, iar omiterea uneia lasă o altă lipsă.

Verifică validarea și transportul separat

Două teste rezolvă cea mai mare parte a confuziei. Primul întreabă dacă resolverul a validat răspunsul; al doilea întreabă dacă transportul a fost protejat. Eșuează în moduri diferite și niciunul nu îl implică pe celălalt.

Aceste comenzi afișează steagurile unei interogări care validează, repetă interogarea cu verificarea dezactivată și rulează validarea locală cu delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Un răspuns cu steagul datelor autentificate și o semnătură prezentă arată validarea la acel resolver. O eroare de validare cu delv arată un lanț rupt undeva între zonă și ancora de încredere, ceea ce este o problemă de publicare, nu o problemă de tunel. O expirare fără niciun steag este o problemă de transport sau de accesibilitate, iar tratarea ei ca eroare de semnătură te trimite la nivelul greșit.

Ce să faci când un VPN strică căutările

Dacă căutările funcționau înainte de tunel și se opresc după, compară resolverul pe care îl folosește fiecare drum. Tunelul divizat, un resolver intern accesibil doar prin tunel și un client care rescrie setările resolverului schimbă toate răspunsul fără să atingă DNSSEC.

Dezactivarea globală a validării este primul pas greșit, pentru că elimină singurul mecanism care raportează manipularea și nu repară un resolver inaccesibil. Restrânge mai întâi defecțiunea: rezolvare, transport, validare, apoi politică. Doar a treia aparține DNSSEC, iar doar a doua transportului criptat.