VPN-DNS-filter: name blokkeer blokkeer nie advertensies nie

Een dnsmasq-reël kan 'n naam met NXDOMAIN beantwoord, en dit is die hele meganisme. Dit lees nooit HTML nie, ondersoek nooit 'n versoekpad nie en sien nooit wat 'n toepassing met 'n verbinding doen wat hy reeds oopgemaak het nie. Om dit met 'n blaaieruitbreiding te vergelyk, is dus 'n vergelyking van twee verskillende take. Die een besluit of 'n naam oplos; die ander besluit wat gebeur nadat dit wel opgelos het.

Wat 'n naamfilter werklik beheer

Die opsie address=/metrics.example/, met niks ná die laaste skeislyn nie, laat die resolver NXDOMAIN vir daardie naam en sy subdomeine teruggee. Om die adres leeg te laat, is die belangrike deel: dit voorkom dat kliënte na 'n onverwante vervangingsbediener gestuur word of dat 'n loopback-adres as die werklike bestemming voorgedoen word. Die dnsmasq-handleiding beskryf dié vorm as 'n negatiewe antwoord eerder as 'n herleiding.

Alles wat die reël kan doen, volg uit daardie enkele besluit. 'n Kliënt wat hierdie resolver vra, kry 'n negatiewe antwoord; 'n kliënt wat 'n ander resolver vra, kry wat daardie resolver ook al sê. Die filter weet niks van watter pad, navraagstring of rekening die toepassing sou gebruik het nie.

Daardie korreligheid maak saak, want een gasheernaam dien dikwels verskeie doele. Aanmeldpunte, beelde en nasporing kan 'n domein deel, en 'n reël wat die hele naam verwyder, kan 'n werksproses saam daarmee verwyder. 'n Beleid op naamvlak moet daardie afweging aanvaar of smaller name kies.

Waar 'n kliëntkant-blokkeerder verskil

'n Blaaieruitbreiding sien die versoek voordat dit vertrek, so dit kan 'n URL-pad pas, 'n spesifieke versoek kanselleer en die element versteek wat die resultaat sou gewys het. Dit kan example.com/article toelaat terwyl dit example.com/ads/ weier, wat geen DNS-antwoord kan uitdruk nie. Daardie siening op padvlak is die vermoë wat 'n resolver eenvoudig nie het nie. Dit is ook waarom 'n filterlys wat vir een instrument gebou is, selde dieselfde in die ander een werk.

Die koste is omvang. Daardie beskerming woon binne een blaaier, in een profiel, op een toestel, en dit verdwyn wanneer die gebruiker na 'n ander toepassing oorskakel. 'n DNS-filter wat op die poort ingestel is, dek elke toestel wat die poort se resolver gebruik, insluitend toestelle waar geen uitbreiding geïnstalleer kan word nie.

Nie een van die twee reëlings is op sigself volledig nie. 'n DNS-filter kan nie 'n identifiseerder verwyder wat 'n bladsy reeds gestuur het nie, en 'n blaaieruitbreiding kan nie 'n toepassing beskerm wat dit nooit laai nie.

Die resolverpad bepaal of enige daarvan geld

'n VPN kan 'n DNS-bediener adverteer en steeds nie elke navraag ontvang nie. 'n Blaaier met geënkripteerde DNS wat opgestel is, 'n toepassing met sy eie resolver, of 'n toestel op 'n netwerkpad wat die poort uitsluit, sal almal elders kyk. Mobiele platforms bied toenemend 'n private-DNS-instelling wat die tonnel se voorstel stilweg ignoreer.

Toets dus die pad eerder as die beleid. Vra die beoogde resolver direk vanaf die poort, vra dit dan vanaf 'n kliënt en vergelyk, en kyk dan of 'n naam wat geblokkeer moet word, werklik in die toepassing wat die gebruiker hardloop, misluk.

Gekaste antwoorde en oop sokkette maak dit raserig. 'n Bladsy wat sy hulpbronne reeds gelaai het, sal aanhou werk nadat die reël verander het, so 'n vars verbinding is 'n beter toets as om 'n ou oortjie te herlaai.

Toets beide rigtings voordat jy 'n resultaat eis

Gebruik 'n doelbewus geblokkeerde dokumentasienaam, 'n toegelate openbare naam en 'n private naam wat die diens nodig het:

$ 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

'n Leë antwoord vir die geblokkeerde naam, 'n normale adres vir die openbare een en 'n private adres vir die interne een wys saam dat filtering, opstroomresolusie en plaaslike rekords almal werk. As al drie misluk, kyk jy na 'n opstroom- of luisteraarprobleem eerder as 'n filter.

Hou die bewering smal in alles wat jy intern publiseer. Dit is domeinfiltering op 'n resolver, nie inhoudinspeksie nie, nie padfiltering nie en nie 'n belofte dat niemand nagespoor word nie. Noem die beleideienaar, die uitsonderingsroete en die navraagbewaarperiode saam met die reëls, want 'n filter wat elke opsoek log, het sy eie privaatheidskoste.