VPN-DNS versus DoH in de browser: wat een lektest je niet kan vertellen

De lektestpagina zegt dat je DNS in orde is, de browserbadge zegt veilig, en de interne wiki laadt nog steeds niet. Alle drie kunnen tegelijk waar zijn, want het adres van een resolver is niet hetzelfde als het beleid dat hem koos of het pad dat de query aflegde. Wat mensen een DNS-lek noemen, is eigenlijk één vraag: welke resolver ontving de naam, en was die keuze opzettelijk? Dat uitzoeken vergt drie controles, en alleen de laatste houdt het wijzigen van een instelling in.

Mythe één: de badge noemt je resolver

Een lektest lost een testnaam op en meldt het adres dat antwoordde. Hij meldt niet het beleid dat die resolver koos, en wanneer de query in DNS over HTTPS is verpakt, kan een tussenbox op het pad de naam helemaal niet zien. Twee heel verschillende machines geven dezelfde geruststellende badge: één waar de VPN 10.8.0.1 pushte en de browser hem gebruikt, en één waar de browser de systeemlijst negeerde en de naam via de tunnel naar zijn eigen versleutelde provider stuurde.

Het verschil telt op het moment dat een privénaam faalt. In de eerste opzet antwoordt de VPN-resolver voor de bedrijfszone; in de tweede heeft de browser hem nooit gevraagd, dus de korte hostnaam wordt niet opgelost en de fout lijkt op een kapotte VPN. De controle is geen nieuwe lektest, het is een opzoeking van een naam die slechts één resolver kent.

Mythe twee: de browser verlaat de tunnel

DNS kiest een adres, routing draagt de verbinding, en dat zijn twee aparte lagen. Een query naar een publieke DoH-provider is nog steeds TCP poort 443 naar een routeerbaar adres. Als je routetabel de standaardroute de tunnel in stuurt, gaat die query ook door de tunnel. Het merk van de resolver bepaalt het pad niet.

Wat browser-DoH verandert, is de ontvanger van de namen. Dat is een echte privacybeslissing en een echte beleidsbeslissing, maar geen omzeiling van routing. Als je eis is dat namen bij de VPN-exploitant blijven, dan voldoet een versleutelde query aan iemand anders niet aan die eis, terwijl hij de tunnel nog steeds voor de werkelijke verbinding gebruikt.

Mythe drie: elke VPN overstemt elke browser

Veilige DNS in een browser heeft modi, geen schakelaar: uit, een standaardprovider met fallback, een aangepaste sjabloon of een beleid dat het besturingssysteem of de organisatie afdwingt. Juist het fallbackgeval levert de periodieke meldingen op. Wanneer het versleutelde eindpunt onbereikbaar is, kan de browser terugvallen op de systeemresolver, zodat dezelfde laptop een privénaam op maandag correct oplost en dinsdag niet.

Tegelijkertijd zetten de meeste VPN-clients de systeemresolver zodra de verbinding opkomt en herstellen ze de vorige wanneer hij wegvalt. Een browser met een eigen versleutelde resolver merkt die herstelling helemaal niet op. Daarom gedraagt hetzelfde profiel zich anders op twee laptops en daarom ziet resolv.conf er correct uit terwijl de browser nog iemand anders vraagt.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Voer die uit terwijl je verbonden bent, noteer welke domeinen elke resolver opeist, en vergelijk met wat de browser over zijn eigen modus meldt. Mozilla's DoH-documentatie is een redelijke beschrijving van hoe het standaard- en fallbackgedrag van een browser zou moeten werken.

De beslissing heeft drie invoerwaarden, niet één

Privénamen, vertrouwen in de exploitant en bereikbaarheid bepalen de juiste opzet. Namen die alleen de VPN-resolver kent, dwingen gesplitste DNS af: het privésuffix gaat naar de gepushte resolver, al het overige volgt het beleid dat je voor openbare namen koos. Vertrouwen in de exploitant bepaalt of openbare namen ook naar die resolver of naar een aparte dienst moeten. Bereikbaarheid bepaalt of je gekozen versleutelde resolver op dit netwerk überhaupt bruikbaar is.

Geen van deze regels is een universele aanbeveling. Een resolver die door de VPN wordt beheerd, concentreert waarnemingen bij die exploitant; een aparte dienst voegt nog een ontvanger van de opgevraagde namen toe. Geen van beide opzetten bewijst iets over bewaring, tenzij je het beleid leest.

Schrijf de beslissing per profiel op, want deze instellingen driften. Een profiel dat vorige maand een resolver pushte, pusht vandaag misschien niets, en de browser houdt graag een oud aangepast eindpunt dat nog antwoordt. Wat in de notitie hoort, is het adres van de resolver, de suffixen die hij bezit en de browsermodus, niet het merk van de dienst.

Test het beleid waarvan je denkt dat je het hebt geconfigureerd

Test op naam, niet op badge. Los een openbare naam en een privénaam op via de systeemresolver, en herhaal dat dan in de browser met zijn eigen veilige DNS-instelling in de modus die je wilt gebruiken. Als de privénaam alleen in de browser faalt, heb je de ontvanger-mismatch gevonden zonder één VPN-instelling aan te raken.

Verbind daarna opnieuw en controleer het herstel, want daar leven de overdrachtsfouten: verbreek, bevestig dat de vorige resolver terugkwam, verbind opnieuw, bevestig dat de gepushte terugkwam. Test tot slot een browser met een beheerd beleid als je die hebt, want die modus kan je wijziging volledig weigeren en stil de vorige resolver houden.

Begin met de naamruimtevraag en je voorkomt het meeste hiervan. Als de machine interne namen moet bereiken, is de versleutelde resolver van de browser een beslissing over alleen de openbare helft, en de privéhelft blijft bij wat de VPN ook pushte.