Privé-DNS versus VPN: wat elke laag werkelijk dekt

Je telefoon heeft privé-DNS ingesteld op een hostnaam van een provider en tegelijkertijd een VPN-app draaien. Het is redelijk om aan te nemen dat een van beide nu de naamopzoekingen regelt. Geen van beide doet dat, in de zin die die zin suggereert, en de snelste manier om te zien waarom is één verzoek te volgen vanaf het moment dat je op een link tikt.

Deze twee functies zitten op verschillende punten in dezelfde reis. Privé-DNS versleutelt de vraag die je aan een resolver stelt. Een VPN verandert de route die de verbinding van het antwoord neemt.

Loop het dus in volgorde door op een apparaat waar beide zijn ingeschakeld, en let op wat elke laag nog kan zien.

Stap één: de opzoeking verlaat de app

Je tikt op een link. Voordat er iets verbindt, heeft de app een adres nodig voor die hostnaam. Op Android is het relevante scherm Instellingen, Netwerk en internet, Privé-DNS. Als je Hostnaam van privé-DNS-provider kiest, zet dat het apparaat in de strikte modus: het doet DNS over TLS naar die hostnaam op poort 853, en als de versleutelde uitwisseling mislukt, mislukt de opzoeking in plaats van stil terug te vallen op platte tekst op poort 53.

Dat is een belangrijk verschil met Automatisch, dat opportunistische versleuteling gebruikt en graag een onversleutelde resolver gebruikt wanneer het netwerk roet in het eten gooit. Als je doel is dat opzoekingen nooit in het openbaar gebeuren, is de strikte modus met een provider-hostnaam de instelling die daarbij past.

Hier is het eerste dat de doorloop blootlegt: de opzoeking is beschermd tegen het lokale netwerk, en de resolver leert de naam alsnog. Versleuteling dekt de sprong. De beheerder van die resolver ziet het verzoek omdat beantwoorden zijn werk is.

Stap twee: de verbinding neemt een andere route

De resolver geeft een adres terug en de app maakt daar verbinding mee. Deze stap wordt niet beïnvloed door hoe de opzoeking is versleuteld. Zonder tunnel verlaat de verbinding je normale openbare adres, en het bestemmings-IP en de TLS-handshake maken de hostnaam meestal toch zichtbaar voor het netwerk, met of zonder versleutelde DNS.

Zet de VPN aan en dit is de stap die verandert. Verkeer dat aan het routeringsbeleid van de client voldoet, gaat door de tunnel, het lokale netwerk ziet een verbinding naar het VPN-eindpunt, en de site ziet doorgaans het uitgangsadres. Naamresolutie kan, afhankelijk van wat de client meestuurt, ook binnen de tunnel reizen.

Die scheiding is de hele vergelijking in één zin. DNS-versleuteling beantwoordt wie de vraag kan lezen. Een VPN beantwoordt waar het gesprek heen gaat.

Stap drie: in de tunnel wordt DNS een beleidsvraag

Nu werken de twee functies samen, en de browser is de gebruikelijke bron van verrassing. Een browser met zijn eigen instelling voor veilige DNS kan opzoekingen via HTTPS naar zijn gekozen resolver sturen in plaats van het besturingssysteem te vragen. De privé-DNS-instelling van Android reikt niet in die beslissing.

In Firefox staat de schakelaar onder Instellingen, Privacy en beveiliging, Veilige DNS inschakelen. In Chrome staat hij onder Instellingen, Privacy en beveiliging, Veilige DNS gebruiken. Beide kunnen op een specifieke provider worden gezet of uit blijven, en als ze aan staan, wordt de DNS-configuratie van de tunnel voor die opzoekingen omzeild, ook al gebruikt het paginaverkeer nog steeds de tunnel.

Als de VPN zijn eigen resolver meestuurt en de browser op de zijne staat, krijg je een splitsing: namen worden opgelost, pagina’s laden, en de opzoekingen die via de tunnel hadden moeten gaan, gingen er direct uit. Een resolveradres dat afwijkt van het VPN-eindpunt is op zichzelf geen bewijs van een lek, maar een opzoekpad dat je verklaarde bedoeling tegenspreekt, is het waard om te repareren.

Stap vier: interne namen zijn waar het misgaat

Maak verbinding met een werk-VPN en open een intranet-host. Als de veilige DNS van de browser aan staat en naar een openbare resolver wijst, bestaat die naam niet voor de browser. De tunnel is op, al het andere werkt, en één hostnaam faalt met een fout die lijkt of de site platligt.

Dezelfde storing verschijnt omgekeerd op Android. Strikte privé-DNS met een openbare provider lost geen namen op die alleen de interne resolver kent, en de strikte modus heeft geen terugval. De DNS van een telefoon verdelen tussen een openbare versleutelde resolver en een bedrijfsresolver is geen instelling; het is een vraag over routeringsbeleid die beantwoord moet worden door wie de VPN beheert.

Controleer dit voordat je de tunnel de schuld geeft: vraag de interne naam op, en daarna dezelfde naam met de veilige DNS van de browser uitgeschakeld. Als die wordt opgelost, was de resolverkeuze het probleem, niet de verbinding.

Wat de doorloop je zegt te veranderen

Vier schermen dragen bijna alles. Bekijk ze in deze volgorde en schrijf op wat elk zegt, want het antwoord is meestal zichtbaar in de combinatie:

1. Android-instellingen, Netwerk en internet, Privé-DNS: Automatisch of een provider-hostnaam, en welke hostnaam.
2. De instelling voor veilige DNS van de browser: uit, of vastgezet op een specifieke resolver.
3. Het DNS-beleid van de VPN-client: stuurt het een resolver mee, en sluit gesplitste tunneling iets uit dat nog namen nodig heeft?
4. Een test met een interne hostnaam terwijl de tunnel op is, twee keer uitgevoerd, één keer met browser-DNS aan en één keer uit.

Pas daarna de oplossing aan op de eis, niet andersom. Als de eis is dat opzoekingen versleuteld naar buiten gaan en naar een resolver van jouw keuze, stel dan strikte privé-DNS in en zorg dat de browser het daarmee eens is. Als de eis is dat verkeer elders naar buiten gaat, configureer dan de tunnel en verwacht niet langer dat een DNS-instelling je adres verplaatst.

En houd de grenzen in het oog. Geen van beide functies maakt een vijandige bestemming veilig, en geen van beide verwijdert een identiteit waarmee je bent aangemeld. Versleuteling verandert wie de vraag kan lezen; de tunnel verandert waar de verbinding heen gaat; niets daarvan anonimiseert het account.