VPN DNS-filter: namen blokkeren blokkeert geen advertenties

Eén dnsmasq-regel kan een naam met NXDOMAIN beantwoorden, en dat is het hele mechanisme. Hij leest nooit HTML, bekijkt nooit een aanvraagpad en ziet nooit wat een applicatie doet met een verbinding die al open is. Een vergelijking met een browserextensie is daarom een vergelijking van twee verschillende taken. Het ene bepaalt of een naam wordt opgelost; het andere bepaalt wat er daarna gebeurt.

Wat een naamfilter werkelijk beheert

De optie address=/metrics.example/, met niets achter de laatste slash, laat de resolver NXDOMAIN teruggeven voor die naam en de subdomeinen ervan. Het adres leeg laten is het belangrijkste deel: het voorkomt dat clients naar een ongerelateerde vervangende server worden gestuurd of dat een loopbackadres als echte bestemming wordt voorgedaan. De dnsmasq-handleiding beschrijft die vorm als een negatief antwoord en niet als een omleiding.

Alles wat de regel kan doen, volgt uit die ene beslissing. Een client die deze resolver vraagt, krijgt een negatief antwoord; een client die een andere resolver vraagt, krijgt wat die resolver zegt. Het filter weet niet welk pad, welke queryreeks of welk account de applicatie zou hebben gebruikt.

Die granulariteit is belangrijk omdat één hostnaam vaak meerdere doelen dient. Inlogeindpunten, afbeeldingen en tracking kunnen een domein delen, en een regel die de hele naam verwijdert, kan een werkstroom meenemen. Een beleid op naamniveau moet die afweging accepteren of smallere namen kiezen.

Waar een blocker aan de clientkant verschilt

Een browserextensie ziet het verzoek voordat het vertrekt, dus kan hij een URL-pad matchen, een bepaald verzoek annuleren en het element verbergen dat het resultaat zou hebben getoond. Hij kan example.com/article toestaan en example.com/ads/ weigeren, wat geen enkel DNS-antwoord kan uitdrukken. Dat beeld op padniveau is het vermogen dat een resolver eenvoudigweg niet heeft. Het is ook de reden waarom een filterlijst die voor het ene hulpmiddel is gebouwd, zich zelden hetzelfde gedraagt in het andere.

De prijs is reikwijdte. Die bescherming leeft in één browser, in één profiel, op één apparaat, en verdwijnt wanneer de gebruiker naar een andere applicatie overstapt. Een DNS-filter op de gateway dekt elk apparaat dat de resolver van de gateway gebruikt, ook apparaten waarop geen extensie kan worden geïnstalleerd.

Geen van beide opzetten is op zichzelf volledig. Een DNS-filter kan geen identificatie verwijderen die een pagina al heeft verzonden, en een browserextensie kan een applicatie die hem nooit laadt niet beschermen.

Het resolverpad bepaalt of dit alles geldt

Een VPN kan een DNS-server aankondigen en toch niet elke query ontvangen. Een browser met versleutelde DNS, een applicatie met een eigen resolver of een apparaat op een netwerkpad dat de gateway uitsluit, zoekt allemaal ergens anders. Mobiele platforms bieden steeds vaker een instelling voor privé-DNS die stil overschrijft wat de tunnel voorstelt.

Test dus het pad en niet het beleid. Bevraag de bedoelde resolver rechtstreeks vanaf de gateway, bevraag hem daarna vanaf een client en vergelijk, en kijk vervolgens of een naam die geblokkeerd zou moeten worden daadwerkelijk faalt in de applicatie die de gebruiker draait.

Gecachte antwoorden en open sockets maken dit rommelig. Een pagina die zijn bronnen al heeft geladen, blijft werken nadat de regel is gewijzigd, dus een verse verbinding is een betere test dan een oud tabblad herladen.

Test beide richtingen voordat je een resultaat claimt

Gebruik een bewust geblokkeerde documentatienaam, een toegestane openbare naam en een privénaam die de dienst nodig heeft:

$ 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

Een leeg antwoord voor de geblokkeerde naam, een normaal adres voor de openbare en een privéadres voor de interne laten samen zien dat filteren, upstream-resolutie en lokale records allemaal werken. Als alle drie falen, kijk je naar een upstream- of listenerprobleem en niet naar een filter.

Houd de bewering smal in alles wat je intern publiceert. Dit is domeinfiltering op een resolver, geen inhoudsinspectie, geen padfiltering en geen belofte dat niemand wordt gevolgd. Vermeld de beleidseigenaar, de uitzonderingsroute en de bewaartermijn van query's naast de regels, want een filter dat elke opzoeking logt, heeft zijn eigen privacykosten.