How ClearDNS Works

Last reviewed: 2026-08-31 12:44 UTC / 1.0.8

ClearDNS is an accountless DNS filtering system. A device sends an encrypted DNS request to ClearDNS. The resolver identifies the request's operational policy/device binding, evaluates the query against that policy, and returns a normal answer, a policy rewrite or a blocking response.

Accountless does not mean anonymous or unlinkable. ClearDNS uses persistent pseudonymous policy, member and device identifiers, but does not require a conventional personal account identity such as an email address, username or password.

The product separates several things that are often collapsed into a single "account" concept: the filtering policy, the member scope, the device binding, the resolver credential, and the browser session used to administer the policy.

That separation is central to how ClearDNS can offer individualized policy without requiring an email address, username or password.

Transparency Center: Welcome

Explore the technical foundations of ClearDNS, including identity, resolver authentication, DNS policy enforcement, privacy, observability, recovery, security, and performance. This documentation is maintained alongside the product as the architecture evolves.

Try Now for Free

The major layers#

1. Accountless policy identity#

ClearDNS creates operational identifiers for a policy, a member scope and a device. These identifiers associate devices with policy state. They are not intended to represent a person's real-world identity, and internal identifiers are validated before they can become an authoritative resolver identity.

Identity and Resolver Credentials

2. Resolver Credential V1#

ClearDNS represents the Policy ID, Member ID and Device ID in a separate 33-letter transport format. The representation is reversible and is not encryption. Its exact mixed-case form is authenticated with HMAC-SHA256 before the decoded binding is trusted.

Identity and Resolver Credentials

3. Encrypted DNS transport#

ClearDNS supports encrypted DNS transports appropriate to the platform. The Resolver Credential is carried in the resolver configuration so ClearDNS can select the correct device and policy without an interactive login on every DNS request. The Resolver Credential and Dashboard session are separate security objects. Resolver possession can participate in establishing the device relationship used for accountless Dashboard authentication, but it does not itself constitute a Dashboard session. Dashboard administration is separately protected by the member's server-resolved security requirement, with Security PIN as the baseline credential and MFA taking over the interactive challenge when enabled.

4. Exact device-policy binding#

A syntactically valid credential is not enough by itself to establish arbitrary policy state. After the transport credential is authenticated and decoded, ClearDNS verifies the corresponding binding and policy authority. Device enrollment and recovery flows are designed around the same exact policy/member/device tuple.

Device and Member Enrollment

5. Policy evaluation#

For an accepted DNS request, ClearDNS evaluates the query through a deterministic policy engine: service-continuity rules for critical ClearDNS and recovery flows, SafeSearch enforcement, custom allow rules, custom block rules, category policy, controlled wildcard/suffix logic, and post-resolution protections that inspect CNAME relationships, the resolved network destination, and the destination country where the policy enables them.

DNS Policy Engine

6. ClearDNS intelligence#

ClearDNS does not treat a collection of raw domains as production intelligence. Inputs pass through normalization, category-specific processing, shared-infrastructure safeguards, ClearDNS-owned enrichment, cross-checking, false-positive controls and freshness checks. The resulting corpus is compiled for resolver use. Private source inventories and operational thresholds are outside this public specification.

Domain and Network Intelligence

7. Resolution and reliability#

If a request is allowed, ClearDNS resolves it through its resolution layer. The data path uses edge-local processing, compact runtime indexes, caching, request coalescing and adaptive resolution strategies to reduce unnecessary work and avoid making one fixed network path a single point of performance failure.

Performance and Reliability

8. Observability as a separate capability#

DNS filtering does not require a conventional account or a permanent personal browsing profile. ClearDNS still has several distinct observability classes for product features, live visibility, service intelligence, operations and security. The reference documents each class separately because the word "logs" is too broad to describe their different purposes and retention behavior, and query-history retention depends on the product state the user has chosen.

Privacy and Observability

9. Lifecycle, recovery and evidence#

Because there is no account to reset, the reference documents the continuity contract: what survives lost sessions, lost devices, lapsed invitations and app reinstalls, and what is not recoverable without possession or a store entitlement. A separate evidence page defines how ClearDNS's claims and numbers should be read and tested.

Identity Lifecycle and Recovery - Evidence and Measurement

A simplified request path#

device
  |
encrypted DNS
  |
Resolver Credential validation
  |
exact device/policy binding
  |
policy state
  |
DNS policy engine
  +- block / rewrite
  +- allow
       |
    resolution
       |
    post-resolution checks (when applicable)
       |
    DNS response

The real production system contains additional safety, caching, recovery and observability layers. The diagram is a functional model, not an infrastructure map.

Why the identity is separated#

A conventional account system starts with a human identity and then attaches devices to it. ClearDNS starts with the policy and device relationship required to perform DNS filtering. Administration can then be proven from a device already using the policy instead of requiring an email/password account.

This changes the trust model:

a DNS policy does not need a personal profile to exist;
devices can have distinct resolver identities under the same policy;
a resolver credential is not automatically a dashboard session;
browser administration can be separately short-lived and revocable;
enrollment can add devices or members without creating conventional accounts.

Accountless Dashboard Authentication

What this architecture does not claim#

ClearDNS is a DNS-layer system. It does not claim that DNS policy is equivalent to inspecting or controlling all network traffic. Applications can use networking techniques that bypass the operating system's configured DNS path. VPNs, embedded resolvers, direct-IP connections and other mechanisms can change what a DNS filtering service can observe or enforce. ClearDNS documents these boundaries explicitly.

Protection Boundaries

Design principles#

Separate identity from real-world identity. Operational IDs are sufficient to deliver policy without a personal account.

Authenticate before authority. Resolver transport validation occurs before the decoded identity is trusted as a policy binding.

Fail closed at security boundaries. Malformed or unauthenticated resolver identities do not fall back to legacy identity formats.

Keep device scope explicit. Policy, member and device are distinct scopes.

Make policy changes responsive. Resolver-side caching improves performance without turning policy changes into long-lived stale state.

Treat intelligence quality as a pipeline. Raw inputs are not the production classification corpus.

Observe before enforcing. New enforcement classes can be measured against real traffic before they affect users.

Document limitations. "Protected by DNS" is not presented as "all network traffic is impossible to bypass."

Ready to try ClearDNS?

Private DNS protection without a conventional account.