Split-DNS-optagelse: sig, hvor hver iagttagelse blev taget

To personer fejlfinder det samme Split-DNS-problem og får forskellige resolver-adresser. Én brugte et opslagsværktøj, én optog pakker på adapteren, og en tredje læste klientens egne diagnostikdata. Ingen af dem lyver, og ingen af dem beskriver det samme trin. Navngivningen af iagttagelsespunktet gør en modsætning til et kort.

Ét opslag, flere iagttagelsespunkter

For ét internt navn er der mindst fem steder at se: applikationen og det resolver-API, den kalder, den gældende domænepolitik på klienten, en optagelse på adapter eller filter, en kontrolleret gateway-grænse og den resolver, der faktisk modtager forespørgslen.

Hvert af dem svarer på et forskelligt spørgsmål, og ingen af dem alene beviser, hvor forespørgslen gik hen.

En optagelse på adapteren viser pakker, ikke hensigt. Den fortæller ikke, hvilken resolver klienten valgte, og en tom optagelse kan betyde et cachet svar eller et andet resolver-API frem for en droppet pakke. Behandl hver iagttagelse som bevis for ét trin. Sæt derefter trinnene sammen til en vej.

Klientens filter sidder mellem app og ledning

En VPN-klient med Split-DNS anvender domænematchning, før pakken forlader maskinen. Navne i det tunnellerede suffiks går til den interne resolver; alt andet går til den lokale. Filteret er politik, og politik kan variere efter platform og klientversion.

Secure Clients vejledning om Split-DNS fra Cisco dækker domænematchning og Windows-filteret og adskiller det, en app ser, når den bruger det native resolver-API, fra det, et værktøj som nslookup ser. De forskelle er pointen.

Begynd med den gældende profil og ét almindeligt applikationsopslag. Enhver test, der angiver en bestemt server, er en bevidst omvej; brug klientens egen diagnostik til at forklare den, og lad den ikke blive acceptkriteriet.

nslookup tager en anden vej end appen

nslookup bygger sin egen DNS-forespørgsel og kan omgå styresystemets resolverpolitik. Det gør det til et nyttigt værktøj til at stille et bestemt spørgsmål til en bestemt server og et misvisende værktøj til at teste, hvad en applikation vil opleve.

På Windows afgør navneopløsningspolitiktabellen, hvilket suffiks der bruger hvilken server. At læse den viser den politik, applikationen vil følge, og det er ofte den manglende brik.

Læs politikken, og stil derefter det samme spørgsmål gennem den normale resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Krypterede resolvere skjuler forespørgslen, ikke forbindelsen

En browser med sin egen DNS-over-HTTPS-resolver er en helt anden sag. Forespørgslen forlader maskinen inde i TLS, så en pakkeoptagelse viser en forbindelse til en resolver-adresse, men ikke det navn, der spørges til.

Find først browserens administrerede politik, og sammenlign den derefter med et opslag fra styresystemet. En browser, der må vælge sin egen resolver, ser måske slet ikke Split-DNS-politikken.

Samme forsigtighed gælder for enhver klient, der leverer sin egen resolver. En optagelse, der identificerer fjernforbindelsen, er ikke bevis for forespørgselsnavnet. Har du brug for navnet, så hent det i resolverens egne logge eller i applikationens diagnostik, med de privatlivsregler, der gælder.

Sammenlign med en mærket test

Vælg et godkendt internt navn til test, plus et offentligt navn uden følsom betydning. For hvert af dem skal du notere tidspunktet, posttypen, svaret og den politik, du forventede.

Hvor det er tilladt, sammenlign resolverens modtagelse med én snæver iagttagelse fra klient eller gateway:

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

Send aldrig private navne til uvedkommende offentlige resolvere bare for at skabe en sammenligning, og rediger alt, du deler. Til sidst skal du skelne et korrekt DNS-svar fra den tjenesteforbindelse, der følger: den opløste private adresse har stadig brug for en rute og en applikationsgodkendelse.