Versleutelt je VPN de DNS, of alleen de volgende hop?

Versleutelde DNS inschakelen op de VPN-server wordt vaak beschreven als het dichten van een lek, en die beschrijving verbergt welke verbinding veranderde. De hop van client naar resolver en de hop van resolver naar upstream zijn afzonderlijke verbindingen met afzonderlijke eigenaren. Als je de een versleutelt, blijft de ander precies zoals die was.

Schrijf op wie de query in elke fase ontvangt voordat je een configuratiebestand aanraakt.

Twee opstellingen lijken op een instellingenpagina op elkaar

In de eerste opstelling draait het apparaat zelf DNS over TLS, en de tunnel draagt die verbinding alleen naar een resolver die jij hebt gekozen. De TLS-sessie eindigt bij de resolver, wat betekent dat de resolver de query ziet en de VPN-uitgang versleutelde tekst ziet die hij niet kan lezen. In de tweede opstelling stuurt het apparaat gewone DNS via de tunnel naar een doorgever op de VPN-host, en die doorgever opent zijn eigen versleutelde verbinding naar een upstream-resolver. In een functielijst zien beide eruit als "versleutelde DNS met een VPN", en ze plaatsen de leesbare query in verschillende gebouwen.

Het verschil is meetbaar in plaats van filosofisch. Zoek de TLS-sessie op de client of op de server, en je weet welke opstelling je werkelijk hebt.

Breng de resolverketen in kaart voordat je hem wijzigt

Tel de resolvers op het pad en benoem de rol van elk. Een doorgevende component geeft een verzoek aan een andere resolver, terwijl een recursieve resolver het werk doet om een antwoord te vinden en rechtstreeks met gezaghebbende servers kan praten. Die rollen zijn juist om deze reden apart gedefinieerd, en de RFC 9076-resolverdefinities zijn het lezen waard voordat je aanneemt dat er één upstream-bestemming bestaat. Een host die zijn eigen recursieve resolver draait heeft geen enkele "upstream" om te versleutelen, wat het hele plan ongeldig maakt.

Vraag dan welke component de client is geconfigureerd om te gebruiken. Een DNS-adres dat door het VPN-profiel wordt gepusht vertelt je waar queries heen gaan, niet welk proces ze beantwoordt.

Let ook op het faalgedrag. Als de versleutelde upstream onbereikbaar wordt, faalt de doorgever dan gesloten, valt hij terug op platte tekst, of valt hij terug op een andere resolver? Die beslissing hoort in het verslag, want ze verandert de privacygarantie op het moment dat de tunnel het minst gezond is.

Controleer welke hop versleuteld is

Begin op de client en stel vast of die een TLS-sessie naar poort 853 heeft. Een query die via poort 53 correct wordt opgelost, bewijst niets over versleuteling.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Ga dan naar de VPN-host en zoek de uitgaande versleutelde verbinding die de doorgever heeft geopend. De socket-tabel vertelt je of er een upstream-TLS-sessie bestaat, en welk proces die bezit:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Als de client een TLS-sessie toont en de server geen, zit je in de eerste opstelling en kan de server queries die hij op IP-niveau doorstuurt niet lezen. Als de server de TLS-sessie toont en de client gewoon poort 53-verkeer binnen de tunnel, zit je in de tweede opstelling: de volgende hop is beschermd, en de doorgever leest nog steeds elke naam die het apparaat vraagt. Dat tweede resultaat is geen storing, maar het end-to-endversleuteling noemen is verkeerd.

Leg de eigenaar en het faalgedrag vast

Eigendom bepaalt wat je mag beloven. De eigenaar van het apparaat beheert een versleutelde verbinding aan de clientkant, terwijl de VPN-beheerder de volgende verbinding beheert die zijn doorgever maakt. Wie geen van beide beheert, kan alleen het pad beschrijven.

Controleer interne naamgeving voordat je iets inschakelt. Organisatienamen naar een publieke resolver sturen is geen gelijkwaardig ontwerp, en een split-horizon-zone die alleen binnen het netwerk bestaat, wordt upstream helemaal niet opgelost. Test na de wijziging één interne en één publieke naam, en bewaar het resultaat bij de configuratiewijziging. Als het versleutelde pad de resolutie voor interne hosts breekt, is de oplossing een resolverregel met beperkte reikwijdte en geen bredere tunnel.

Sluit af met één zin per hop: welke component de query ontving, of die hop versleuteld was, en wie de naam kan lezen. Als de zin over de VPN-host nog steeds zegt dat hij queries kan lezen, moet de documentatie dat ook zeggen, want een diagram dat het tegendeel beweert, wordt vertrouwd door iemand die de commando's nooit heeft uitgevoerd.