Ang isang linya ng dnsmasq ay makasasagot sa isang pangalan ng NXDOMAIN, at iyon ang buong mekanismo. Hindi nito binabasa ang HTML, hindi sinusuri ang landas ng kahilingan, at hindi nakikita ang ginagawa ng aplikasyon sa koneksyong nabuksan na. Kaya ang paghahambing nito sa isang extension ng browser ay paghahambing ng dalawang magkaibang gawain. Ang isa ay nagpapasya kung ang pangalan ay malulutas; ang isa ay nagpapasya kung ano ang mangyayari pagkatapos.

Ano ba talaga ang kinokontrol ng filter ng pangalan

Ang opsyong address=/metrics.example/, na walang anuman pagkatapos ng huling slash, ay nagpapatawag sa resolver na magbalik ng NXDOMAIN para sa pangalang iyon at sa mga subdomain nito. Ang pag-iiwan sa address na walang laman ang mahalagang bahagi: iniiwasan nitong ipadala ang mga kliyente sa isang walang kaugnayang kapalit na server o ipalagay na ang loopback address ang tunay na destinasyon. Inilalarawan ng manwal ng dnsmasq ang anyong iyon bilang negatibong sagot at hindi bilang pag-redirect.

Lahat ng kayang gawin ng tuntunin ay nagmumula sa isang desisyong iyon. Ang kliyenteng nagtatanong sa resolver na ito ay nakakakuha ng negatibong sagot; ang kliyenteng nagtatanong sa ibang resolver ay nakakakuha ng sinasabi niyon. Hindi alam ng filter kung aling landas, aling query string o aling account ang gagamitin sana ng aplikasyon.

Mahalaga ang detalyeng iyon dahil ang isang hostname ay madalas na naglilingkod sa ilang layunin. Ang mga entry point ng pag-sign in, mga larawan at pagsubaybay ay maaaring maghati sa isang domain, at ang tuntuning nag-aalis ng buong pangalan ay maaaring mag-alis din ng isang workflow. Ang patakaran sa antas ng pangalan ay kailangang tanggapin ang kompromisong iyon o pumili ng mas makitid na pangalan.

Saan naiiba ang blocker sa panig ng kliyente

Nakikita ng extension ng browser ang kahilingan bago ito umalis, kaya maaari nitong itugma ang isang landas ng URL, kanselahin ang isang partikular na kahilingan at itago ang elementong magpapakita sana ng resulta. Maaari nitong payagan ang example.com/article habang tinatanggihan ang example.com/ads/, na hindi maipapahayag ng anumang sagot ng DNS. Ang pananaw sa antas ng landas na iyon ang kakayahang wala ang resolver. Iyon din ang dahilan kung bakit ang listahan ng filter na ginawa para sa isang tool ay bihirang kumilos nang pareho sa isa pa.

Ang halaga ay saklaw. Ang proteksyong iyon ay nabubuhay sa loob ng isang browser, sa isang profile, sa isang aparato, at nawawala kapag lumipat ang gumagamit sa ibang aplikasyon. Ang filter ng DNS na naka-configure sa gateway ay sumasakop sa bawat aparatong gumagamit ng resolver ng gateway, kabilang ang mga aparatong hindi malalagyan ng anumang extension.

Walang alinman sa mga kaayusan ang kumpleto nang mag-isa. Hindi maaalis ng filter ng DNS ang isang identifier na naipadala na ng pahina, at hindi mapoprotektahan ng extension ng browser ang isang aplikasyong hindi kailanman naglo-load nito.

Ang landas ng resolver ang nagpapasya kung may nalalapat sa alinman dito

Maaaring mag-anunsyo ng DNS server ang isang VPN at gayon pa man ay hindi matanggap ang bawat query. Ang browser na may naka-configure na encrypted DNS, ang aplikasyong may sariling resolver, o ang aparato sa isang landas ng network na hindi kasama ang gateway ay titingin sa ibang lugar. Ang mga mobile platform ay lalong nag-aalok ng setting ng pribadong DNS na tahimik na nagpapawalang-bisa sa iminumungkahi ng tunnel.

Kaya subukan ang landas at hindi ang patakaran. Tanungin ang nilalayong resolver nang direkta mula sa gateway, pagkatapos tanungin ito mula sa isang kliyente at ihambing, at pagkatapos ay obserbahan kung ang isang pangalan na dapat harangin ay talagang nabigo sa aplikasyong pinapatakbo ng gumagamit.

Ang mga naka-cache na sagot at bukas na socket ay gumagawa nitong maingay. Ang pahinang na-load na ang mga mapagkukunan nito ay patuloy na gagana pagkatapos magbago ang tuntunin, kaya ang isang bagong koneksyon ay mas mahusay na pagsubok kaysa sa muling pag-load ng lumang tab.

Subukan ang parehong direksyon bago mag-claim ng resulta

Gumamit ng sadyang hinarang na pangalan ng dokumentasyon, isang pinapayagang pampublikong pangalan, at isang pribadong pangalan na kailangan ng serbisyo:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Ang walang laman na sagot para sa hinarang na pangalan, normal na address para sa pampubliko at pribadong address para sa panloob ay magkasamang nagpapakita na gumagana ang pag-filter, paglutas sa upstream at mga lokal na rekord. Kung mabibigo ang tatlo, tinitingnan mo ang isang problema sa upstream o sa listener at hindi isang filter.

Panatilihing makitid ang pahayag sa lahat ng ipinapahayag mo sa loob. Ito ay pag-filter ng domain sa isang resolver, hindi pagsusuri ng nilalaman, hindi pag-filter ng landas at hindi isang pangakong walang sinusubaybayan. Isama sa mga tuntunin ang may-ari ng patakaran, ang landas ng eksepsyon at ang panahon ng pagpapanatili ng query, dahil ang filter na nag-log ng bawat paghahanap ay may sariling gastos sa privacy.

Kaugnay na mga artikulo