Performance and Reliability

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

ClearDNS therefore separates relatively slow control-plane work from the resolver's fast data path.

Compact production intelligence#

The domain intelligence pipeline produces a compiled runtime representation. The resolver loads that representation close to query processing and performs category checks without parsing or scanning the source corpus on every DNS request.

This is an important distinction:

intelligence construction: rich, expensive, asynchronous
resolver lookup: compact, predictable, latency-sensitive

Category checks run directly against the compact in-memory compiled representation; a separate per-domain policy-decision cache is not required in the current implementation. The resolver queries a compact in-memory representation of the compiled intelligence corpus, so the multi-million-record source corpus is transformed before it reaches the hot path.

Layered policy state#

Policy and binding state have different consistency requirements from DNS answers. ClearDNS uses short-lived local and edge representations to avoid turning every request into a full authoritative database round trip, while retaining an authoritative backend for policy/device state. Cache lifetimes are bounded so a performance optimization does not become permanent stale authority.

Policy fingerprints#

A policy's effective filtering configuration is represented by a content fingerprint. That gives the resolver a useful cache boundary:

• requests under unchanged filtering state can reuse derived state;
• changing the filter configuration changes the fingerprint;
• cached state does not need to be keyed by a human account concept.

This also separates the content of filtering policy from unrelated billing or UI fields.

Positive and negative answer caching#

Allowed DNS answers are cached with lifetimes constrained by the DNS response and ClearDNS's own cache policy; the resolver does not invent a lifetime longer than is appropriate for the answer. Negative answers are cached briefly, honoring standard DNS semantics within bounded limits.

Single-flight / request coalescing#

Popular names can generate many identical cache misses at nearly the same time. Without coalescing, every one of those requests could trigger identical upstream work. ClearDNS joins concurrent equivalent work behind one in-flight resolution and shares the result with waiting requests, which reduces burst amplification:

100 equivalent misses at once
        v
one in-flight resolution
        v
shared result

Adaptive resolution#

ClearDNS is not designed around the assumption that one fixed external resolution path is always fastest and healthiest from every location. The resolver measures recent path behavior and adapts its preference over time, so routing decisions respond to real network conditions rather than a permanent static priority.

The exact providers, scoring parameters and sampling thresholds are outside this public specification.

Hedging and fallback#

When appropriate, ClearDNS starts an alternate resolution path if the preferred path does not return quickly enough. The goal is not to duplicate every query; it is to reduce tail latency and provide another path when the current preferred route is slow or unhealthy. A bounded overall deadline prevents resolution attempts from growing without limit.

Local learning#

Performance information is useful when it reflects the network location doing the work. A path that performs well from one region may not be the best path from another. ClearDNS keeps adaptive behavior close to the execution location rather than treating one global latency number as universal truth.

Failure isolation#

Several design choices limit the impact of a failure:

• a malformed resolver credential is rejected before expensive state work;
• observability delivery is designed to be failure-isolated from DNS resolution and is generally deferred from the returned response path;
• one slow resolution path has a fallback;
• cached policy and intelligence keep repeated work off the critical path;
• 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 refresh never replaces the last known-good dataset.

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.

Outside the public specification#

Provider names and rankings, exact hedge and deadline values, internal cache keys and memo sizes, storage bindings and bucket names, private service topology, and operational failover thresholds. These change as infrastructure evolves and are not required to understand the design.

Related technical references#

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