Filtru DNS VPN: blocarea numelor nu blochează reclamele
O regulă dnsmasq răspunde numelor cu NXDOMAIN; nu citește niciodată pagina. Compară asta cu ce face un blocant din partea clientului înainte de a promite eliminarea reclamelor.
O singură linie dnsmasq poate răspunde unui nume cu NXDOMAIN, iar acesta este întregul mecanism. Nu citește niciodată HTML, nu inspectează niciodată o cale de cerere și nu vede niciodată ce face o aplicație cu o conexiune pe care a deschis-o deja. Comparația cu o extensie de browser este, așadar, o comparație între două sarcini diferite. Una decide dacă un nume se rezolvă; cealaltă decide ce se întâmplă după aceea.
Ce controlează de fapt un filtru de nume
Opțiunea address=/metrics.example/, fără nimic după ultima bară oblică, face resolverul să returneze NXDOMAIN pentru acel nume și subdomeniile lui. Lăsarea adresei goale este partea importantă: evită trimiterea clienților către un server de înlocuire nelegat sau prefacerea că o adresă loopback este destinația reală. Manualul dnsmasq documentează acea formă ca răspuns negativ, nu ca redirecționare.
Tot ce poate face regula decurge din acea singură decizie. Un client care întreabă acest resolver primește un răspuns negativ; un client care întreabă alt resolver primește ce spune acel resolver. Filtrul nu știe ce cale, ce șir de interogare sau ce cont ar fi folosit aplicația.
Acea granularitate contează pentru că un singur nume de gazdă servește adesea mai multe scopuri. Puncte de autentificare, imagini și urmărire pot împărți un domeniu, iar o regulă care elimină tot numele poate elimina și un flux de lucru. O politică la nivel de nume trebuie să accepte acest compromis sau să aleagă nume mai înguste.
Unde diferă un blocant din partea clientului
O extensie de browser vede cererea înainte ca ea să plece, deci poate potrivi o cale din URL, anula o cerere anume și ascunde elementul care ar fi afișat rezultatul. Poate permite example.com/article refuzând example.com/ads/, ceea ce niciun răspuns DNS nu poate exprima. Acea vedere la nivel de cale este capacitatea pe care un resolver pur și simplu nu o are. De aceea o listă de filtre construită pentru un instrument se comportă rar la fel în celălalt.
Costul este acoperirea. Acea protecție trăiește într-un singur browser, într-un singur profil, pe un singur dispozitiv și dispare când utilizatorul trece la altă aplicație. Un filtru DNS configurat pe gateway acoperă fiecare dispozitiv care folosește resolverul gateway-ului, inclusiv dispozitivele pe care nu poate fi instalată nicio extensie.
Niciuna dintre aranjamente nu este completă de una singură. Un filtru DNS nu poate elimina un identificator pe care pagina l-a trimis deja, iar o extensie de browser nu poate proteja o aplicație care nu o încarcă niciodată.
Calea resolverului decide dacă se aplică ceva din toate acestea
Un VPN poate anunța un server DNS și totuși să nu primească fiecare interogare. Un browser cu DNS criptat configurat, o aplicație cu propriul resolver sau un dispozitiv pe o cale de rețea care exclude gateway-ul vor căuta toate în altă parte. Platformele mobile oferă tot mai des o setare de DNS privat care suprascrie în tăcere ce propune tunelul.
Deci testează calea, nu politica. Interogează resolverul dorit direct de pe gateway, apoi interoghează-l de pe un client și compară, apoi observă dacă un nume care ar trebui blocat eșuează într-adevăr în aplicația pe care o rulează utilizatorul.
Răspunsurile din cache și socketurile deschise fac asta zgomotoasă. O pagină care și-a încărcat deja resursele va continua să funcționeze după schimbarea regulii, așa că o conexiune nouă este un test mai bun decât reîncărcarea unui tab vechi.
Testează ambele direcții înainte de a revendica un rezultat
Folosește un nume de documentație blocat intenționat, un nume public permis și un nume privat de care serviciul are nevoie:
$ 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
Un răspuns gol pentru numele blocat, o adresă normală pentru cel public și o adresă privată pentru cel intern arată împreună că filtrarea, rezolvarea upstream și înregistrările locale funcționează toate. Dacă toate trei eșuează, te uiți la o problemă upstream sau de listener, nu la un filtru.
Păstrează afirmația îngustă în tot ce publici intern. Aceasta este filtrare de domenii pe un resolver, nu inspecție de conținut, nu filtrare de căi și nu o promisiune că nimeni nu este urmărit. Menționează proprietarul politicii, calea de excepție și perioada de păstrare a interogărilor alături de reguli, pentru că un filtru care jurnalizează fiecare căutare are propriul cost de confidențialitate.