Split-DNS uztveršana: pasakiet, kur veikts katrs novērojums

Divi cilvēki risina vienu un to pašu Split-DNS problēmu un iegūst dažādas resolver adreses. Viens izmantoja meklēšanas rīku, otrs uztvēra paketes adapterī, bet trešais nolasīja paša klienta diagnostiku. Neviens no viņiem nemelo, un neviens neapraksta to pašu posmu. Novērojuma punkta nosaukšana pretrunu pārvērš kartē.

Viena meklēšana, vairāki novērojuma punkti

Vienam iekšējam nosaukumam ir vismaz piecas vietas, kur skatīties: lietotne un tās izsauktais resolver API, klientā spēkā esošā domēna politika, uztveršana adapterī vai filtrā, kontrolēta vārtejas robeža un resolver, kas faktiski saņem vaicājumu.

Katrs atbild uz citu jautājumu, un neviens viens pats nepierāda, kur vaicājums aizgāja.

Uztveršana adapterī rāda paketes, nevis nodomu. Tā nepasaka, kuru resolver klienta izvēlējās, un tukša uztveršana var nozīmēt kešatmiņā saglabātu atbildi vai citu resolver API, nevis atmestu paketi. Uzskatiet katru novērojumu par pierādījumu par vienu posmu. Pēc tam salieciet posmus ceļā.

Klienta filtrs atrodas starp lietotni un vadu

VPN klients ar Split-DNS piemēro domēnu saskaņošanu pirms pakete atstāj mašīnu. Nosaukumi tunelētajā sufiksā dodas uz iekšējo resolver; viss pārējais dodas uz vietējo. Filtrs ir politika, un politika var atšķirties atkarībā no platformas un klienta versijas.

Cisco Secure Client Split-DNS norādījumi aptver domēnu saskaņošanu un Windows filtru, un tie atdala to, ko lietotne redz, izmantojot vietējo resolver API, no tā, ko redz tāds rīks kā nslookup. Tieši šīs atšķirības ir būtība.

Sāciet ar spēkā esošo profilu un vienu parastu lietotnes meklēšanu. Jebkurš tests, kas nosauc konkrētu serveri, ir apzināts apkārtceļš; izskaidrojiet to ar paša klienta diagnostiku un neļaujiet tam kļūt par pieņemšanas kritēriju.

nslookup iet citu ceļu nekā lietotne

nslookup veido savu DNS vaicājumu un var apiet operētājsistēmas resolver politiku. Tas padara to par noderīgu rīku, lai uzdotu konkrētu jautājumu konkrētam serverim, un par maldinošu rīku, lai pārbaudītu, ko lietotne piedzīvos.

Windows nosaukumu izšķiršanas politikas tabula nosaka, kurš sufikss izmanto kuru serveri. Tās nolasīšana parāda politiku, kurai lietotne sekos, un bieži vien tas ir trūkstošais gabals.

Nolasiet politiku un pēc tam uzdodiet to pašu jautājumu caur parasto resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Šifrētie resolveri slēpj vaicājumu, nevis savienojumu

Pārlūks ar savu DNS-over-HTTPS resolver ir pavisam cits gadījums. Vaicājums iziet TLS iekšienē, tāpēc pakešu uztveršana rāda savienojumu ar resolver adresi, bet ne jautāto nosaukumu.

Vispirms noskaidrojiet pārlūka pārvaldīto politiku, pēc tam salīdziniet to ar operētājsistēmas meklēšanu. Pārlūks, kam atļauts izvēlēties savu resolver, Split-DNS politiku var nemaz neredzēt.

Tāda pati piesardzība attiecas uz jebkuru klientu, kas nodrošina savu resolver. Uztveršana, kas identificē attālo savienojumu, nav pierādījums par vaicājuma nosaukumu. Ja nosaukums ir vajadzīgs, ņemiet to no paša resolver žurnāliem vai no lietotnes diagnostikas, ievērojot piemērojamos privātuma noteikumus.

Salīdziniet ar marķētu testu

Izvēlieties apstiprinātu iekšējo nosaukumu testēšanai, kā arī publisku nosaukumu, kam nav jutīgas nozīmes. Katram pierakstiet laiku, ieraksta tipu, atbildi un paredzēto politiku.

Kur atļauts, salīdziniet resolver saņemšanu ar vienu šauru klienta vai vārtejas novērojumu:

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

Nekad nesūtiet privātus nosaukumus nesaistītiem publiskiem resolveriem tikai tāpēc, lai izveidotu salīdzinājumu, un rediģējiet visu, ko kopīgojat. Visbeidzot, atdaliet pareizu DNS atbildi no pēc tās sekojošā pakalpojuma savienojuma: atrisinātajai privātajai adresei joprojām vajag maršrutu un lietotnes atļauju.