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 Resolver Credential V1 format, or the order in which a credential is validated. 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 evaluation order, or the field content 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 a case-normalized resolver credential being rejected.
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.
That rule is why this page contains definitions rather than a table of numbers.
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 a global edge network operated by its infrastructure provider. 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.
How to read domain-intelligence counts#
The intelligence corpus is compiled into a runtime representation 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 expanded IPv4 address coverage of the curated ranges in the current snapshot:
- the unit is individual IPv4 addresses covered by the ranges;
- 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;
- it describes IPv4 coverage only: the current answer-address layer evaluates IPv4 destinations, and IPv6 destinations are not presently evaluated by that specific layer;
- 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 ClearDash, its internally developed first-party analytics system, 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, rejection of malformed or case-normalized resolver credentials, the DNS-assisted dashboard authentication flow, and the protection boundaries described in this reference.
Related technical references#
Ready to try ClearDNS?
Private DNS protection without a conventional account.