Split-DNS-kaptaĵo: diru, kie ĉiu observo estis prenita

Du homoj pritraktas la saman Split-DNS-problemon kaj ricevas malsamajn adresojn de resolver. Unu uzis serĉilon, unu kaptis pakaĵojn sur la adaptilo, kaj tria legis la proprajn diagnozojn de la kliento. Neniu el ili mensogas, kaj neniu priskribas la saman etapon. Nomado de la observpunkto transformas kontraŭdiron en mapon.

Unu serĉo, pluraj observpunktoj

Por unu interna nomo ekzistas almenaŭ kvin lokoj rigardi: la aplikaĵo kaj la resolver-API, kiun ĝi vokas, la efektiva domajna politiko sur la kliento, kaptaĵo sur la adaptilo aŭ filtrilo, kontrolita porda limo, kaj la resolver, kiu efektive ricevas la demandon.

Ĉiu respondas al malsama demando, kaj neniu sole pruvas, kien iris la demando.

Kaptaĵo sur la adaptilo montras pakaĵojn, ne intencon. Ĝi ne diras, kiun resolver la kliento elektis, kaj malplena kaptaĵo povas signifi kaŝmemoran respondon aŭ alian resolver-API anstataŭ forĵetitan pakaĵon. Traktu ĉiun observon kiel pruvon pri unu etapo. Poste kunmetu la etapojn en vojon.

La filtrilo de la kliento staras inter aplikaĵo kaj drato

VPN-kliento kun Split-DNS aplikas domajnan kongruadon antaŭ ol la pakaĵo forlasas la maŝinon. Nomoj en la tunela sufikso iras al la interna resolver; ĉio alia iras al la loka. La filtrilo estas politiko, kaj politiko povas varii laŭ platformo kaj klienta versio.

La gvidilo de Secure Client pri Split-DNS de Cisco kovras domajnan kongruadon kaj la Windows-filtrilon, kaj apartigas tion, kion aplikaĵo vidas kiam ĝi uzas la denaskan resolver-API, de tio, kion vidas ilo kiel nslookup. Tiuj distingoj estas la punkto.

Komencu de la efektiva profilo kaj unu ordinara aplikaĵa serĉo. Ĉiu testo, kiu nomas eksplicitan servilon, estas intenca flankovojo; uzu la proprajn diagnozojn de la kliento por klarigi ĝin, kaj ne lasu ĝin fariĝi la akcepta kriterio.

nslookup sekvas alian vojon ol la aplikaĵo

nslookup konstruas sian propran DNS-demandon kaj povas preterpasi la resolver-politikon de la operaciumo. Tio igas ĝin utila ilo por demandi specifan servilon pri specifa demando, kaj misgvida ilo por testi tion, kion aplikaĵo spertos.

En Windows la tabelo de nomresolva politiko decidas, kiun sufikson uzas kiun servilon. Legi ĝin montras la politikon, kiun la aplikaĵo sekvos, kaj tio ofte estas la mankanta peco.

Legu la politikon kaj poste demandu la saman demandon per la normala resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Ĉifritaj resolveroj kaŝas la demandon, ne la konekton

Retumilo kun propra DNS-over-HTTPS-resolver estas tute alia kazo. La demando forlasas ene de TLS, do paka kaptaĵo montras konekton al resolver-adreso sed ne la demanditan nomon.

Unue eltrovu la administritan politikon de la retumilo, poste komparu ĝin kun operaciuma serĉo. Retumilo rajtigita elekti sian propran resolveron eble tute ne vidos la Split-DNS-politikon.

La sama singardo validas por ĉiu kliento, kiu venigas sian propran resolveron. Kaptaĵo, kiu identigas la malproksiman konekton, ne estas pruvo pri la demanda nomo. Se vi bezonas la nomon, prenu ĝin el la propraj protokoloj de la resolver aŭ el la diagnozoj de la aplikaĵo, kun la validaj privatecaj reguloj.

Komparu kun etikedita testo

Elektu aprobitan internan nomon por testado, plus publikan nomon, kiu portas neniun senteman signifon. Por ĉiu, registru la tempon, la rikordan tipon, la respondon kaj la politikon, kiun vi atendis.

Kie permesite, komparu la ricevon de la resolver kun unu mallarĝa observo de la kliento aŭ pordo:

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

Neniam sendu privatajn nomojn al nerilataj publikaj resolveroj nur por krei komparon, kaj redaktu ĉion, kion vi kunhavigas. Fine, apartigu korektan DNS-respondon de la serva konekto, kiu sekvas: la solvita privata adreso ankoraŭ bezonas itineron kaj aplikaĵan rajtigon.