Pagkuha ng Split-DNS: sabihin kung saan kinuha ang bawat pagmamasid

Dalawang tao ang nag-iimbestiga sa parehong problemang Split-DNS at nakakakuha ng magkaibang address ng resolver. Isang gumamit ng kasangkapan sa paghahanap, isa ang kumuha ng packet sa adapter, at ang pangatlo ay nagbasa ng diagnostic ng kliyente mismo. Walang nagsisinungaling, at walang naglalarawan ng parehong yugto. Ang pagpangalan sa punto ng pagmamasid ay ginagawang mapa ang kontradiksyon.

Isang paghahanap, maraming punto ng pagmamasid

Para sa isang panloob na pangalan, may hindi bababa sa limang lugar na titingnan: ang aplikasyon at ang resolver API na tinatawag nito, ang epektibong patakaran ng domain sa kliyente, isang pagkuha sa adapter o filter, isang kontroladong hangganan ng gateway, at ang resolver na talagang tumatanggap ng query.

Ang bawat isa ay sumasagot sa magkaibang tanong, at walang isa na nag-iisa ang nagpapatunay kung saan napunta ang query.

Ang pagkuha sa adapter ay nagpapakita ng packet, hindi layunin. Hindi nito sinasabi kung aling resolver ang pinili ng kliyente, at ang walang laman na pagkuha ay maaaring nangangahulugan ng naka-cache na sagot o ibang resolver API sa halip na itinapong packet. Ituring ang bawat pagmamasid bilang ebidensya tungkol sa isang yugto. Pagkatapos ay pagsamahin ang mga yugto sa isang landas.

Ang filter ng kliyente ay nasa pagitan ng app at wire

Ang kliyenteng VPN na may Split-DNS ay naglalapat ng pagtutugma ng domain bago umalis ang packet sa makina. Ang mga pangalan sa tunneled suffix ay pumupunta sa panloob na resolver; lahat ng iba ay pumupunta sa lokal. Ang filter ay patakaran, at ang patakaran ay maaaring magkaiba ayon sa platform at bersyon ng kliyente.

Ang gabay sa Split-DNS ng Secure Client ng Cisco ay sumasaklaw sa pagtutugma ng domain at filter ng Windows, at inihihiwalay ang nakikita ng aplikasyon kapag gumagamit ito ng native na resolver API mula sa nakikita ng kasangkapan tulad ng nslookup. Ang mga pagkakaibang iyon ang mahalaga.

Magsimula sa epektibong profile at isang ordinaryong paghahanap ng aplikasyon. Anumang pagsubok na nagpapangalan ng tiyak na server ay sinadyang paglihis; ipaliwanag ito gamit ang diagnostic ng kliyente mismo, at huwag hayaang maging pamantayan ng pagtanggap.

Ang nslookup ay dumadaan sa ibang landas kaysa sa app

Ang nslookup ay bumubuo ng sarili nitong DNS query at maaaring laktawan ang patakaran ng resolver ng operating system. Ginagawa nitong kapaki-pakinabang na kasangkapan upang magtanong ng tiyak na tanong sa tiyak na server, at nakalilinlang na kasangkapan upang subukan ang mararanasan ng aplikasyon.

Sa Windows, ang talahanayan ng patakaran sa paglutas ng pangalan ang nagpapasya kung aling suffix ang gumagamit ng aling server. Ang pagbasa nito ay nagpapakita ng patakarang susundin ng aplikasyon, at madalas iyon ang nawawalang piraso.

Basahin ang patakaran at pagkatapos ay itanong ang parehong tanong sa normal na resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Itinatago ng mga naka-encrypt na resolver ang query, hindi ang koneksyon

Ang browser na may sariling resolver na DNS-over-HTTPS ay ganap na ibang kaso. Ang query ay lumalabas sa loob ng TLS, kaya ang pagkuha ng packet ay nagpapakita ng koneksyon sa isang address ng resolver ngunit hindi ang pangalang tinatanong.

Alamin muna ang pinamamahalaang patakaran ng browser, pagkatapos ay ihambing ito sa paghahanap ng operating system. Ang browser na pinapayagang pumili ng sariling resolver ay maaaring hindi makita ang patakaran ng Split-DNS.

Ang parehong pag-iingat ay naaangkop sa anumang kliyenteng nagdadala ng sariling resolver. Ang pagkuha na nakikilala ang malayuang koneksyon ay hindi ebidensya tungkol sa pangalan ng query. Kung kailangan mo ang pangalan, kunin ito mula sa mga log ng resolver mismo o sa diagnostic ng aplikasyon, kasama ang mga naaangkop na patakaran sa privacy.

Ihambing sa isang may label na pagsubok

Pumili ng aprubadong panloob na pangalan para sa pagsubok, kasama ang pampublikong pangalan na walang sensitibong kahulugan. Para sa bawat isa, itala ang oras, uri ng record, sagot at patakarang inaasahan mo.

Kung pinapayagan, ihambing ang pagtanggap ng resolver sa isang makitid na pagmamasid ng kliyente o gateway:

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

Huwag kailanman magpadala ng mga pribadong pangalan sa walang kaugnayang pampublikong resolver para lamang gumawa ng paghahambing, at i-redact ang lahat ng ibinabahagi mo. Sa huli, ihiwalay ang tamang sagot ng DNS mula sa koneksyon ng serbisyo na sumusunod: ang naresolba na pribadong address ay kailangan pa rin ng ruta at awtorisasyon ng aplikasyon.