DNS Policy Engine

ClearDNS applies policy after the resolver has authenticated the presented Resolver Credential and established the corresponding device/policy relationship.

The policy engine is not just a lookup of "domain exists in one blocklist." It combines explicit user intent, category intelligence, DNS-specific behavior and post-resolution protections in a deterministic resolver path.

Before policy evaluation#

A request must first pass the identity and authority boundary:

encrypted DNS request
-> Resolver Credential authentication
-> identity decode and validation
-> exact binding lookup
-> policy state
-> policy evaluation

A malformed transport credential is not converted into an anonymous unfiltered query.

Evaluation order#

The conceptual production order is:

service continuity / protected infrastructure rules
-> SafeSearch processing
-> explicit allow rules
-> explicit block rules
-> category intelligence
-> controlled wildcard/suffix policy
-> resolution
-> applicable post-resolution CNAME / answer-IP / country checks

The exact internal execution graph is optimized and may short-circuit stages that are irrelevant to a query, but the precedence above is the contract users can reason about.

Service continuity#

Some resolver states need a narrow continuity path so a user can reach ClearDNS itself or complete essential recovery, billing and platform operations. These rules are narrow system controls, not a general bypass for normal policy evaluation. The exact hostname inventory is outside this public specification.

SafeSearch#

Where a supported search service exposes a DNS mechanism for enforcing a safer endpoint, ClearDNS rewrites the DNS answer toward that provider's safe-search target. SafeSearch alters resolution rather than returning a block.

SafeSearch runs before user and category blocking, and rewrite destinations are preserved through the later checks. That preservation is a correctness rule: the enforced safe endpoint must remain resolvable, and a rewrite target must not be re-blocked into a loop by a category rule.

Explicit policy rules#

Allow rules#

An allow rule is an explicit instruction that a matching name should not be blocked by ordinary user or category policy. Matching applies to the relevant hostname hierarchy so a policy does not require every subdomain to be entered independently.

Block rules#

A block rule is an explicit instruction to block the matching name. The resolver normalizes DNS names before rule evaluation so superficial case or trailing-dot differences do not create separate policy identities.

Category policy#

ClearDNS compiles its production domain intelligence into a runtime representation that returns category membership without iterating through millions of text records per query. A domain can carry more than one relevant classification signal; the enabled policy categories determine whether a classification produces a blocking decision.

Exact vs inherited domain treatment#

Not every category treats a subdomain and its parent domain identically. A shared hosting or analytics infrastructure domain can host many unrelated tenants; over-broadly promoting a subdomain classification to the entire parent would create large false positives.

ClearDNS therefore uses category-specific rules for when parent/suffix relationships may be used and when exact/subdomain precision must be preserved. This behavior is part of the intelligence-quality pipeline as well as the runtime policy engine.

Wildcard and suffix intelligence#

Some advertising and tracking infrastructure is better represented by controlled suffix patterns than by a flat set of exact hostnames. ClearDNS applies a secondary suffix/wildcard layer where appropriate. That layer is separate from unrestricted "block every parent domain" behavior.

Post-resolution protections#

Three protections operate on the upstream answer rather than the query name. They exist because some information only becomes visible after resolution.

CNAME-cloaked tracking#

A common tracking technique uses a first-party-looking hostname that resolves through a CNAME to tracking infrastructure. Looking only at the original query name misses that relationship.

ClearDNS inspects the CNAME chain in the upstream answer and re-evaluates the revealed target names against tracker-class policy before returning the final response. The inspection is scoped to dedicated tracker classes: those classifications identify tracking infrastructure with subdomain precision, so re-evaluating a revealed name there is safe. Content classes are excluded from CNAME re-evaluation because shared content-delivery infrastructure would make that inference unreliable.

A CNAME-based block uses an NXDOMAIN-style response, because the affected names are embedded page resources rather than pages a person navigated to.

Answer-IP network protection#

Domain classification and destination-network reputation solve different problems. Some threats rotate through thousands of throwaway domains while reusing a small set of network destinations.

ClearDNS evaluates the resolved answer address against a curated network-protection dataset after DNS resolution. A domain that is individually unknown can still be blocked when its resolved destination matches the protection policy.

This layer is conservative by design, because network blocking can have a wider effect on unrelated services than domain blocking:

• the dataset is curated, and address space belonging to large shared cloud platforms is explicitly excluded so one bad tenant cannot block a shared platform address;
• the dataset is refreshed regularly with integrity checks, and a failed refresh never replaces the last known-good dataset;
• the protection was observed against real production traffic before enforcement was enabled;
• the protection can be turned off per policy.

Current answer-address network intelligence is IPv4-scoped. Domain, category and CNAME protections operate independently of that address-family limitation.

Country policy#

A country policy is applied to the resolved network destination, not to a claim about a domain's nationality:

domain query
-> DNS resolution
-> answer address
-> destination network / country mapping
-> policy country decision

This distinction matters for CDNs, distributed services and sites whose registration, ownership and hosting geography are different concepts. Service-continuity names, explicit allow rules and SafeSearch targets are exempt from the country check so that the policy cannot cut off ClearDNS's own recovery paths or a rewrite target.

Blocking responses#

Different policy classes use different DNS blocking behavior.

NXDOMAIN-style blocking#

The resolver responds as though the blocked name does not resolve. This is used for embedded resources such as trackers, where redirecting to a human-readable page is undesirable.

Sinkhole / Guard response#

For human-facing content policy, the resolver returns a controlled destination that explains that ClearDNS blocked the request. This is used when the person needs to understand why a page did not open.

The response mode is selected according to policy/category behavior rather than applying one response type to everything.

Fast policy changes#

Blocking responses and policy-related caches are designed with bounded lifetimes. A policy edit should not require a user to wait for an arbitrarily long old filtering decision to disappear. ClearDNS balances caching with the expectation that user policy changes become effective quickly.

Why this is more than a list lookup#

• identity is validated before policy;
• user intent is distinct from curated categories;
• SafeSearch rewrites rather than blocks, and its targets are protected from self-defeating loops;
• categories can preserve subdomain precision;
• CNAME chains are inspected after resolution for tracker classes;
• network policy operates on the resolved answer, with shared-platform exclusions;
• country policy uses the resolved destination;
• response behavior differs by policy class.

Related technical references#

• Domain and Network Intelligence
• Performance and Reliability
• Protection Boundaries