VPN-en din skyv tre DNS-tenarar: kva for ein svarar?

Opne innstillingssida etter tilkopling, og tre DNS-adresser står oppførte; revisjonsspørsmålet er kva for ei som handsama den siste spørjinga di. Talet åleine svarar ikkje på noko, fordi eit klientpush, eit fysisk grensesnitt og ein policy per domene alle skriv i same visning. Desse oppføringane har ulike omfang, og det er omfanget, ikkje plasseringa, som avgjer kven som svarar. Byrja med å skilje kjeldene, og test deretter den som eig namnet du bryr deg om.

Kvifor lista er lengre enn profilen din

Ein VPN-klient skyv resolveradresser for tunnellkoblinga, og operativsystemet held dei ved sida av det det fysiske grensesnittet alt hadde. Ein ruter, ein bedrifts-DHCP-lease, ein annan VPN og ein policy per domene bidreg kvar med si eiga oppføring. Tre adresser på sida kan difor tyde tre omfang i staden for tre kandidatar til éin jobb. Å lese talet som prov på ein lekkasje er den første feilen i denne revisjonen.

Innanfor eitt grensesnitt prøver ein klient faktisk tenarane sine etter tur, så ei ordna liste er ikkje meiningslaus. Det som ikkje er ei kø, er den samanslåtte visninga, der oppføringar frå profilen, den fysiske lenkja og reglar per domene står side om side utan éin rangering. Den skilnaden avgjer kva du testar: rekkjefølgja forklarar åtferd innanfor eitt omfang, og omfanget forklarar alt anna.

Kryptert DNS bryt biletet frå innsida av ein applikasjon. Ein nettlesar eller chatklient med eigen DNS-over-HTTPS-resolver sender spørjingar heilt utanom lista til operativsystemet, så adressene på innstillingssida skildrar trafikk appen aldri genererte. Sjekk den eigne resolverinnstillinga til appen før du gir profilen skulda for eit namn som kom feil ut.

Kva kvar av dei tre kontrollane fortel

Kvar kjelde set merket sitt på ein annan stad, og ingen einskild kommando viser dei alle. Dette er kartlegginga som er verdt å ha ved innstillingssida:

På eit system som brukar systemd-resolved, er resolvectl status autoritativ, fordi ho rapporterer DNS per kobling saman med rutingsdomena. macOS svarar gjennom scutil --dns, som listar opp resolverar med omfang i den rekkjefølgja dei blir prøvde. Windows deler dei to halvdelane: Get-DnsClientServerAddress for tenarar per grensesnitt og Get-DnsClientNrptPolicy for suffiksreglane. Køyr kommandoen som høyrer til resolveryen som faktisk blir brukt, for ein maskin med containerruntime og ein skrivebordsresolver kan ha meir enn éin installert.

Ein reserveresolver som ikkje kan svare for sona di

Ei andre oppføring er vanlegvis der for tilgjenge, og tilgjenge verkar berre om reserven kjenner namna. Spør ein offentleg resolver om eit internt vertsnamn, og han returnerer NXDOMAIN eller eit jokerteiknsvar frå eit søkjedomene som ikkje har noko med deg å gjere. Ein failover ingen har kontrollert, gir då eit utfall på nøyaktig det tidspunktet det trengst.

Split DNS finst for å hindre det: bedriftssuffiks går til ein resolver som held sona, og offentlege namn blir verande på standardvegen. Designet er solid, og det er avhengig av at suffikslista er komplett. Microsoft dokumenterer resolverpolicyen per suffiks som driv dette på Windows, og den same ideen dukkar opp som rutingsdomene i systemd-resolved og som resolverar med omfang på macOS.

Samanlikn sonene reserven kan svare for, med suffiksa som finst i policyen. Den samanlikninga finn holet før ein brukar rapporterer at éin intern nettstad slutta å slå opp etter ei tunnellendring.

Spør gjennom policyen, ikkje utanom han

Spør gjennom resolveryen til operativsystemet, fordi ei direkte spørjing til ein tenar omgår policyen og rapporterer berre kva den tenaren ville sagt. Skilnaden mellom dei to svara er heile poenget:

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

Om systemsøkjinga returnerer ei privat adresse medan den direkte spørjinga returnerer NXDOMAIN, verkar policyen, og reserven er det svake punktet. Om begge returnerer same offentlege svar, blir namnet slått opp utanfor omfanget du meinte, og suffikslista er staden å sjå. Ta vare på begge utdata, for ein resolverdiskusjon blir avgjord raskare med to linjer enn med eit skjermbilete av innstillingssida.

Prøv deretter feilvegen, for ein reserve ingen har testa, er ei antaking. Gjer den føretrekte resolveryen til eit svart hòl for éi spørjing, og sjå kva adresse som kjem 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 ruta så snart spørjinga er ferdig, elles arvar neste person eit mysterium. Om interne namn framleis blir slått opp i det vindauget, har noko utanfor det tiltenkte omfanget svart dei. Om dei i staden går ut på tid, manglar reserven eller han er rett avgrensa, og den eigne loggen til resolveryen fortel deg kven av dei to det var.

Bestem: behald, avgrens eller fjern

Behald ein annan resolver når han svarar på namnerommet du treng og blir verande tilgjengeleg under profilen. Avgrens han når han berre skal sjå eitt suffiks og ingenting anna, og fjern han når han korkje har eit omfang eller eit dokumentert føremål. Ei oppføring utan jobb er ein framtidig lekkasje utan nytte, og ein leverandørstandard er ikkje eit føremål.

Registrer resultatet som fire kolonnar: suffiks, resolver, grensesnitt og eigar. Den linja svarar på neste revisjonsspørsmål raskare enn noko skjermbilete, og ho overlever klientoppdateringa som stille omorganiserer lista.