Split-DNS-opptak: si hvor hver observasjon ble gjort

To personer feilsøker det samme Split-DNS-problemet og får ulike resolver-adresser. Én brukte et oppslagsverktøy, én tok opp pakker på adapteren, og en tredje leste klientens egen diagnostikk. Ingen av dem lyver, og ingen av dem beskriver det samme trinnet. Å navngi observasjonspunktet gjør en motsetning om til et kart.

Ett oppslag, flere observasjonspunkter

For ett internt navn er det minst fem steder å se: applikasjonen og resolver-API-et den kaller, den gjeldende domenepolitikken på klienten, et opptak på adapter eller filter, en kontrollert gateway-grense og resolveren som faktisk mottar spørringen.

Hver av dem svarer på et ulikt spørsmål, og ingen av dem alene beviser hvor spørringen gikk.

Et opptak på adapteren viser pakker, ikke hensikt. Det sier ikke hvilken resolver klienten valgte, og et tomt opptak kan bety et bufret svar eller et annet resolver-API i stedet for en droppet pakke. Behandle hver observasjon som bevis for ett trinn. Sett deretter trinnene sammen til en vei.

Klientens filter sitter mellom app og ledning

En VPN-klient med Split-DNS bruker domenematching før pakken forlater maskinen. Navn i det tunnelerte suffikset går til den interne resolveren; alt annet går til den lokale. Filteret er politikk, og politikken kan variere etter plattform og klientversjon.

Secure Clients veiledning for Split-DNS fra Cisco dekker domenematching og Windows-filteret, og den skiller det en app ser når den bruker det innebygde resolver-API-et, fra det et verktøy som nslookup ser. Det er nettopp disse forskjellene som er poenget.

Begynn med den gjeldende profilen og ett vanlig applikasjonsoppslag. Enhver test som navngir en bestemt server, er en bevisst omvei; forklar den med klientens egen diagnostikk, og ikke la den bli akseptkriteriet.

nslookup tar en annen vei enn appen

nslookup bygger sin egen DNS-spørring og kan omgå operativsystemets resolverpolitikk. Det gjør det til et nyttig verktøy for å stille et bestemt spørsmål til en bestemt server, og et misvisende verktøy for å teste hva en applikasjon vil oppleve.

På Windows avgjør navneoppløsningspolitikk-tabellen hvilket suffiks som bruker hvilken server. Å lese den viser politikken applikasjonen vil følge, og det er ofte den manglende brikken.

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

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Krypterte resolvere skjuler spørringen, ikke forbindelsen

En nettleser med sin egen DNS-over-HTTPS-resolver er en helt annen sak. Spørringen går ut inne i TLS, så et pakkeopptak viser en forbindelse til en resolver-adresse, men ikke navnet det spørres om.

Finn først nettleserens administrerte politikk, og sammenlign den så med et oppslag fra operativsystemet. En nettleser som får velge sin egen resolver, ser kanskje ikke Split-DNS-politikken i det hele tatt.

Samme forsiktighet gjelder for enhver klient som leverer sin egen resolver. Et opptak som identifiserer fjernforbindelsen, er ikke bevis for spørringsnavnet. Hvis du trenger navnet, hent det fra resolverens egne logger eller fra applikasjonens diagnostikk, med personvernreglene som gjelder.

Sammenlign med en merket test

Velg et godkjent internt navn for testing, samt et offentlig navn uten følsom betydning. For hvert av dem noterer du tidspunktet, posttypen, svaret og politikken du forventet.

Der det er tillatt, sammenlign resolverens mottak med én smal observasjon fra klient eller gateway:

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

Send aldri private navn til urelaterte offentlige resolvere bare for å lage en sammenligning, og rediger alt du deler. Til slutt skiller du et korrekt DNS-svar fra tjenesteforbindelsen som følger: den oppslåtte private adressen trenger fortsatt en rute og en applikasjonsgodkjenning.