Web and DNS filtering: stop the bad destination before it loads

A DNS filtering service works on a simple idea: before a device can connect to a site, something has to answer the question of where that site lives, and that answer can be checked first. Web content filtering applies the same logic one step later, to the request itself, matching the destination against category policy and refusing the ones you have decided are off limits. It is one control layer inside our managed cybersecurity and compliance stack, and it is the layer that removes the destination instead of cleaning up after someone reached it.

• Security categories — phishing and credential-harvesting pages, the destination a convincing email exists to get someone to open.
• Malware downloads, including the ones served by a compromised ad on an otherwise ordinary site, where nobody clicked anything that looked wrong.
• The servers malicious software calls back to, so a payload that does land has nowhere to report in.
• Acceptable-use categories — the content that is not dangerous but does not belong on a company device, set by group instead of person by person.

Where the filtering actually happens

Filtering gets enforced in one of two places. At the resolver, the device asks where a domain lives and the lookup itself is answered or refused, which covers everything on that network path without touching the device. On the endpoint, an agent evaluates the destination on the machine itself, using policy that follows the laptop to the coffee shop, the client site, and the spare bedroom.

Resolver-level filtering is elegant on a network you control. Endpoint enforcement is what holds up once your people stop working on that network, which for most of the companies we support is the normal case rather than the exception. It also survives the things that quietly defeat resolver policy: a browser shipping its own encrypted DNS setting, a phone hotspot, a VPN someone installed for their own reasons.

Why this layer earns its place

Filtering is not the layer that gets attention, and it is the one we would give up last. The reason is arithmetic. Most incidents start with a destination, so anything that removes destinations reduces how often every other layer has to do its job, and a blocked lookup is an event nobody has to triage.

It also covers ground that training cannot reach. Background processes, scripts, and software with no person sitting in front of it do not sit through a phishing awareness module. Policy applies to them exactly the way it applies to a browser tab.

What running it well takes

The technology is the easy part. The work is in the content filtering policy: what gets blocked by default, which groups need exceptions, and how fast someone can actually get an exception when a legitimate vendor tool lands on a category list. Filtering that nobody maintains ends one of two ways. Either it is wide open, because every complaint earned an exception, or it is quietly routed around, because getting one took three days.

So we run it as a managed policy instead of a checkbox. Categories are set per group, exception requests come to us rather than stalling on the person who hit the block, blocks are logged, and the policy gets revisited as your tooling changes.

How we deliver it today

The filtering layer itself runs on every uConnect plan. It is enforced at the endpoint through ThreatLocker Web Control on managed devices, the same agent that handles application allowlisting, and exception requests come to us with ThreatLocker's Cyber Heroes team behind them. Exception requests are actioned within fifteen minutes, around the clock, on every plan — the plan comparison chart carries the same commitment. There is no separate DNS filtering product alongside it; the policy lives on the agent.

Filtering sits alongside the other layers in the stack. Endpoint protection and EDR handles what happens if something does execute, managed detection and response puts a human on the alerts around the clock, and active vulnerability management closes the weaknesses that would make a miss expensive. Those last two land on Advanced and Compliance plans.

What a block looks like to the person who hits one, and how to get an exception approved, is written up for clients in our endpoint web filtering guide.