Insights
Secure DNS filtering: choose a policy and check that it works
Choose a DNS filtering policy, check resolver trust, test allowed and blocked domains, and recover from false positives safely.
On this page
Secure Domain Name System (DNS) filteringOpens in a new tab checks your domain lookups against rules and blocks names your policy doesn't allow. It can reduce access to known malicious or unwanted sites. Encrypted DNSOpens in a new tab protects the lookup in transit, but encryption alone doesn't filter domains.
In short:
- Choose your policy. Use threat blocking for general browsing or allowlist-only access for a small set of required services.
- Check resolver trust. Review your DNS provider's privacy terms separately from its encryption and filtering features.
- Test both outcomes. Check an allowed lookup and a confirmed policy block through your chosen resolver.
What happens when a domain is blocked
A DNS lookup normally asks a resolver for the Internet Protocol (IP) address associated with a domain. The resolver answers the lookup, and your device uses the address to connect. A filtering resolver checks the domain against its rules before allowing that process to continue.
When a rule blocks the domain, the resolver can refuse to return its address. The filtering service may instead redirect the request to a block pageOpens in a new tab. The visible result varies by service, so a failed page alone doesn't prove that DNS filtering caused it.
Filtering acts on the domain lookup, not everything that happens after a connection. You'll still need to check which resolver receives your queries and whether its policy matches your needs.
Choose what your network should block
A blocklist normally allows domains outside its rules. An allowlist reverses that choice and blocks domains you haven't explicitly approved. Filtering services can also compare domains with content categories and custom rules.
These approaches differ in what they permit and how much policy upkeep they need.
| Policy use | Allowed domains | Blocked domains | Maintenance tradeoff |
|---|---|---|---|
| Threat blocklist for general browsing | Domains outside the threat list | Domains on the threat list | Review unwanted blocks |
| Category rules for chosen restrictions | Domains outside selected categories | Domains in selected categories | Review category matches |
| Allowlist for fixed-service devices | Explicitly approved domains | All unapproved domains | Update required domains as services change |
For general browsing, start with threat blocking and add only content categories you intend to restrict. Consider allowlist-only access for a device with a small, known set of required services. Stricter rules need more care when those services change their required domains.
Keep your existing filtering service if it already meets your blocking, privacy and recovery needs. A change of provider isn't necessary just to adopt a clearer policy.
Check encryption and resolver trust separately
Filtering decides which domains your policy allows. DNS over Transport Layer Security (DoT) and DNS over HTTPS (DoH) encrypt DNS queries in transit. Neither encryption method, by itself, decides which domains to block.
DNS Security Extensions (DNSSEC)Opens in a new tab authenticate the origin of signed DNS data and check its integrity, but don't encrypt communications. That makes DNSSEC a different check from encrypted transport and domain filtering. Don't treat these features as interchangeable signs that a DNS service meets all your needs.
Check your selected resolver's privacy policy, query-log handling and supported encrypted endpoint, which is the address used to reach its encrypted DNS service. An encryption label doesn't answer what the resolver records or how it handles those records. Use the Secure DNS help pageOpens in a new tab for browser and operating-system setup.
Test allowed and blocked domains together
Plan checks only on a network you own or administer, and save the original policy for rollback. Record the device, resolver and assigned policy. Choose harmless domains, including an allowed control with a known expected address and a domain you control for any temporary custom block.
This matrix pairs each test domain and intended rule with the expected result, confirming evidence and next action.
| Domain rule | Expected outcome | Confirming evidence | Next action |
|---|---|---|---|
| Harmless known domain, allowed | Expected address returned | DNS result from selected resolver | Check resolver and policy assignment |
| Controlled domain, temporarily blocked | Provider's documented block response | Matching domain and rule event, where available | Check rule match and resolver path |
| Harmless provider category test, blocked where available | Documented category-block result | Category event or documented test response | Check category selection and test conditions |
| Controlled domain, temporary block removed | Expected address returned again | Restored lookup and original policy | Check remaining matching rules |
A normal address response shows that the tested domain resolved through the resolver you checked. A matching policy event or documented block response supports a policy-block diagnosis. A custom block confirms that rule, not the accuracy of threat classification. A browser error or a page failing to load isn't enough to confirm a DNS block.
A successful lookup doesn't prove every browser or app uses the same resolver. CloudConnexa's domain filteringOpens in a new tab applies only to queries resolved through its service, and third-party DoH can bypass that configuration. If your intended filter isn't receiving the queries, use DNS bypass troubleshootingOpens in a new tab instead of changing block rules.
Restore a needed site with a narrow exception
Change rules only on networks you own or administer, and save the original policy so you can restore it. A narrow exception should restore the needed service without removing unrelated restrictions.
1. Confirm the blocked domain.
Check the exact domain and its policy event where your provider documents those events. If neither an event nor a documented block response supports the diagnosis, investigate the connection failure before changing rules.
2. Check that the domain is legitimate.
Confirm that the domain belongs to the service you need. Don't allow a name solely because a page asks you to do so.
3. Check how matching rules are applied.
Read your provider's rule-precedence guidance, which explains which rule wins when several match. Don't assume an allow exception overrides every threat rule.
4. Add the narrowest supported exception.
Allow the specific required domain where your provider supports that control. CloudConnexa, for example, documents a Domain Allow List for specific domains that would otherwise be blocked. Don't expand the exception to a whole parent domain unless the service's requirements justify it.
5. Retest the service and a blocked control.
The needed service should work, and your harmless blocked control should still show the documented block result. Together, those results show that the exception restored access without removing that tested restriction. If either result differs, restore the original policy and check the rule match.
6. Record why the exception exists.
Document the domain, reason and expected result. Remove the exception when it's no longer needed, then check that the original policy applies again.
Know what a DNS filter can't prove
DNS filtering can block a classified malicious domain, but newly created malicious domains may remain unclassified. Cloudflare notes that attackers create new domains too quickly for blocklists to cover all of them. Passing your checks doesn't prove that every malicious destination will be blocked.
A domain rule also isn't page-content or individual Uniform Resource Locator (URL) filtering. Allowing a domain doesn't approve every page or file hosted there. Separate content controls answer a different question from whether a domain lookup is allowed.
Your test results cover the tested device, resolver path and policy. CloudConnexa's documented bypass condition illustrates why that path matters, but it doesn't define every filtering product's behavior. Neither DNS filtering nor encrypted DNS makes all browsing private or safe, and these checks don't prove complete malware, data-leak, prompt-injection or tracking protection.
Where doxx.net fits. doxx.net encrypts DNS lookups and blocks unwanted domains, but that doesn't mean it protects all browsing traffic. To use it, create an account, download the appOpens in a new tab and connect a device or agent to the private network.