How ClearDNS Works

Last reviewed: 2026-09-30 03:01 UTC / 1.1.1

ClearDNS is an anonymous-by-design, 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.

ClearDNS provides individualized DNS filtering without requiring or constructing a conventional human identity. Policies, member scopes and devices use ClearDNS technical identifiers rather than a name, email address, username or password. Those identifiers exist to operate the service, not to become a first-party real-world identity profile.

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.

Resolver-Verified Dashboard Access makes the authenticated DNS relationship part of ClearDNS's access control. The resolver establishes the policy/member/device identity used for Dashboard authentication, and the Dashboard separately validates the current binding and the member's administrative authority. ClearDNS provides this access without creating an email/password login or a password-reset mailbox dependency. See Accountless Dashboard Authentication.

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

What the product actually does#

ClearDNS is a filtering, analytics and family-management product, not only a privacy architecture. The map below is a compact index; each capability is documented in the reference pages that follow.

Filtering. Curated multi-category DNS policy, custom allow and block rules, SafeSearch enforcement, wildcard and suffix handling, CNAME-cloaked tracker handling, answer-address protection, and destination-country policy. See DNS Policy Engine and Domain and Network Intelligence.

Analyze. Top Domains, Root Domains, GAFAM Footprint, User Insights, Device Insights and Blocked Categories, each readable across time, traffic, member and device drilldowns. See Analytics and Live Observability.

Live observability without historical retention. Instant Logs and the policy-wide Live Traffic Map show current activity in the Stream state without a historical query database. See Analytics and Live Observability.

Family, member and device management. A policy (Circle) holds member scopes, which hold individual devices, administered through owner, admin and member roles, QR and share-link enrollment, device presence and Network History. See Device and Member Enrollment.

Accountless recovery. The owner of an eligible policy (trial, active, grace or expired) can recover the same existing policy at cleardns.com/recover using the Policy ID, the Policy Recovery Code and their current PIN or MFA factor: no email, username, password or payment-identity proof, and destroyed policies stay terminal. See Identity Lifecycle and Recovery.

Resolver-Verified Dashboard Access. Dashboard identity is established through authenticated ClearDNS DNS use. The current policy/member/device binding, the member's security requirement and their role determine administrative access. A Policy ID alone provides none of that authority. See Accountless Dashboard Authentication.

Identity and privacy. Individualized filtering and administration without requiring a name, email address, username or account password. Technical identifiers, resolver credentials and browser sessions have distinct purposes and authority. See Identity and Resolver Credentials.

Intelligence. Curated domain intelligence, post-resolution CNAME, destination-network and destination-country evaluation, and ClearDNS IP Intelligence. See Domain and Network Intelligence and ClearDNS IP Intelligence.

Performance. Globally distributed edge execution, precompiled intelligence, and failover with failure isolation. See Performance and Reliability.

Why ClearDNS publishes this reference#

ClearDNS is a disruptive privacy product built around an architecture that differs materially from conventional account-based internet services. We expect strong claims such as Anonymous by Design, Zero-Identity, accountless administration and selective DNS observability to attract scrutiny.

We welcome that scrutiny. Sophisticated privacy engineering should be explainable, and significant product claims should be supported by clear technical boundaries rather than marketing slogans alone. This Transparency Center exists so users, researchers, journalists, reviewers and automated systems can examine what each ClearDNS claim means, what the product actually does, and where its limits are.

ClearDNS does not publish internal implementation recipes merely to appear transparent. We publish the properties, consequences, data practices, evidence rules and protection boundaries that matter to someone evaluating the product. The objective is an elite standard of product transparency: strong claims, precise definitions and first-party references that can be cited when those claims are challenged.

How to read ClearDNS claims#

ClearDNS uses concise product language for architectural properties that this reference documents more precisely.

