Pagsubok sa pagtagas ng DNS: ang pangalan ng resolver ay hindi ruta

Tatlong kaayusan ang itinuturing na tamang DNS para sa user ng VPN: mga query sa resolver ng operator, mga query sa naka-encrypt na resolver na pinili mo, at split DNS na nagpapadala ng mga pangalan ng trabaho sa organisasyon. Ang pagsubok sa pagtagas ay nag-uulat ng isang resolver, at hindi masasabi ng nag-iisang label na iyon kung aling kaayusan talaga ang mayroon ka. Magpasya muna sa nilalayong patakaran, pagkatapos ay subukan laban dito. Kung hindi, inihahambing mo ang isang numero sa isang damdamin.

Magpasya kung ano ang gusto mo bago basahin ang resulta

Pangalanan ang patakaran sa isang pangungusap: lahat ng pangalan sa resolver ng VPN, lahat ng pangalan sa piniling naka-encrypt na resolver, o split DNS na may mga panloob na pangalan na papunta sa organisasyon. Ang bawat isa ay maipagtatanggol para sa ibang user, at ang bawat isa ay gumagawa ng ibang inaasahang sagot. Kung wala ang pangungusap na iyon, anumang resulta na kaiba sa screenshot sa isang post sa forum ay mukhang nakakaalarma. Isulat ang patakaran bago ang unang pagsubok.

Ang pagsubok na ginawa bago tukuyin ang patakaran ay walang sinusukat. Nagbibigay ito ng pangalan ng resolver na walang anumang reference point.

Hindi pinatutunayan ng pangalan ng resolver ang ruta o ang tatanggap

Dalawang tanong ang mahalaga: sino ang tumanggap ng query, at aling ruta ang nagdala nito. Ang resolver ng third party ay maaaring maabot sa pamamagitan ng tunel habang ang screen ng mga setting ay nagpapakita ng address ng provider. Ang label sa pahina ng pagsubok sa pagtagas ay naglalarawan ng pananaw ng tagamasid, hindi ang iyong routing table.

Maaaring gumamit ang browser ng sarili nitong naka-encrypt na DNS habang dumadaan ang trapiko ng site sa tunel, at ang mga sagot sa cache ay maaaring magpahintulot sa pahina na mag-load nang walang bagong paghahanap. Iyon ang dahilan kung bakit walang sinasabi ang resulta ng pampublikong IP tungkol sa DNS. Pinoprotektahan ng DoH at DoT ang query habang papunta sa resolver, at nakikita pa rin ng resolver na iyon ang mga pangalan.

resolvectl status
resolvectl query example.com
dig +short example.com

Ginagawang tama ng split DNS ang maraming resolver

Maaaring ipadala ng organisasyon ang mga panloob na pangalan sa sarili nitong DNS at lahat ng iba pa sa ibang lugar. Kaya ang pagsubok na naglilista ng maraming resolver ay maaaring naglalarawan ng nilalayong patakaran at hindi ng sira. Ihambing ang naobserbahang set sa mga dokumentadong tuntunin ng split DNS bago i-disable ang anuman. Ang pagpatay sa panloob na resolver upang maging mas malinis ang hitsura ng pahina ng pagsubok ay sumisira sa mga pribadong pangalan.

Ang split tunneling at split DNS ay magkaibang pagpipilian: ang isa ay nagruruta ng mga packet, ang isa ay nagruruta ng mga tanong. Ang pagbabago ng ruta ng tunel ay hindi naglilipat ng paghahanap ng pangalan, at ang pagbabago ng resolver ay hindi nag-aayos ng landas ng website. Ang IPv6 ay ikatlong tanong, dahil ang hindi sinasadyang koneksyon ng IPv6 ay hindi awtomatikong pagtagas ng DNS.

Gawing imbestigasyon ang resulta

Itala ang nilalayong patakaran at ang secure DNS setting ng browser bago subukan. Patakbuhin ang pagsubok habang aktibo ang tunel, itala ang bawat resolver na binabanggit nito, at ihambing ang set sa patakaran at hindi sa isang inaasahang address.

Ulitin pagkatapos ng muling pagkonekta kung doon lumilitaw ang sintomas, dahil ang patakarang inilapat sa oras ng pagkonekta ay maaaring mawala mamaya. Gamitin ang dokumentasyon ng client para sa mga panloob na pagbubukod ng DNS sa halip na hulaan ang mga setting.

Ayusin ang pagkakaibang natagpuan: pagpili ng browser, setting ng DNS ng VPN o tuntunin ng split DNS. Kung kailangang huminto ang mga query kapag nabigo ang tunel, ang kill switch ay hiwalay na setting, at ang configuration ng DNS lamang ay hindi iyon nagbibigay. Ang espesipikasyon ng RFC 8484 ay kapaki-pakinabang kapag kailangan mong ipaliwanag kung ano ang itinatago at hindi itinatago ng naka-encrypt na resolver.