Split-DNS-opptak: sei kvar kvar observasjon vart gjord

To personar feilsøkjer det same Split-DNS-problemet og får ulike resolver-adresser. Éin brukte eit oppslagsverkty, éin tok opp pakkar på adapteren, og ein tredje las diagnostikken til klienten sjølv. Ingen av dei lyg, og ingen av dei skildrar det same trinnet. Å namngje observasjonspunktet gjer ei motseiing om til eit kart.

Eitt oppslag, fleire observasjonspunkt

For eitt internt namn er det minst fem stader å sjå: applikasjonen og resolver-API-et han kallar, den gjeldande domenepolitikken på klienten, eit opptak på adapter eller filter, ei kontrollert gateway-grense og resolveren som faktisk tek imot spørjinga.

Kvar av dei svarar på eit ulikt spørsmål, og ingen av dei åleine beviser kvar spørjinga gjekk.

Eit opptak på adapteren viser pakkar, ikkje hensikt. Det seier ikkje kva resolver klienten valde, og eit tomt opptak kan bety eit bufra svar eller eit anna resolver-API i staden for ein droppa pakke. Handsame kvar observasjon som prov for eitt trinn. Set deretter trinna saman til ein veg.

Filteret til klienten sit mellom app og leidning

Ein VPN-klient med Split-DNS brukar domenematching før pakken forlèt maskina. Namn i det tunnelerte suffikset går til den interne resolveren; alt anna går til den lokale. Filteret er politikk, og politikken kan variere etter plattform og klientversjon.

Secure Clients rettleiing for Split-DNS frå Cisco dekkjer domenematching og Windows-filteret, og ho skil det ein app ser når han brukar det innebygde resolver-API-et, frå det eit verktøy som nslookup ser. Det er nettopp desse skilnadene som er poenget.

Byrja med den gjeldande profilen og eitt vanleg applikasjonsoppslag. Kvar test som namngjev ein bestemt server, er ein medviten omveg; forklar han med diagnostikken til klienten sjølv, og ikkje lat han bli akseptkriteriet.

nslookup tek ein annan veg enn appen

nslookup byggjer si eiga DNS-spørjing og kan omgå resolverpolitikken til operativsystemet. Det gjer det til eit nyttig verktøy for å stille eit bestemt spørsmål til ein bestemt server, og eit misvisande verktøy for å teste kva ein applikasjon vil oppleve.

På Windows avgjer namneoppløysingspolitikk-tabellen kva suffiks som brukar kva server. Å lese han viser politikken applikasjonen vil følgje, og det er ofte den manglande brikka.

Les politikken, og still deretter det same spørsmålet gjennom den vanlege resolveren:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Krypterte resolverar skjuler spørjinga, ikkje sambandet

Ein nettlesar med sin eigen DNS-over-HTTPS-resolver er ei heilt anna sak. Spørjinga går ut inne i TLS, så eit pakkeopptak viser eit samband til ei resolver-adresse, men ikkje namnet det blir spurt om.

Finn først den administrerte politikken til nettlesaren, og samanlikn han så med eit oppslag frå operativsystemet. Ein nettlesar som får velje sin eigen resolver, ser kanskje ikkje Split-DNS-politikken i det heile.

Same varsemd gjeld for ein kvar klient som leverer sin eigen resolver. Eit opptak som identifiserer fjernsambandet, er ikkje prov for spørringsnamnet. Treng du namnet, hent det frå loggane til resolveren sjølv eller frå diagnostikken til applikasjonen, med personvernreglane som gjeld.

Samanlikn med ein merkt test

Vel eit godkjent internt namn for testing, samt eit offentleg namn utan kjenslevar tyding. For kvart av dei noterer du tidspunktet, posttypen, svaret og politikken du venta.

Der det er tillate, samanlikn mottaket til resolveren med éin smal observasjon frå klient eller gateway:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Send aldri private namn til urelaterte offentlege resolverar berre for å lage ein samanlikning, og rediger alt du deler. Til slutt skil du eit korrekt DNS-svar frå tenestesambandet som følgjer: den oppslåtte private adressa treng framleis ei rute og ei applikasjonsgodkjenning.