Split-DNS snimanje: recite gdje je uzeto svako opažanje

Dvije osobe rješavaju isti Split-DNS problem i dobijaju različite adrese rezolvera. Jedna je koristila alat za pretragu, druga je snimala pakete na adapteru, a treća je pročitala klijentovu vlastitu dijagnostiku. Niko od njih ne laže i niko od njih ne opisuje istu fazu. Imenovanje točke opažanja pretvara proturječnost u kartu.

Jedan upit, nekoliko točaka opažanja

Za jedno interno ime postoji najmanje pet mjesta za pogledati: aplikacija i API rezolvera koji poziva, važeća politika domena na klijentu, snimanje na adapteru ili filteru, kontrolirana granica pristupnika i rezolver koji stvarno prima upit.

Svako od njih odgovara na drugo pitanje i nijedno samo po sebi ne dokazuje kuda je upit otišao.

Snimanje na adapteru pokazuje pakete, a ne namjeru. Ono ne kaže koji je rezolver klijent odabrao, a prazno snimanje može značiti keširani odgovor ili drugi API rezolvera, a ne odbačen paket. Svako opažanje tretirajte kao dokaz o jednoj fazi. Zatim sastavite faze u putanju.

Klijentov filter stoji između aplikacije i žice

VPN klijent sa Split-DNS primjenjuje podudaranje domena prije nego paket napusti mašinu. Imena u tuneliranom sufiksu idu na interni rezolver; sve ostalo ide na lokalni. Filter je politika, a politika se može razlikovati po platformi i verziji klijenta.

Ciscovo Secure Client Split-DNS uputstvo pokriva podudaranje domena i Windows filter, i razdvaja ono što aplikacija vidi kada koristi izvorni API rezolvera od onoga što vidi alat poput nslookup. Te razlike su poanta.

Pođite od važećeg profila i jednog običnog upita aplikacije. Svaki test koji imenuje izričit server namjerni je zaobilazak; upotrijebite klijentovu vlastitu dijagnostiku da ga objasnite i ne dopustite da postane kriterij prihvaćanja.

nslookup ide drugim putem od aplikacije

nslookup gradi vlastiti DNS upit i može zaobići politiku rezolvera operacijskog sustava. To ga čini korisnim alatom za postavljanje određenog pitanja određenom serveru i zavodljivim alatom za ispitivanje onoga što će aplikacija doživjeti.

U Windowsu tablica politike razrješavanja imena odlučuje koji sufiks koristi koji server. Njezino čitanje pokazuje politiku koju će aplikacija slijediti, a to je često dio koji nedostaje.

Pročitajte politiku pa zatim postavite isto pitanje kroz normalni rezolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Šifrirani rezolveri skrivaju upit, a ne vezu

Preglednik s vlastitim DNS-over-HTTPS rezolverom posve je drugi slučaj. Upit izlazi unutar TLS-a, pa snimanje paketa pokazuje vezu s adresom rezolvera, ali ne i ime koje se traži.

Prvo razradite upravljanu politiku preglednika, zatim je usporedite s pretragom operacijskog sustava. Pregledniku kojem je dopušteno birati vlastiti rezolver možda uopće neće vidjeti politiku Split-DNS.

Isto upozorenje vrijedi za svakog klijenta koji isporučuje vlastiti rezolver. Snimanje koje prepoznaje udaljenu vezu nije dokaz o imenu upita. Ako vam treba ime, uzmite ga iz rezolverovih vlastitih zapisa ili iz dijagnostike aplikacije, uz pravila privatnosti koja vrijede.

Usporedite s označenim testom

Odaberite odobreno interno ime za testiranje, plus javno ime koje ne nosi osjetljivo značenje. Za svako zabilježite vrijeme, vrstu zapisa, odgovor i politiku koju ste očekivali.

Gdje je dopušteno, usporedite rezolverov prijem s jednim uskim opažanjem klijenta ili pristupnika:

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

Nikada ne šaljite privatna imena nepovezanim javnim rezolverima samo da biste stvorili usporedbu i redigirajte sve što podijelite. Na kraju odvojite ispravan DNS odgovor od veze sa servisom koja slijedi: razriješena privatna adresa još treba rutu i odobrenje aplikacije.