DNS over TLS plus een VPN: welk deel is beschermd

DNS over TLS versleutelt de uitwisseling tussen een client en de resolver die hij koos, en de resolver leest nog steeds de naam. Die zin lost het grootste deel van de verwarring rond DoT plus een VPN op. De tunnel bepaalt welke weg de versleutelde query neemt, terwijl de resolver nog steeds leert wat er gevraagd is. Geen van beide mechanismen vervangt het andere, en geen maakt het andere overbodig.

Vier controles bepalen of de opzet die u hebt de opzet is die u denkt te hebben.

Controle 1: wat de versleuteling dekt

DoT wikkelt de DNS-uitwisseling in TLS, zodat een waarnemer op de route een verbinding naar een adres en poort ziet in plaats van een naam in een query. De resolver zelf ontsleutelt en antwoordt. Vergelijk het met DNS over HTTPS: beide versleutelen, en ze gebruiken verschillende transporten, dus een netwerk dat webverkeer toestaat, staat niet automatisch een DoT-verbinding toe.

Dat onderscheid telt wanneer een captive portal of een filterende middenbox 443 toestaat en 853 blokkeert. Het hulpmiddel dat daar werkte, is geen bewijs dat het andere zal werken.

Controle 2: welke route de query neemt

De route is een kwestie van clientbeleid. Een DoT-resolver is te bereiken via de tunnel, erbuiten, of via een pad dat met het netwerk verandert. Welke gebeurt, hangt af van de routes en van of de client zijn eigen DNS-socket beschermt. Een tunnel die al het verkeer vangt, neemt de query meestal mee, wat het resolveradres ook zegt.

Een resolveradres van een derde partij in een test zien bewijst geen omzeiling, en versleuteling zien bewijst niet de bedoelde ontvanger. Lees de resolver en het pad apart, en beslis dan of het paar is wat u hebt ontworpen.

Controle 3: interne namen

Een organisatie die interne namen publiceert, heeft een resolver nodig die die records houdt. Een openbare DoT-dienst kent uw persoonlijke naamruimte niet, en de client daarop richten garandeert dat die namen mislukken. Dit is de meest voorkomende praktische regressie wanneer iemand versleutelde DNS aanzet op een beheerd apparaat.

Houd de interne resolver voor interne suffixen en versleutel die sprong als het beleid dat vereist, in plaats van hem te vervangen door een openbare aanbieder.

Controle 4: gedrag bij een fout

Een strikte resolverinstelling zonder bereikbare resolver levert een naamresolutiefout op terwijl de tunnel blijft staan. Kijk naar de platformmodus en de gedocumenteerde terugval in plaats van sleutels of certificaten aan te raken.

Een terugval die stilletjes gewone DNS gebruikt, is een beleidsbeslissing, geen gemak. Beslis of de fout zichtbaar moet zijn of moet terugvallen op iets zwakkers, en schrijf het antwoord op.

Vertrouw het certificaat, niet het antwoord

Gebruik de hostnaam van de aanbieder en de verificatieconfiguratie die voor de dienst gedocumenteerd zijn. TLS-controles uitschakelen zodat een onbekende resolver antwoordt, geeft u een versleuteld kanaal naar een niet-geverifieerd eindpunt, wat op één bepaald punt slechter is dan de gewone query die het verving: het ziet er veilig uit. De specificatie voor DNS over TLS zet de authenticatieverwachting achter die controle uiteen.

Een antwoord van een resolver die u niet kunt authenticeren, is een bewering, geen resultaat.

Wat dit onverklaard laat

DoT verbergt de naam niet voor de resolver, verbergt het bestemmingsadres van de verbinding niet voor het netwerk en beslist niet of de query door de tunnel ging. Dat zijn drie afzonderlijke vragen met drie afzonderlijke antwoorden.

Schrijf de resolveridentiteit, het transitpad en het beleid voor interne namen op als drie regels. De volgende DNS-vraag die u krijgt, is er een van.