DNS prin TLS plus un VPN: care parte este protejată

DNS prin TLS criptează schimbul dintre un client și resolverul pe care l-a ales, iar resolverul citește în continuare numele. Această propoziție lămurește cea mai mare parte a confuziei din jurul DoT plus un VPN. Tunelul decide pe ce drum merge interogarea criptată, în timp ce resolverul află în continuare ce s-a întrebat. Niciun mecanism nu îl înlocuiește pe celălalt, și niciunul nu îl face pe celălalt de prisos.

Patru verificări decid dacă aranjamentul pe care îl aveți este cel pe care credeți că îl aveți.

Verificarea 1: ce acoperă criptarea

DoT înfășoară schimbul DNS în TLS, așa că un observator pe drum vede o conexiune către o adresă și un port, nu un nume într-o interogare. Resolverul însuși decriptează și răspunde. Comparați cu DNS prin HTTPS: ambele criptează și folosesc transporturi diferite, așa că o rețea care permite trafic web nu permite automat o conexiune DoT.

Această distincție contează când un portal captiv sau o cutie intermediară de filtrare permite 443 și blochează 853. Instrumentul care a funcționat acolo nu este dovada că celălalt va funcționa.

Verificarea 2: pe ce rută merge interogarea

Ruta este o chestiune de politică a clientului. Un resolver DoT poate fi atins prin tunel, în afara lui sau printr-o cale care se schimbă cu rețeaua. Care se întâmplă depinde de rute și de dacă clientul își protejează propriul socket DNS. Un tunel care capturează tot traficul de obicei ia interogarea cu el, orice ar spune adresa resolverului.

Vederea unei adrese de resolver terță parte într-un test nu dovedește o ocolire, iar vederea criptării nu dovedește destinatarul dorit. Citiți resolverul și calea separat, apoi decideți dacă perechea este cea pe care ați proiectat-o.

Verificarea 3: nume interne

O organizație care publică nume interne are nevoie de un resolver care ține acele înregistrări. Un serviciu DoT public nu cunoaște spațiul dumneavoastră de nume privat, iar îndreptarea clientului către unul garantează că acele nume vor eșua. Aceasta este cea mai frecventă regresie practică atunci când cineva activează DNS criptat pe un dispozitiv administrat.

Păstrați resolverul intern pentru sufixele interne și criptați acel salt dacă politica o cere, în loc să îl înlocuiți cu un furnizor public.

Verificarea 4: comportamentul la eșec

O setare strictă de resolver fără un resolver accesibil produce un eșec de rezoluție a numelor în timp ce tunelul rămâne ridicat. Uitați-vă la modul platformei și la rezerva ei documentată în loc să atingeți chei sau certificate.

O rezervă care folosește în tăcere DNS simplu este o decizie de politică, nu o comozitate. Decideți dacă eșecul trebuie să fie vizibil sau trebuie să degradeze spre ceva mai slab, și scrieți răspunsul.

Aveți încredere în certificat, nu în răspuns

Folosiți numele de gazdă al furnizorului și configurația de verificare documentate pentru serviciu. Dezactivarea verificărilor TLS ca să răspundă un resolver necunoscut vă dă un canal criptat către un punct final neverificat, ceea ce este mai rău decât interogarea simplă pe care a înlocuit-o într-o anumită privință: pare sigur. Specificația DNS prin TLS expune așteptarea de autentificare din spatele acelei verificări.

Un răspuns de la un resolver pe care nu îl puteți autentifica este o afirmație, nu un rezultat.

Ce lasă aceasta neexplicat

DoT nu ascunde numele de resolver, nu ascunde adresa de destinație a conexiunii de rețea și nu decide dacă interogarea a trecut prin tunel. Sunt trei întrebări separate cu trei răspunsuri separate.

Scrieți identitatea resolverului, calea de tranzit și politica de nume interne pe trei linii. Următoarea întrebare despre DNS pe care o primiți va fi una dintre ele.