DNS oor TLS plus 'n VPN: watter deel is beskerm

DNS oor TLS versleutel die uitruiling tussen 'n kliënt en die resolver wat hy gekies het, en die resolver lees steeds die naam. Daardie sin besleg die meeste verwarring oor DoT plus 'n VPN. Die tonnel bepaal watter pad die versleutelde navraag volg, terwyl die resolver steeds leer wat gevra is. Nie een meganisme vervang die ander nie, en nie een maak die ander oorbodig nie.

Vier kontroles bepaal of die reëling wat jy het, die een is wat jy dink jy het.

Kontrole 1: wat die versleuteling dek

DoT wikkel die DNS-uitruiling in TLS, so 'n waarnemer op die pad sien 'n verbinding na 'n adres en poort eerder as 'n naam in 'n navraag. Die resolver self ontsyfer en antwoord. Vergelyk dit met DNS oor HTTPS: albei versleutel, en hulle gebruik verskillende vervoermiddels, so 'n netwerk wat webverkeer toelaat, laat nie outomaties 'n DoT-verbinding toe nie.

Daardie onderskeid maak saak wanneer 'n gevangenisportaal of 'n filtrerende middelboks 443 toelaat en 853 blokkeer. Die instrument wat daar gewerk het, is nie bewys dat die ander een sal nie.

Kontrole 2: watter roete die navraag volg

Die roete is 'n kwessie van kliëntbeleid. 'n DoT-resolver kan deur die tonnel bereik word, buite dit, of deur 'n pad wat met die netwerk verander. Watter een gebeur, hang af van roetes en van of die kliënt sy eie DNS-sok beskerm. 'n Tonnel wat alle verkeer vang, sal gewoonlik die navraag saamneem, wat die resolveradres ook al sê.

Om 'n derdeparty-resolveradres in 'n toets te sien, bewys nie 'n omseiling nie, en om versleuteling te sien bewys nie die bedoelde ontvanger nie. Lees die resolver en die pad afsonderlik, en besluit dan of die paar is wat jy ontwerp het.

Kontrole 3: interne name

'n Organisasie wat interne name publiseer, het 'n resolver nodig wat daardie rekords hou. 'n Openbare DoT-diens ken nie jou private naamruimte nie, en om die kliënt na een te wys, waarborg dat daardie name misluk. Dit is die algemeenste praktiese terugslag wanneer iemand versleutelde DNS op 'n bestuurde toestel aktiveer.

Hou die interne resolver vir interne agtervoegsels en versleutel daardie skakel as beleid dit vereis, in plaas daarvan om dit met 'n openbare verskaffer te vervang.

Kontrole 4: foutgedrag

'n Streng resolverinstelling sonder 'n bereikbare resolver veroorsaak 'n naamresolusiefout terwyl die tonnel bly staan. Kyk na die platformmodus en sy gedokumenteerde terugval eerder as om aan sleutels of sertifikate te raak.

'n Terugval wat stilweg gewone DNS gebruik, is 'n beleidsbesluit, nie 'n gerief nie. Besluit of mislukking sigbaar moet wees of na iets swakker moet afneem, en skryf die antwoord neer.

Vertrou die sertifikaat, nie die antwoord nie

Gebruik die verskaffer-hostnaam en verifikasiopstelling wat vir die diens gedokumenteer is. Om TLS-kontroles af te skakel sodat 'n onbekende resolver sal antwoord, gee jou 'n versleutelde kanaal na 'n ongeverifieerde eindpunt, wat op een spesifieke manier slegter is as die gewone navraag wat dit vervang het: dit lyk veilig. Die DNS over TLS-spesifikasie stel die verifikasieverwagting agter daardie kontrole uiteen.

'n Antwoord van 'n resolver wat jy nie kan verifieer nie, is 'n bewering, nie 'n resultaat nie.

Wat dit onverklaar laat

DoT verberg nie die naam van die resolver nie, verberg nie die verbinding se bestemmingsadres van die netwerk nie, en besluit nie of die navraag deur die tonnel gegaan het nie. Dit is drie afsonderlike vrae met drie afsonderlike antwoorde.

Skryf die resolver-identiteit, die deurvoerpad en die interne-naambeleid as drie reëls neer. Die volgende DNS-vraag wat jy kry, sal een van hulle wees.