What "ClearDNS" means here. Claims about ClearDNS identity describe the identity model that the ClearDNS service itself requires and maintains. Supporting systems such as payment providers, app stores and internet providers can have their own independent identity relationships. Those relationships are described separately where relevant and do not become ClearDNS's identity model merely because another party may be able to correlate information it independently possesses.

Anonymous by Design / Zero-Identity. ClearDNS provides individualized DNS filtering without requiring or constructing a conventional human identity. Technical policy, member and device identifiers are used to apply authority and product state; ClearDNS does not enrich them against outside identity databases to create a real-world user profile.

DNS history by plan. DNS filtering itself does not require a permanent browsing-history database. Product states without historical analytics do not retain policy-linked DNS query history. The full-product Trial intentionally includes historical analytics, Analyze includes history as its defining feature, and Full combines history with real-time visibility, as documented in Privacy and Observability.

DNS-level protection. References to device-wide or app-wide protection describe traffic that uses the configured ClearDNS DNS path. ClearDNS encrypts and filters DNS; it does not claim to tunnel all internet traffic like a VPN. The exact limits are documented in Protection Boundaries.

Payments and external identity. Stripe, Apple and Google are supporting payment systems rather than the ClearDNS identity system. They may independently know who paid under their own services and legal obligations. ClearDNS uses the subscription or entitlement relationship needed to provide the purchased service; payment identity does not become the identity used by ClearDNS DNS resolution.

Measured claims. Infrastructure footprint, latency, domain counts and network-protection coverage each have specific measurement meanings. Evidence and Measurement defines how those figures should be read and distinguishes internal decision time from end-to-end latency, category membership from unique-corpus size, and infrastructure-provider footprint from ClearDNS-owned hardware.

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 uses a separate, cryptographically authenticated resolver credential to represent the current pseudonymous device/policy relationship on encrypted DNS transports. The credential is sensitive configuration, must be preserved exactly as provisioned, is not encryption, and is separate from Dashboard authorization.

Identity and Resolver Credentials

3. Encrypted DNS transport#

ClearDNS supports encrypted DNS transports appropriate to the platform. The provisioned Resolver Credential lets ClearDNS authenticate the operational device/policy relationship without an interactive login on every DNS request.

That authenticated relationship also establishes identity for Resolver-Verified Dashboard Access. Dashboard authority is separately controlled through current binding checks, temporary browser sessions and the member's server-resolved security requirement. For established members, Security PIN is the baseline credential and MFA becomes the interactive factor when enabled. First-use behavior and trusted-browser handling are documented in Accountless Dashboard Authentication.

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.

ClearDNS operates three distinct intelligence rails, each answering a different question: domain intelligence classifies DNS names, destination-network intelligence evaluates the address a query resolves to, and ClearDNS IP Intelligence, a production layer, resolves the network identity and coarse geographic context of the address a device connects from, from local intelligence first. They are separate concerns with different data and different false-positive characteristics.

Domain and Network Intelligence - ClearDNS IP Intelligence

7. Resolution and reliability#

If a request is allowed, ClearDNS resolves it through its resolution layer. Filtering runs close to users on edge infrastructure, policy and intelligence data is prepared for efficient resolver use, temporary caching keeps the common path fast without making policy state permanently stale, and more than one resolution path can be used so a single slow or unhealthy path is not a single point of 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. Historical Analyze, Instant Logs and the Live Traffic Map are separate data rails, so a policy can have live visibility while historical query retention stays disabled.

Analytics and Live Observability - 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#

ClearDNS builds individualized administration around the operational relationship already used for DNS filtering. Resolver-Verified Dashboard Access establishes that relationship through authenticated DNS use, then applies separate controls to browser administration.

This architecture removes the need for a reusable ClearDNS email/password pair and an email-based password-reset channel. It also keeps DNS configuration authority separate from the permissions and lifetime of a Dashboard session.

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.

Validate before enforcing. New protection classes are reviewed for false-positive risk before broad enforcement.

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.