Dve osebi rešujeta isto težavo Split-DNS in dobita različne naslove razreševalnika. Ena je uporabila orodje za iskanje, druga je zajela pakete na vmesniku, tretja pa je prebrala diagnostiko odjemalca samega. Nobena ne laže in nobena ne opisuje iste stopnje. Poimenovanje točke opazovanja protislovje spremeni v zemljevid.

Eno iskanje, več točk opazovanja

Za eno notranje ime je vsaj pet mest za pogledati: aplikacija in API razreševalnika, ki ga kliče, veljavna domenska politika na odjemalcu, zajem na vmesniku ali filtru, nadzorovana meja prehoda in razreševalnik, ki poizvedbo dejansko prejme.

Vsako odgovori na drugo vprašanje in nobeno samo po sebi ne dokaže, kam je poizvedba odšla.

Zajem na vmesniku kaže pakete, ne namere. Ne pove, kateri razreševalnik je izbral odjemalec, prazen zajem pa lahko pomeni predpomnjen odgovor ali drug API razreševalnika, ne pa zavrženega paketa. Vsako opazovanje obravnavajte kot dokaz o eni stopnji. Nato stopnje sestavite v pot.

Filter odjemalca stoji med aplikacijo in kablom

Odjemalec VPN s Split-DNS uporabi ujemanje domen, preden paket zapusti napravo. Imena v tunelirani priponi gredo k notranjemu razreševalniku; vse ostalo gre k lokalnemu. Filter je politika in politika se lahko razlikuje glede na platformo in različico odjemalca.

Smernice Secure Client za Split-DNS podjetja Cisco pokrivajo ujemanje domen in filter Windows ter ločujejo, kaj vidi aplikacija pri uporabi izvornega API razreševalnika, od tega, kar vidi orodje, kot je nslookup. Prav te razlike so bistvo.

Začnite z veljavnim profilom in enim običajnim iskanjem aplikacije. Vsak test, ki imenuje določen strežnik, je nameren ovinek; pojasnite ga z lastno diagnostiko odjemalca in ne dovolite, da postane merilo sprejema.

nslookup gre drugačno pot kot aplikacija

nslookup sestavi lastno poizvedbo DNS in lahko obide politiko razreševalnika operacijskega sistema. Zato je koristno orodje za postavitev določenega vprašanja določenemu strežniku in zavajajoče orodje za preverjanje, kaj bo aplikacija doživela.

V sistemu Windows tabela politike razreševanja imen odloča, katera pripona uporablja kateri strežnik. Branje le-te pokaže politiko, ki ji bo sledila aplikacija, in to je pogosto manjkajoči del.

Preberite politiko in nato postavite isto vprašanje prek običajnega razreševalnika:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Šifrirani razreševalniki skrijejo poizvedbo, ne povezave

Brskalnik z lastnim razreševalnikom DNS-over-HTTPS je povsem drug primer. Poizvedba odide znotraj TLS, zato zajem paketov pokaže povezavo z naslovom razreševalnika, ne pa imena, po katerem sprašujemo.

Najprej ugotovite upravljano politiko brskalnika, nato jo primerjajte z iskanjem operacijskega sistema. Brskalnik, ki mu je dovoljeno izbrati lasten razreševalnik, morda politike Split-DNS sploh ne bo videl.

Enaka previdnost velja za vsakega odjemalca, ki prinese lasten razreševalnik. Zajem, ki prepozna oddaljeno povezavo, ni dokaz o imenu poizvedbe. Če ime potrebujete, ga vzemite iz dnevnikov razreševalnika samega ali iz diagnostike aplikacije, ob veljavnih pravilih zasebnosti.

Primerjajte z označenim testom

Izberite odobreno notranje ime za testiranje in javno ime, ki ne nosi občutljivega pomena. Za vsako zabeležite čas, vrsto zapisa, odgovor in pričakovano politiko.

Kjer je dovoljeno, primerjajte prejem v razreševalniku z enim ozkim opazovanjem odjemalca ali prehoda:

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

Nikoli ne pošiljajte zasebnih imen nepovezanim javnim razreševalnikom samo zato, da bi ustvarili primerjavo, in prečrtajte vse, kar delite. Na koncu ločite pravilen odgovor DNS od povezave s storitvijo, ki sledi: razrešen zasebni naslov še vedno potrebuje pot in dovoljenje aplikacije.

Sorodni članki