Zachycený Split-DNS: řekněte, kde bylo každé pozorování pořízeno

Dva lidé řeší stejný problém se Split-DNS a dostanou různé adresy resolveru. Jeden použil nástroj pro vyhledávání, druhý zachytával pakety na adaptéru a třetí si přečetl vlastní diagnostiku klienta. Ani jeden nelže a ani jeden nepopisuje stejnou fázi. Pojmenování místa pozorování promění rozpor v mapu.

Jeden dotaz, několik míst pozorování

Pro jedno interní jméno existuje nejméně pět míst, kam se podívat: aplikace a API resolveru, které volá, platná doménová politika na klientovi, zachytávání na adaptéru nebo filtru, řízená hranice brány a resolver, který dotaz skutečně přijme.

Každé z nich odpovídá na jinou otázku a žádné samo o sobě nedokazuje, kam dotaz odešel.

Zachytávání na adaptéru ukazuje pakety, ne úmysl. Neříká, který resolver klient zvolil, a prázdné zachytávání může znamenat odpověď z mezipaměti nebo jiné API resolveru, nikoli zahozený paket. Každé pozorování berte jako důkaz o jedné fázi. Potom fáze složte v cestu.

Filtr klienta stojí mezi aplikací a kabelem

VPN klient se Split-DNS uplatňuje porovnávání domén dřív, než paket opustí počítač. Jména v tunelované příponě jdou k internímu resolveru; všechno ostatní jde k místnímu. Filtr je politika a politika se může lišit podle platformy a verze klienta.

Pokyny Secure Client pro Split-DNS od Cisco pokrývají porovnávání domén a filtr Windows a oddělují to, co aplikace vidí, když používá nativní API resolveru, od toho, co vidí nástroj jako nslookup. Právě ty rozdíly jsou podstatné.

Začněte od platného profilu a jednoho běžného dotazu aplikace. Každý test, který jmenuje konkrétní server, je záměrnou oklikou; vysvětlete ho vlastní diagnostikou klienta a nedovolte, aby se stal kritériem přijetí.

nslookup jde jinou cestou než aplikace

nslookup sestavuje vlastní DNS dotaz a může obejít politiku resolveru operačního systému. To z něj dělá užitečný nástroj pro položení konkrétní otázky konkrétnímu serveru a zavádějící nástroj pro testování toho, co aplikace zažije.

Ve Windows rozhoduje tabulka politiky překladu jmen o tom, která přípona používá který server. Její přečtení ukáže politiku, kterou bude aplikace následovat, a to je často chybějící dílek.

Přečtěte politiku a potom položte stejnou otázku přes běžný resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Šifrované resolvery skrývají dotaz, ne spojení

Prohlížeč s vlastním resolverem DNS-over-HTTPS je úplně jiný případ. Dotaz odchází uvnitř TLS, takže zachytávání paketů ukáže spojení s adresou resolveru, ale ne jméno, na které se ptáme.

Nejprve zjistěte spravovanou politiku prohlížeče a potom ji porovnejte s dotazem operačního systému. Prohlížeč, kterému je dovoleno vybrat si vlastní resolver, nemusí politiku Split-DNS vůbec vidět.

Stejná opatrnost platí pro každého klienta, který dodává vlastní resolver. Zachytávání, které identifikuje vzdálené spojení, není důkazem o jménu dotazu. Pokud jméno potřebujete, vezměte ho z vlastních protokolů resolveru nebo z diagnostiky aplikace, s platnými pravidly soukromí.

Porovnejte s označeným testem

Vyberte schválené interní jméno pro testování a k tomu veřejné jméno, které nenese žádný citlivý význam. Pro každé zaznamenejte čas, typ záznamu, odpověď a politiku, kterou jste očekávali.

Kde je to dovoleno, porovnejte přijetí v resolveru s jediným úzkým pozorováním klienta nebo brány:

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

Nikdy neposílejte soukromá jména nesouvisejícím veřejným resolverům jen proto, abyste vytvořili srovnání, a redigujte vše, co sdílíte. Nakonec oddělte správnou DNS odpověď od navazujícího spojení se službou: přeložená soukromá adresa stále potřebuje trasu a oprávnění aplikace.