DNS sobre TLS més una VPN: quina part queda protegida

DNS sobre TLS xifra l'intercanvi entre un client i el resolutor que ha triat, i el resolutor continua llegint el nom. Aquesta frase resol bona part de la confusió al voltant de DoT més una VPN. El túnel decideix quin camí pren la consulta xifrada, mentre que el resolutor continua sabent què s'ha preguntat. Cap dels dos mecanismes substitueix l'altre, i cap no fa l'altre redundant.

Quatre comprovacions decideixen si la disposició que teniu és la que penseu que teniu.

Comprovació 1: què cobreix el xifratge

DoT embolcalla l'intercanvi DNS en TLS, de manera que un observador al camí veu una connexió a una adreça i un port en lloc d'un nom en una consulta. El resolutor mateix desxifra i respon. Compareu-ho amb DNS sobre HTTPS: tots dos xifren i fan servir transports diferents, així que una xarxa que permet trànsit web no permet automàticament una connexió DoT.

Aquesta distinció importa quan un portal captiu o un intermediari de filtratge permet el 443 i bloqueja el 853. L'eina que funcionava allà no és prova que l'altra ho farà.

Comprovació 2: quina ruta pren la consulta

La ruta és una qüestió de política del client. Es pot arribar a un resolutor DoT a través del túnel, fora d'ell o per un camí que canvia amb la xarxa. Quin dels casos passa depèn de les rutes i de si el client protegeix el seu propi sòcol DNS. Un túnel que captura tot el trànsit normalment s'endurà la consulta amb ell, digui el que digui l'adreça del resolutor.

Veure una adreça de resolutor de tercers en una prova no demostra una elusió, i veure xifratge no demostra el destinatari previst. Llegiu el resolutor i el camí per separat, i després decidiu si la parella és la que vau dissenyar.

Comprovació 3: noms interns

Una organització que publica noms interns necessita un resolutor que tingui aquests registres. Un servei DoT públic no coneix el vostre espai de noms privat, i apuntar-hi el client garanteix que aquests noms fallin. Aquesta és la regressió pràctica més habitual quan algú activa DNS xifrat en un dispositiu gestionat.

Manteniu el resolutor intern per als sufixos interns i xifreu aquest salt si la política ho exigeix, en lloc de substituir-lo per un proveïdor públic.

Comprovació 4: comportament davant d'un error

Un paràmetre de resolutor estricte sense cap resolutor abastable produeix un error de resolució de noms mentre el túnel continua aixecat. Mireu el mode de la plataforma i la seva alternativa documentada en lloc de tocar claus o certificats.

Una alternativa que utilitza DNS en clar silenciosament és una decisió de política, no una comoditat. Decidiu si l'error ha de ser visible o ha de degradar-se a una cosa més feble, i escriviu la resposta.

Confieu en el certificat, no en la resposta

Feu servir el nom d'amfitrió del proveïdor i la configuració de verificació documentats per al servei. Desactivar les comprovacions TLS perquè un resolutor desconegut respongui us dona un canal xifrat cap a un punt final no verificat, que és pitjor que la consulta en clar que ha substituït en un aspecte concret: sembla segur. L'especificació de DNS sobre TLS exposa l'expectativa d'autenticació que hi ha darrere d'aquesta comprovació.

Una resposta d'un resolutor que no podeu autenticar és una afirmació, no un resultat.

Què deixa això sense explicar

DoT no amaga el nom al resolutor, no amaga l'adreça de destinació de la connexió a la xarxa i no decideix si la consulta ha viatjat pel túnel. Són tres preguntes separades amb tres respostes separades.

Escriviu la identitat del resolutor, el camí de trànsit i la política de noms interns com a tres línies. La propera pregunta sobre DNS que rebeu serà una d'elles.