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
-> current device/policy binding
-> 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 prepares its production domain intelligence for efficient resolver use, so category checks do not slow ordinary resolution. 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 maintained and refreshed in a way designed to keep protection current without letting a failed update degrade it;
• the protection can be turned off per policy.

Answer-address network protection evaluates resolved IPv4 and IPv6 answer addresses against ClearDNS-maintained malicious-network protection intelligence. Shared-infrastructure safeguards reduce the risk of broad blocking on major multi-tenant cloud and delivery infrastructure.

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 a ClearDNS block is a ClearDNS decision#

The final authority for a blocking decision is the ClearDNS policy engine, not any single input to it.

• Explicit user rules and curated categories are different authorities. A policy owner's allow and block rules are user intent; categories are ClearDNS-curated intelligence.
• Raw external lists are not mounted directly as unquestioned production policy. A classification becomes a category decision only after the curation pipeline documented in Domain and Network Intelligence.
• Category decisions are ClearDNS-owned, and false-positive correction belongs to the ClearDNS curation pipeline, not to an upstream source.
• An explicit allow rule lets a policy owner override ordinary curated category behavior for that policy, without changing anyone else's protection.

Because the resolver records the decision, the reason and the category on every event, the answer to "why was this blocked?" is the ClearDNS decision that acted, and it is visible in Activity and on the Guard block page. That accountability surface is documented in Analytics and Live Observability.

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
• Analytics and Live Observability
• Performance and Reliability
• Protection Boundaries