Protection Boundaries
ClearDNS applies policy to DNS traffic that reaches the configured ClearDNS resolver path. That gives it broad coverage across applications that use the device's configured DNS resolver, but it does not turn DNS into complete packet inspection.
A complete definition of "protected" must distinguish DNS-layer enforcement from traffic that bypasses DNS.
What ClearDNS controls#
When an application asks the operating system to resolve a hostname through the configured ClearDNS path, ClearDNS can:
- authenticate the device/policy resolver credential;
- evaluate the hostname against the policy;
- enforce custom domain rules;
- enforce category policy;
- apply supported SafeSearch rewrites;
- inspect relevant CNAME relationships in the answer;
- evaluate applicable answer-address network policy;
- apply country policy to resolved destinations;
- return a normal answer or a DNS-level policy response.
That is the normal protected path.
Encrypted DNS protects the resolver exchange#
Supported ClearDNS configurations use encrypted DNS transports. This protects the DNS message from ordinary passive inspection between the client and the ClearDNS encrypted-DNS endpoint. Encrypted DNS protects the DNS exchange itself; transport metadata can still reveal the resolver service being contacted, and device and configuration security remain part of the possession boundary.
Encrypted DNS also does not encrypt the rest of the application's traffic. HTTPS, VPNs and other application protocols have their own security properties, and after resolution the connection to the resolved destination address remains ordinary network traffic that the network operator can observe.
Application-controlled DNS#
An application can embed its own DNS client or explicitly send DNS to a resolver other than the operating system's configured resolver. If that traffic never reaches ClearDNS, ClearDNS cannot make a policy decision on the missing DNS request.
Examples include an application with a hard-coded DNS-over-HTTPS endpoint, an embedded DNS resolver, or a custom networking stack. Whether an operating system or managed-device policy can prevent that bypass is a platform-administration question, not a property of DNS filtering alone.
Browser Secure DNS#
Modern browsers may have their own Secure DNS setting. Depending on platform and browser configuration, the browser may use the operating system DNS, upgrade the system resolver to encrypted transport, use a user-selected resolver, or use its own configured resolver.
If the browser uses a different resolver directly, its queries can bypass a system-level ClearDNS configuration. ClearDNS can also be configured directly in supported browser Secure DNS settings where appropriate.
VPNs#
A VPN can replace or intercept DNS. The result depends on the VPN: some honor a custom DNS resolver, some force their own resolver, some route the operating-system DNS configuration through the tunnel, and some applications combine VPN and private DNS controls differently.
ClearDNS should therefore not be described as able to force DNS through itself against every VPN implementation.
Direct IP connections#
If an application already knows an IP address and connects to it directly, there may be no DNS lookup to filter. DNS policy cannot block a request it never receives. Network firewalls and endpoint traffic controls solve a different problem.
Cached DNS#
Operating systems and applications cache DNS responses. A connection may reuse a previously resolved address without issuing a new DNS query at that moment. ClearDNS policy changes affect new resolution decisions; they cannot retroactively erase every DNS cache held by every application or operating system.
Encrypted relay and privacy systems#
Some operating systems and applications include privacy relay features that can change DNS behavior or route name resolution through a different service. If that design removes the DNS request from the ClearDNS path, ClearDNS cannot claim enforcement over it. Platform documentation should describe the actual interaction for the current OS version.
DoH and DoT platform contract#
ClearDNS uses the encrypted DNS transport that best matches the supported platform configuration.
Supported encrypted-DNS clients must preserve the provisioned resolver hostname exactly. Normalization or alteration of the authenticated representation is rejected. For DNS-over-TLS, ClearDNS claims support only for client classes verified to preserve that exact form; platforms that do not meet the contract should use the supported DNS-over-HTTPS configuration instead.
Hard-coded destination IPs#
A domain filter cannot infer a domain that was never resolved. If malware, an application or a device connects directly to a hard-coded IP address, domain classification is not part of that connection.
ClearDNS's answer-address protections evaluate destinations returned by DNS resolution; that is different from being a general IP firewall for arbitrary direct connections.
DNS filtering vs content filtering#
DNS sees names and DNS answers. It does not see the full encrypted contents of an HTTPS page. ClearDNS can therefore block a domain or service boundary, but it cannot reliably make URL-path or page-content decisions inside one HTTPS hostname without a different inspection architecture.
ClearDNS does not describe DNS policy as HTTPS content inspection.
A practical matrix#
| Behavior | Can ClearDNS evaluate it? | Notes |
|---|---|---|
| Normal app uses system DNS configured to ClearDNS | Yes | Primary protected path |
| Browser uses ClearDNS Secure DNS | Yes | Direct encrypted DNS path |
| App sends DNS to another embedded resolver | No, if it bypasses ClearDNS | Platform controls may separately restrict this |
| VPN forces its own DNS | Not through ClearDNS | Depends on VPN behavior |
| Direct connection to known IP with no DNS lookup | No domain decision | No DNS event exists |
| DNS answer contains relevant CNAME target | Yes, where inspection applies | Post-resolution name check |
| DNS answer resolves to protected network address | Yes, where applicable | Answer-address policy; address-family scope is defined on the policy-engine page |
| HTTPS path/content inside an allowed hostname | No content inspection | DNS does not decrypt page traffic |
Why publish limitations#
The phrase "DNS protection" should mean something testable. Publishing the boundary makes it possible for users and reviewers to choose the right layer for their threat model. ClearDNS is designed to do DNS policy well. It is not presented as a substitute for every firewall, VPN, endpoint-control or content-inspection technology.
Related technical references#
Ready to try ClearDNS?
Private DNS protection without a conventional account.