Je VPN duwt drie DNS-servers naar voren: welke antwoordt?

Open de instellingenpagina na het verbinden en er staan drie DNS-adressen; de auditvraag is welke je laatste query heeft afgehandeld. Het aantal alleen antwoordt nergens op, omdat een client-push, een fysieke interface en een beleid per domein allemaal in dezelfde weergave schrijven. Die vermeldingen hebben verschillende bereiken, en het bereik, niet de positie, bepaalt wie antwoordt. Begin met het scheiden van de bronnen en test dan degene die de naam bezit die jij belangrijk vindt.

Waarom de lijst langer is dan je profiel

Een VPN-client duwt resolveradressen voor de tunnelverbinding, en het besturingssysteem houdt ze naast wat de fysieke interface al had. Een router, een zakelijke DHCP-lease, een tweede VPN en een beleid per domein dragen elk hun eigen vermelding bij. Drie adressen op de pagina kunnen dus drie bereiken betekenen in plaats van drie kandidaten voor één taak. Het aantal als bewijs van een lek lezen is de eerste fout in deze audit.

Binnen één interface probeert een client zijn servers wel in volgorde, dus een geordende lijst is niet zinloos. Wat geen wachtrij is, is de samengevoegde weergave, waarin vermeldingen uit het profiel, de fysieke verbinding en regels per domein zonder één rangorde naast elkaar staan. Dat onderscheid bepaalt wat je test: volgorde verklaart gedrag binnen één bereik, en bereik verklaart al het andere.

Versleutelde DNS breekt het beeld van binnenuit een toepassing. Een browser of chatclient met een eigen DNS-over-HTTPS-resolver stuurt queries volledig langs de lijst van het besturingssysteem, dus de adressen op de instellingenpagina beschrijven verkeer dat de app nooit heeft gegenereerd. Controleer de eigen resolverinstelling van de app voordat je het profiel de schuld geeft van een naam die verkeerd uitkwam.

Wat elk van de drie controles zegt

Elke bron laat zijn spoor op een andere plek achter, en geen enkel commando toont ze allemaal. Dit is de mapping die het waard is om naast de instellingenpagina te houden:

Op een systeem met systemd-resolved is resolvectl status gezaghebbend, omdat het DNS per verbinding samen met de routeringsdomeinen rapporteert. macOS antwoordt via scutil --dns, dat resolvers met een bereik op volgorde van proberen opsomt. Windows splitst de twee helften: Get-DnsClientServerAddress voor servers per interface en Get-DnsClientNrptPolicy voor de suffixregels. Voer het commando uit dat bij de werkelijk gebruikte resolver hoort, want een machine met een containerruntime en een desktopresolver kan er meer dan één geïnstalleerd hebben.

Een reserveresolver die je zone niet kan beantwoorden

Een tweede vermelding is er meestal voor beschikbaarheid, en beschikbaarheid werkt alleen als de reserve de namen kent. Vraag een publieke resolver naar een interne hostnaam en hij geeft NXDOMAIN terug, of een wildcard-antwoord uit een zoekdomein dat niets met je te maken heeft. Een failover die niemand controleerde, veroorzaakt dan een storing precies op het moment dat die nodig is.

Split DNS bestaat om dat te voorkomen: bedrijfssuffixen gaan naar een resolver die de zone heeft, en publieke namen blijven op het standaardpad. Het ontwerp is degelijk, en het hangt ervan af of de suffixlijst compleet is. Microsoft documenteert het resolverbeleid per suffix dat dit op Windows aanstuurt, en hetzelfde idee verschijnt als routeringsdomeinen in systemd-resolved en als resolvers met een bereik op macOS.

Vergelijk de zones die de reserve mag beantwoorden met de suffixes in het beleid. Die vergelijking vindt de leemte voordat een gebruiker meldt dat één interne site na een tunnelwijziging niet meer oploste.

Vraag via het beleid, niet eromheen

Vraag via de resolver van het besturingssysteem, want een rechtstreekse query naar een server omzeilt het beleid en meldt alleen wat die server zou zeggen. Het verschil tussen de twee antwoorden is het hele punt:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Als de systeemquery een privéadres teruggeeft terwijl de rechtstreekse query NXDOMAIN teruggeeft, werkt het beleid en is de reserve het zwakke punt. Als beide hetzelfde publieke antwoord teruggeven, wordt de naam buiten het bedoelde bereik opgelost, en de suffixlijst is de plek om te kijken. Bewaar beide uitvoer, want een resolverdiscussie is sneller beslecht met twee regels dan met een schermafbeelding van de instellingenpagina.

Oefen daarna het foutpad, want een reserve die niemand testte is een aanname. Maak de voorkeursresolver voor één query een zwart gat en kijk welk adres terugkomt:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Verwijder die route zodra de query klaar is, anders erft de volgende persoon een raadsel. Als interne namen in dat venster nog steeds oplossen, heeft iets buiten het bedoelde bereik ze beantwoord. Als ze in plaats daarvan time-out gaan, ontbreekt de reserve of is die correct afgebakend, en het eigen log van de resolver vertelt je welke van de twee het was.

Beslis: behouden, afbakenen of verwijderen

Behoud een tweede resolver wanneer die de naamruimte beantwoordt die je nodig hebt en bereikbaar blijft onder het profiel. Bakendeer hem af wanneer hij één suffix en niets anders mag zien, en verwijder hem wanneer hij geen bereik en geen gedocumenteerd doel heeft. Een vermelding zonder taak is een toekomstig lek zonder voordeel, en een leveranciersstandaard is geen doel.

Leg het resultaat vast in vier kolommen: suffix, resolver, interface en eigenaar. Die regel beantwoordt de volgende auditvraag sneller dan welke schermafbeelding dan ook, en hij overleeft de clientupdate die de lijst stil herschikt.