VPN-en din skyver tre DNS-servere: hvilken svarer?

Åpne innstillingssiden etter tilkobling, og tre DNS-adresser står oppført; revisjonsspørsmålet er hvilken som håndterte din siste spørring. Antallet alene svarer ikke på noe, fordi en klientpush, et fysisk grensesnitt og en policy per domene alle skriver i samme visning. Disse oppføringene har forskjellige omfang, og omfanget, ikke plasseringen, avgjør hvem som svarer. Begynn med å skille kildene, og test deretter den som eier navnet du bryr deg om.

Hvorfor listen er lengre enn profilen din

En VPN-klient skyver resolveradresser for tunnelkoblingen, og operativsystemet holder dem ved siden av det det fysiske grensesnittet allerede hadde. En ruter, en bedrifts-DHCP-lease, en andre VPN og en policy per domene bidrar hver med sin egen oppføring. Tre adresser på siden kan derfor bety tre omfang i stedet for tre kandidater til én jobb. Å lese antallet som bevis på en lekkasje er den første feilen i denne revisjonen.

Innenfor ett grensesnitt prøver en klient faktisk serverne sine i rekkefølge, så en ordnet liste er ikke meningsløs. Det som ikke er en kø, er den sammenslåtte visningen, der oppføringer fra profilen, den fysiske lenken og regler per domene står side om side uten én rangering. Den forskjellen avgjør hva du tester: rekkefølgen forklarer atferd innenfor ett omfang, og omfanget forklarer alt annet.

Kryptert DNS bryter bildet fra innsiden av en applikasjon. En nettleser eller chatklient med sin egen DNS-over-HTTPS-resolver sender spørringer helt utenom listen til operativsystemet, så adressene på innstillingssiden beskriver trafikk appen aldri genererte. Sjekk appens egen resolverinnstilling før du gir profilen skylden for et navn som kom feil ut.

Hva hver av de tre kontrollene forteller

Hver kilde setter sitt merke på et annet sted, og ingen enkelt kommando viser dem alle. Dette er kartleggingen som er verdt å ha ved innstillingssiden:

På et system som bruker systemd-resolved, er resolvectl status autoritativ, fordi den rapporterer DNS per kobling sammen med rutingsdomenene. macOS svarer gjennom scutil --dns, som lister opp resolvere med omfang i den rekkefølgen de prøves. Windows deler de to halvdelene: Get-DnsClientServerAddress for servere per grensesnitt og Get-DnsClientNrptPolicy for suffiksreglene. Kjør kommandoen som hører til resolveryen som faktisk brukes, for en maskin med containerruntime og en skrivebordsresolver kan ha mer enn én installert.

En reserveresolver som ikke kan svare for sonen din

En andre oppføring er vanligvis der for tilgjengelighet, og tilgjengelighet virker bare hvis reserven kjenner navnene. Spør en offentlig resolver om et internt vertsnavn, og den returnerer NXDOMAIN eller et jokertegnsvar fra et søkedomene som ikke har noe med deg å gjøre. En failover ingen har kontrollert, gir da et utfall på nøyaktig det tidspunktet det trengs.

Split DNS finnes for å hindre det: bedriftssuffikser går til en resolver som holder sonen, og offentlige navn blir på standardveien. Designet er solid, og det avhenger av at suffikslisten er komplett. Microsoft dokumenterer resolverpolicyen per suffiks som driver dette på Windows, og den samme ideen dukker opp som rutingsdomener i systemd-resolved og som resolvere med omfang på macOS.

Sammenlign sonene reserven kan svare for, med suffiksene som finnes i policyen. Den sammenligningen finner hullet før en bruker rapporterer at ett internt nettsted sluttet å slå opp etter en tunnelendring.

Spør gjennom policyen, ikke utenom den

Spør gjennom operativsystemets resolver, fordi en direkte spørring til en server omgår policyen og bare rapporterer hva den serveren ville sagt. Forskjellen mellom de to svarene er hele poenget:

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

Hvis systemspørringen returnerer en privat adresse mens den direkte spørringen returnerer NXDOMAIN, virker policyen, og reserven er det svake punktet. Hvis begge returnerer samme offentlige svar, slås navnet opp utenfor omfanget du mente, og suffikslisten er stedet å se. Ta vare på begge utdataene, for en resolverdiskusjon avgjøres raskere med to linjer enn med et skjermbilde av innstillingssiden.

Prøv deretter feilveien, for en reserve ingen har testet, er en antagelse. Gjør den foretrukne resolveren til et svart hull for én spørring, og se hvilken adresse som kommer tilbake:

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

Slett ruten så snart spørringen er ferdig, ellers arver neste person et mysterium. Hvis interne navn fortsatt slås opp i det vinduet, har noe utenfor det tiltenkte omfanget svart dem. Hvis de i stedet går ut på tid, mangler reserven eller den er riktig avgrenset, og resolverens egen logg forteller deg hvilken av de to det var.

Bestem: behold, avgrens eller fjern

Behold en andre resolver når den svarer på navnerommet du trenger og forblir tilgjengelig under profilen. Avgrens den når den bare skal se ett suffiks og ingenting annet, og fjern den når den verken har et omfang eller et dokumentert formål. En oppføring uten jobb er en fremtidig lekkasje uten nytte, og en leverandørstandard er ikke et formål.

Registrer resultatet som fire kolonner: suffiks, resolver, grensesnitt og eier. Den linjen svarer på neste revisjonsspørsmål raskere enn noe skjermbilde, og den overlever klientoppdateringen som stille omorganiserer listen.