DNS-lektest: een resolver-naam is niet de route

Drie opstellingen gelden als correcte DNS voor een VPN-gebruiker: query's naar de resolver van de operator, query's naar een versleutelde resolver die je zelf hebt gekozen, en split DNS die werknemersnamen naar de organisatie stuurt. Een lektest meldt één resolver, en dat ene label kan je niet vertellen welke opstelling je werkelijk hebt. Bepaal eerst het bedoelde beleid en test daarna daartegen. Anders vergelijk je een getal met een gevoel.

Bepaal wat je wilde voordat je het resultaat leest

Benoem het beleid in één zin: alle namen naar de VPN-resolver, alle namen naar een gekozen versleutelde resolver, of split DNS met interne namen naar de organisatie. Elk is verdedigbaar voor een andere gebruiker, en elk levert een ander verwacht antwoord op. Zonder die zin lijkt elk resultaat dat afwijkt van een schermafbeelding in een forumbericht verontrustend. Schrijf het beleid op vóór de eerste test.

Een test die wordt uitgevoerd voordat het beleid is gedefinieerd, meet niets. Hij levert een resolver-naam zonder enig referentiepunt.

Een resolver-naam bewijst noch het pad noch de ontvanger

Twee vragen tellen: wie de query ontving, en welke route die droeg. Een resolver van een derde partij kan via de tunnel bereikbaar zijn terwijl een instellingenscherm het adres van de provider toont. Het label op een lektestpagina beschrijft het gezichtspunt van de waarnemer, niet je routingtabel.

Een browser kan zijn eigen versleutelde DNS gebruiken terwijl het siteverkeer door de tunnel gaat, en antwoorden uit de cache kunnen een pagina laden zonder nieuwe opzoeking. Daarom zegt een openbaar IP-resultaat niets over DNS. DoH en DoT beschermen de query onderweg naar de resolver, en die resolver ziet de namen nog steeds.

resolvectl status
resolvectl query example.com
dig +short example.com

Split DNS maakt meerdere resolvers correct

Een organisatie kan interne namen naar zijn eigen DNS sturen en al het andere elders. Een test die meerdere resolvers vermeldt, kan daarom het bedoelde beleid beschrijven en niet een storing. Vergelijk de waargenomen set met de gedocumenteerde split DNS-regels voordat je iets uitschakelt. De interne resolver uitschakelen om een testpagina schoner te laten lijken, breekt privé-namen.

Split tunneling en split DNS zijn verschillende keuzes: de een routeert pakketten, de ander routeert vragen. Een tunnelroute wijzigen verplaatst geen naamopzoeking, en de resolver wijzigen herstelt geen websitepad. IPv6 is een derde vraag, want een onbedoelde IPv6-verbinding is niet automatisch een DNS-lek.

Maak van het resultaat een onderzoek

Noteer het bedoelde beleid en de veilige DNS-instelling van de browser vóór het testen. Voer de test uit met de tunnel actief, noteer elke resolver die hij noemt, en vergelijk de set met het beleid en niet met één verwacht adres.

Herhaal na een herverbinding als het symptoom dan optreedt, want een beleid dat bij het verbinden wordt toegepast, kan later verloren gaan. Gebruik de documentatie van de client voor interne DNS-uitzonderingen in plaats van de instellingen te raden.

Repareer de mismatch die je vond: een browserkeuze, een VPN-DNS-instelling of een split DNS-regel. Als query's moeten stoppen wanneer de tunnel faalt, is de kill switch een aparte instelling, en DNS-configuratie alleen levert die niet. De RFC 8484-specificatie is nuttig wanneer je moet uitleggen wat een versleutelde resolver verbergt en wat niet.