Jedna linija u dnsmasqu može odgovoriti na ime sa NXDOMAIN i to je cijeli mehanizam. Ono nikada ne čita HTML, nikada ne pregleda putanju zahtjeva i nikada ne vidi šta aplikacija radi s vezom koju je već otvorila. Poređenje s proširenjem preglednika zato je poređenje dva različita posla. Jedno odlučuje da li se ime razrješava; drugo odlučuje šta se dešava nakon toga.

Šta filter imena zapravo kontroliše

Opcija address=/metrics.example/, bez ičega nakon posljednje kose crte, čini da razrješivač vrati NXDOMAIN za to ime i njegove poddomene. Ostavljanje adrese praznom je važan dio: time se klijenti ne šalju na nepovezani zamjenski server i ne pretvara se loopback adresa u pravo odredište. dnsmasq priručnik opisuje taj oblik kao negativan odgovor, a ne kao preusmjeravanje.

Sve što pravilo može uraditi proizlazi iz te jedne odluke. Klijent koji pita ovaj razrješivač dobija negativan odgovor; klijent koji pita drugi razrješivač dobija ono što taj razrješivač kaže. Filter ne zna koju bi putanju, koji upitni niz ni koji račun aplikacija koristila.

Ta granularnost je važna jer jedno ime hosta često služi u nekoliko svrha. Priključne tačke za prijavu, slike i praćenje mogu dijeliti domenu, a pravilo koje ukloni cijelo ime može ukloniti i radni tok. Politika na razini imena mora prihvatiti taj kompromis ili odabrati uža imena.

Gdje se blokator na strani klijenta razlikuje

Proširenje preglednika vidi zahtjev prije nego što ode, pa može upariti putanju URL-a, otkazati određeni zahtjev i sakriti element koji bi prikazao rezultat. Može dopustiti example.com/article dok odbija example.com/ads/, što nijedan DNS odgovor ne može izraziti. Taj pogled na razini putanje je sposobnost koju razrješivač jednostavno nema. Zato se i lista filtera napravljena za jedan alat rijetko ponaša isto u drugom.

Cijena je opseg. Ta zaštita živi unutar jednog preglednika, u jednom profilu, na jednom uređaju i nestaje kada korisnik pređe na drugu aplikaciju. DNS filter postavljen na gatewayu pokriva svaki uređaj koji koristi gatewayev razrješivač, uključujući uređaje na koje se ne može instalirati nijedno proširenje.

Nijedno rješenje nije potpuno samo po sebi. DNS filter ne može ukloniti identifikator koji je stranica već poslala, a proširenje preglednika ne može zaštititi aplikaciju koja ga nikada ne učita.

Putanja razrješivača odlučuje da li se išta od toga primjenjuje

VPN može oglašavati DNS server, a ipak ne primati svaki upit. Preglednik s konfiguriranim šifriranim DNS-om, aplikacija s vlastitim razrješivačem ili uređaj na mrežnoj putanji koja isključuje gateway gledat će negdje drugdje. Mobilne platforme sve češće nude postavku privatnog DNS-a koja tiho nadjačava ono što tunel predlaže.

Zato testirajte putanju, a ne politiku. Upitajte namjeravani razrješivač direktno s gatewaya, zatim ga upitajte s klijenta i uporedite, pa pogledajte da li ime koje bi trebalo biti blokirano zaista pada u aplikaciji koju korisnik pokreće.

Keširani odgovori i otvorene veze čine ovo neurednim. Stranica koja je već učitala svoje resurse nastavit će raditi nakon promjene pravila, pa je svježa veza bolji test od ponovnog učitavanja starog taba.

Testirajte oba smjera prije nego što tvrdite rezultat

Koristite namjerno blokirano dokumentacijsko ime, dopušteno javno ime i privatno ime koje servisu treba:

$ 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

Prazan odgovor za blokirano ime, normalna adresa za javno i privatna adresa za interno zajedno pokazuju da filtriranje, razrješavanje na višem nivou i lokalni zapisi rade. Ako sva tri padnu, gledate problem s višim nivoom ili s listenerom, a ne s filterom.

Držite tvrdnju uskom u svemu što objavljujete interno. Ovo je filtriranje domena na razrješivaču, a ne pregled sadržaja, ne filtriranje putanja i ne obećanje da nikoga ne prate. Uz pravila navedite vlasnika politike, putanju izuzetka i period čuvanja upita, jer filter koji bilježi svako pretraživanje ima vlastitu cijenu za privatnost.

Povezani članci