Evidence and Measurement

Technical claims require clear definitions. This page explains how ClearDNS classifies the claims in this Technical Reference, what its published numbers mean, and which kinds of numbers this reference does not repeat.

Evidence classes used in this reference#

Protocol-defined#

A property specified by the current ClearDNS architecture or protocol. Example: the separation between resolver authority and Dashboard authority. These properties are true by construction and change only when the architecture changes.

Source-verified#

A behavior directly verified against production source during preparation of the current Transparency Center revision. Example: the policy precedence contract, or the data categories of each observability class.

Measured#

A quantitative observation with a defined methodology and a measurement date. A measured claim should always answer: what exactly was measured, over what population and period, with what denominator and aggregation (mean, median, p95, count), and with what exclusions.

Externally testable#

A behavior an independent user can observe with ordinary product or network tests, without trusting ClearDNS's own telemetry. Example: blocked categories returning the documented response types, or SafeSearch enforcement on supported search services.

ClearDNS does not describe this reference as independently audited, independently benchmarked or externally certified, because no such third-party engagement is being claimed here.

Dashboard separation is externally testable. Possession of valid resolver configuration is not sufficient, by itself, to use normal Dashboard functionality. A newly authenticated Dashboard session must also satisfy the member's current Dashboard security requirement.

The quantitative-claim rule#

This Technical Reference repeats a quantitative figure only when its measurement definition can be published alongside it. Where a public summary figure exists whose full methodology has not yet been published, this reference describes the mechanism qualitatively and leaves the figure to the surface that carries it, until a methodology document accompanies it.

Some public-facing figures may come from ClearDNS internal measurements before a full reproducible methodology is published. In that state, they should be read as ClearDNS-reported measurements, not as independently audited benchmarks. Their absence from this reference is not a retraction; it means this reference has not elevated the figure into its reproducibly documented evidence set yet.

That rule is why this page contains definitions rather than a table of numbers.

Product age is not a technical metric#

Market tenure, installed base and community size are useful historical context, but they do not by themselves prove the present behavior of a resolver, policy engine, analytics system, recovery mechanism or intelligence pipeline. A system's age is evidence about how long it has existed, not a measurement of how it behaves today.

ClearDNS states the other side plainly: a newer system has less long-term field history, and ClearDNS does not claim otherwise. What present technical maturity should be evaluated on is measurable behavior:

• tail latency, not only an average;
• failure isolation when a path or update goes wrong;
• update safety, so a bad intelligence update cannot replace good data;
• policy responsiveness after a change;
• recovery behavior under lost sessions and devices;
• behavior an independent party can test without trusting ClearDNS telemetry.

These are properties this Transparency Center documents and, where possible, makes externally testable.

How to read latency claims#

"DNS latency" hides several different quantities:

policy/filter decision time      (resolver-internal work to reach a decision)
resolver processing time         (total time inside ClearDNS's edge execution)
upstream DNS time                (time spent asking the upstream resolution path)
client-to-edge network RTT       (distance between the device and the nearest edge)
end-to-end observed DNS latency  (what the device experiences)

These are not interchangeable. A small policy-decision time is an internal quantity and does not mean every lookup completes in that time; end-to-end latency is dominated by network distance and cache state. Any ClearDNS latency figure should state which of these quantities it is, whether it is a mean or a percentile, whether cache hits are included, and when it was measured. Averages do not describe tail latency that can affect user experience, so percentile figures are preferred for serious evaluation.

How to read infrastructure claims#

ClearDNS executes on Cloudflare's global edge network. Statements about location or country counts describe the execution footprint of that network: the set of cities and countries where ClearDNS's resolver logic can run close to users. They do not mean dedicated ClearDNS-owned physical servers in each location, and the exact footprint changes over time as the underlying network evolves. The provider remains part of the ClearDNS technical trust boundary, and the reasoning for deliberately using a hyperscale edge rather than a small private fleet is on the Performance and Reliability page.

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

The right infrastructure questions are behavioral: resolver processing time, end-to-end latency at p50/p95/p99, failover behavior, policy responsiveness and update failure isolation, not a count of owned machines.

How to read domain-intelligence counts#

The intelligence corpus consists of unique domain entries, where one entry can carry multiple category classifications at once.

Consequences for reading any published counts:

• A per-category count is a membership count. It answers "how many entries carry this classification," not "how many entries exist only in this category."
• Category counts must not be summed to derive the total corpus, because one domain can belong to several categories.
• The corpus total is a count of unique compiled entries at a build snapshot, and it moves as the pipeline adds, prunes and reclassifies entries.
• Suffix/wildcard rules and runtime behaviors such as SafeSearch are separate mechanisms and are not part of the compiled entry count.

Counts published on marketing surfaces are floor figures ("at least") tied to a corpus snapshot; the corpus is rebuilt regularly, so a precise number is only meaningful together with its build date.

How to read network-protection counts#

The answer-address protection layer works on curated address ranges, not on a list of individually chosen addresses. A "blocked addresses" figure therefore describes the enforceable address coverage of the curated ranges in the current snapshot:

• the unit is address coverage of the curated ranges, not a hand-picked address list;
• it is a current-snapshot quantity, not a historical cumulative total, and it changes as ranges are added and, importantly, removed when address space is cleaned up and reassigned;
• the answer-address layer evaluates both IPv4 and IPv6 destinations;
• shared cloud-platform address space is excluded from coverage by design, so the figure reflects enforceable coverage rather than raw list size.

Measurement hygiene ClearDNS applies to itself#

• A quantitative figure is incomplete without its denominator and measurement context.
• Retries, duplicates and cache effects must be defined in or out of any traffic measurement.
• Population bias (which devices, plans, regions and periods are in the sample) must be stated for any behavioral statistic.
• Internal telemetry measurements and externally testable behavior are labeled differently.
• A quantitative claim whose methodology cannot yet be stated reproducibly is left out of this reference until that methodology is available.

ClearDNS uses its own internally developed first-party product analytics for product-usage measurement rather than outsourcing that measurement to a third-party analytics platform.

What an independent evaluator can test today#

Without any ClearDNS cooperation, an evaluator can verify externally testable properties such as: documented block-response behavior per category class, SafeSearch rewriting on supported services, prompt effect of policy changes on their own policy, and the protection boundaries described in this reference.

Protection Boundaries

Related technical references#

• Performance and Reliability
• Domain and Network Intelligence
• Analytics and Live Observability
• Privacy and Observability