Performance and Reliability

DNS filtering sits on a latency-sensitive path. A design that performs expensive work on every query, or waits on one fixed upstream path, can make a technically correct filter unpleasant to use.

This page describes the performance and reliability properties ClearDNS commits to. The exact routing, caching and failover mechanics that deliver them are private implementation details.

Filtering close to the user#

ClearDNS runs filtering close to users on edge infrastructure, so policy evaluation does not require a long detour before a DNS answer can be produced. Policy and intelligence data is prepared in advance for efficient resolver use: the large intelligence corpus is prepared before it reaches query processing, so category checks do not slow ordinary resolution.

intelligence construction: rich, expensive, asynchronous
resolver evaluation: efficient, predictable, latency-sensitive

Why ClearDNS uses a global edge platform#

ClearDNS deliberately executes its resolver and policy logic on Cloudflare's globally distributed edge, rather than assuming that owning a smaller private DNS server fleet would automatically deliver better latency or reliability.

The reasoning is specific to DNS:

• DNS is latency-sensitive, and the largest, most consistent latency win comes from executing close to the user;
• a broadly distributed edge places policy evaluation near users in far more locations than a small proprietary fleet could economically reach;
• ClearDNS buys hyperscale network reach and mature global infrastructure instead of maintaining its own set of points of presence.

This is a real architectural trade, and it has a boundary. Those locations remain provider infrastructure, and the provider is part of the ClearDNS technical trust boundary. A provider's edge footprint is not the same thing as ClearDNS-owned physical servers, a distinction stated plainly on the Evidence and Measurement page.

Owning the rack is not itself a latency, privacy or reliability metric.

What should be measured is behavior, not hardware ownership: end-to-end latency and resolver processing time, p50/p95/p99 rather than a single average, failover behavior, policy responsiveness, and update failure isolation. Those are the properties the rest of this page commits to.

Bounded caching, prompt policy changes#

Temporary caching keeps the common path fast. Cache lifetimes are bounded so a performance optimization never becomes permanently stale policy authority: a policy edit is designed to take effect promptly rather than waiting behind long-lived cached decisions. DNS answers are cached within lifetimes appropriate to the answer, honoring standard DNS semantics.

Resilient resolution#

ClearDNS is not designed around the assumption that one fixed external resolution path is always fastest and healthiest from every location. More than one resolution path can be used, so a single slow or unhealthy path is not a single point of failure, and resolution work is bounded so attempts do not grow without limit. The exact path-selection behavior is private.

Failure isolation#

Several design choices limit the impact of a failure:

• a malformed resolver credential is rejected before expensive work;
• observability delivery is designed to be failure-isolated from DNS resolution;
• a slow resolution path has an alternative;
• live visualization is a separate capability rather than the resolver's authority;
• supporting data stores are separated from the critical policy directory;
• a failed intelligence update never degrades the intelligence currently serving users.

Measuring latency correctly#

"DNS latency" can mean several different things:

client network RTT
+ edge processing
+ policy decision
+ cache behavior
+ upstream resolution
= end-to-end observed lookup time

A small policy-decision time does not imply that every internet lookup completes in that same number of milliseconds. ClearDNS distinguishes internal resolver/filtering work from total client-observed resolution time when presenting technical performance claims, and does not publish benchmark numbers that are not backed by a current, reproducible measurement.

Useful performance dimensions#

A rigorous benchmark should separate warm-cache vs cold-cache, filtered vs unfiltered, cache-hit ratio, policy decision time, upstream time, total resolver time, client-to-edge RTT, p50/p95/p99, regional variance, and failure/fallback behavior. A single average does not describe tail latency, so serious evaluation should include percentile measurements.

Policy responsiveness#

Resolver performance also includes policy responsiveness: a DNS policy product needs changes to take effect promptly. ClearDNS uses bounded lifetimes for policy-related and block-response state so that changing a rule does not require waiting for long stale caches.

Why real-time features cost money#

ClearDNS could operate a simpler product more cheaply by doing less. Basic recursive DNS can be provided with far less per-user state and observability than ClearDNS's real-time product features require, and free public resolvers already cover that basic use case well.

The features that define the paid ClearDNS product are the expensive part:

• Instant Logs: streaming recent policy events to an authorized dashboard in real time;
• the Live Traffic Map: visualizing resolution activity as it happens;
• near-real-time device status: keeping per-device presence state fresh;
• historical analytics: retaining, indexing and serving policy-linked query analytics;
• queryable per-device visibility: answering "which device, what, when, why" on demand;
• global streaming and state processing: doing all of the above at the network edge, worldwide, continuously.

Each of these requires additional compute, storage, state management, streaming infrastructure and ongoing operational work beyond what basic recursive DNS needs. ClearDNS pricing reflects the infrastructure required by the features a plan includes: plans that include live visibility or historical analytics carry the cost of the rails that provide them.

Users who only need a basic resolver have free public DNS options available, and ClearDNS says so plainly. ClearDNS is a paid product because it provides substantially more than basic recursive DNS, and because a subscription is the business model that does not require monetizing user data to cover those costs.

Outside the public specification#

Routing and path-selection behavior, cache keys and lifetimes, internal data structures and formats, storage bindings, private service topology, and operational failover thresholds. These change as infrastructure evolves and are not required to understand the properties above.

Related technical references#

• DNS Policy Engine
• Domain and Network Intelligence
• Security Model