Din VPN skubber tre DNS-servere: hvilken svarer?

Åbn indstillingssiden efter tilslutning, og tre DNS-adresser står på listen; revisionsspørgsmålet er, hvilken der håndterede din sidste forespørgsel. Antallet alene svarer ikke på noget, fordi et klient-push, en fysisk grænseflade og en politik per domæne alle skriver i samme visning. De poster har forskellige områder, og området snarere end placeringen afgør, hvem der svarer. Begynd med at skille kilderne ad, og test derefter den, der ejer det navn, du bekymrer dig om.

Hvorfor listen er længere end din profil

En VPN-klient skubber resolveradresser til tunnel-linket, og styresystemet holder dem ved siden af det, den fysiske grænseflade allerede havde. En router, en virksomheds-DHCP-lease, en anden VPN og en politik per domæne bidrager hver med deres egen post. Tre adresser på siden kan derfor betyde tre områder i stedet for tre kandidater til ét job. At læse antallet som bevis på en lækage er den første fejl i denne revision.

Inden for én grænseflade prøver en klient faktisk sine servere i rækkefølge, så en ordnet liste er ikke meningsløs. Det, der ikke er en kø, er den sammenlagte visning, hvor poster fra profilen, det fysiske link og regler per domæne står side om side uden én rangordning. Den forskel afgør, hvad du tester: rækkefølge forklarer adfærd inden for ét område, og område forklarer alt andet.

Krypteret DNS bryder billedet inde fra en applikation. En browser eller en chatklient med sin egen DNS-over-HTTPS-resolver sender forespørgsler helt uden om styresystemets liste, så adresserne på indstillingssiden beskriver trafik, som appen aldrig genererede. Kontrollér appens egen resolverindstilling, før du bebrejder profilen et navn, der kom forkert ud.

Hvad hver af de tre kontroller fortæller

Hver kilde sætter sit mærke et forskelligt sted, og ingen enkelt kommando viser dem alle. Det er mappingen, der er værd at have ved indstillingssiden:

På et system, der bruger systemd-resolved, er resolvectl status autoritativ, fordi den rapporterer DNS per link sammen med rutningsdomænerne. macOS svarer gennem scutil --dns, som viser resolverne med område i den rækkefølge, de prøves. Windows deler de to halvdele: Get-DnsClientServerAddress til servere per grænseflade og Get-DnsClientNrptPolicy til suffiksreglerne. Kør den kommando, der hører til den resolver, der faktisk bruges, for en maskine med containerruntime og en skrivebordsresolver kan have mere end én installeret.

En reserveresolver, der ikke kan svare på din zone

En anden post er normalt der for tilgængelighed, og tilgængelighed virker kun, hvis reserven kender navnene. Spørg en offentlig resolver om et internt værtsnavn, og den returnerer NXDOMAIN eller et jokertegn-svar fra et søgedomæne, der ikke har noget med dig at gøre. Et failover, som ingen har kontrolleret, giver så et udfald på præcis det tidspunkt, hvor det er nødvendigt.

Split DNS findes for at forhindre det: virksomhedssuffikser går til en resolver, der holder zonen, og offentlige navne bliver på standardvejen. Designet er solidt, og det afhænger af, at suffikslisten er komplet. Microsoft dokumenterer resolverpolitikken per suffiks, der driver dette på Windows, og den samme idé optræder som rutningsdomæner i systemd-resolved og som resolver med område på macOS.

Sammenlign de zoner, reserven må svare på, med de suffikser, der findes i politikken. Den sammenligning finder hullet, før en bruger rapporterer, at et internt websted holdt op med at slå op efter en tunnelændring.

Spørg gennem politikken, ikke uden om den

Spørg gennem styresystemets resolver, fordi en direkte forespørgsel til en server omgår politikken og kun rapporterer, hvad den server ville sige. Forskellen mellem de to svar er hele pointen:

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

Hvis systemforespørgslen returnerer en privat adresse, mens den direkte forespørgsel returnerer NXDOMAIN, virker politikken, og reserven er det svage punkt. Hvis begge returnerer det samme offentlige svar, slås navnet op uden for det område, du havde tænkt, og suffikslisten er stedet at kigge. Gem begge uddata, for en resolverdiskussion afgøres hurtigere med to linjer end med et skærmbillede af indstillingssiden.

Prøv derefter fejlvejen, for et reservevalg, som ingen har testet, er en antagelse. Gør den foretrukne resolver til et sort hul for én forespørgsel, og se hvilken adresse der kommer tilbage:

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

Slet den rute, så snart forespørgslen er færdig, ellers arver den næste person et mysterium. Hvis interne navne stadig slås op i det vindue, har noget uden for det tilsigtede område svaret på dem. Hvis de i stedet udløber, mangler reserven, eller den er korrekt afgrænset, og resolverens egen log fortæller dig hvilket af de to det var.

Beslut: behold, afgræns eller fjern

Behold en anden resolver, når den svarer på det navneområde, du har brug for, og forbliver nåelig under profilen. Afgræns den, når den kun skal se ét suffiks og intet andet, og fjern den, når den hverken har et område eller et dokumenteret formål. En post uden et job er en fremtidig lækage uden fordel, og en leverandørstandard er ikke et formål.

Registrér resultatet som fire kolonner: suffiks, resolver, grænseflade og ejer. Den linje svarer på det næste revisionsspørgsmål hurtigere end noget skærmbillede, og den overlever den klientopdatering, der stille omarrangerer listen.