Split-DNS-i püüdmine: öelge, kus iga vaatlus tehti

Kaks inimest tegelevad sama Split-DNS-probleemiga ja saavad erinevad resolveri aadressid. Üks kasutas otsingutööriista, teine püüdis pakette adapteril ja kolmas luges kliendi enda diagnostikat. Ükski neist ei valeta ja ükski ei kirjelda sama etappi. Vaatluspunkti nimetamine muudab vastuolu kaardiks.

Üks päring, mitu vaatluspunkti

Ühe sisemise nime jaoks on vähemalt viis kohta, kuhu vaadata: rakendus ja resolver-API, mida see kutsub, kliendil kehtiv domeenipoliitika, püüdmine adapteril või filtril, kontrollitud lüüsi piir ja resolver, mis päringu tegelikult vastu võtab.

Igaüks neist vastab erinevale küsimusele ja ükski üksi ei tõesta, kuhu päring läks.

Adapteril püüdmine näitab pakette, mitte kavatsust. See ei ütle, millise resolveri klient valis, ja tühi püüdmine võib tähendada vahemällu salvestatud vastust või teist resolver-APIt, mitte visatud paketti. Käsitlege iga vaatlust tõendina ühe etapi kohta. Seejärel koostage etapid teekonnaks.

Kliendi filter asub rakenduse ja kaabli vahel

Split-DNS-iga VPN-klient rakendab domeeni sobitamist enne, kui pakett masinast lahkub. Tunneldatud sufiksi nimed lähevad sisemisele resolverile; kõik muu läheb kohalikule. Filter on poliitika ja poliitika võib platvormi ja kliendiversiooni järgi erineda.

Cisco Secure Clienti Split-DNS-i juhend katab domeeni sobitamise ja Windowsi filtri ning eristab seda, mida rakendus näeb natiivse resolver-API kasutamisel, sellest, mida näeb tööriist nagu nslookup. Just need erinevused ongi olulised.

Alustage kehtivast profiilist ja ühest tavalisest rakenduse päringust. Iga test, mis nimetab konkreetset serverit, on meelega kõrvalepõige; selgitage seda kliendi enda diagnostikaga ja ärge laske sellel saada vastuvõtukriteeriumiks.

nslookup läheb rakendusest erinevat teed

nslookup koostab oma DNS-päringu ja võib operatsioonisüsteemi resolveripoliitikast mööda minna. See teeb selle kasulikuks tööriistaks konkreetse küsimuse esitamiseks konkreetsele serverile ja eksitavaks tööriistaks selle testimiseks, mida rakendus kogeb.

Windowsis otsustab nimelahenduse poliitikatabel, milline sufiks millist serverit kasutab. Selle lugemine näitab poliitikat, mida rakendus järgib, ja sageli on see puuduv tükk.

Lugege poliitikat ja esitage siis sama küsimus tavalise resolveri kaudu:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Krüpteeritud resolverid varjavad päringut, mitte ühendust

Brauser, millel on oma DNS-over-HTTPS resolver, on hoopis teine juhtum. Päring väljub TLS-i sees, seega paketipüüdmine näitab ühendust resolveri aadressiga, kuid mitte küsitud nime.

Tehke esmalt kindlaks brauseri halduspoliitika ja võrrelge seda siis operatsioonisüsteemi päringuga. Brauser, millel on lubatud oma resolver valida, ei pruugi Split-DNS-i poliitikat üldse näha.

Sama ettevaatus kehtib iga kliendi kohta, mis toob kaasa oma resolveri. Püüdmine, mis tuvastab kaugühenduse, ei ole tõend päringu nime kohta. Kui vajate nime, hankige see resolveri enda logidest või rakenduse diagnostikast, järgides kohalduvaid privaatsusreegleid.

Võrrelge märgistatud testiga

Valige testimiseks kinnitatud sisemine nimi ja lisaks avalik nimi, mis ei kanna tundlikku tähendust. Kirjutage igaühe kohta üles aeg, kirje tüüp, vastus ja poliitika, mida ootasite.

Kus see on lubatud, võrrelge resolveri vastuvõttu ühe kitsa kliendi või lüüsi vaatlusega:

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

Ärge kunagi saatke privaatseid nimesid mitteseotud avalikele resolveritele ainult võrdluse loomiseks ja redigeerige kõike, mida jagate. Lõpuks eraldage õige DNS-vastus järgnevast teenuseühendusest: lahendatud privaatne aadress vajab endiselt marsruuti ja rakenduse luba.