Domain and Network Intelligence

ClearDNS does not equate "having many domain names" with having high-quality filtering intelligence.

Intelligence is curated, not imported. A domain appearing in an external, public or otherwise permitted intelligence source does not automatically become a ClearDNS production classification. Inputs are signals. Production policy intelligence is the output of a multi-stage quality process that ClearDNS runs itself.

Private source inventories, source-specific agreements, proprietary enrichment services, scoring rules and operational thresholds are outside this public specification.

The pipeline model#

Inputs pass through normalization and validation, category-aware consolidation, false-positive review, cross-signal corroboration, shared-infrastructure safeguards, freshness controls and production gating before anything reaches the resolver, and everything remains subject to continuous re-evaluation afterward.

The existence of these stages is more important than the name of any individual source, and their exact order and internal mechanics are not part of this public specification.

Normalization and validation#

Inputs arrive in different forms: full hostnames, base domains, wildcard-like rules, URLs, network observations, repeated observations, malformed values, conflicting labels. Before production use, ClearDNS converts relevant inputs into normalized forms appropriate to DNS policy. Malformed or non-domain material is not treated as a valid hostname simply because it appeared in an input dataset.

Category-aware consolidation#

Removing identical strings is the easiest part. A useful DNS intelligence pipeline also needs to understand relationships such as:

a.example.com
b.example.com
example.com

Collapsing every subdomain to the parent reduces data size, but it can make a policy too broad. ClearDNS makes consolidation decisions according to category semantics and infrastructure context: a category intended to cover an entire consumer service can legitimately operate at a broader domain boundary than a category intended to identify one tracking endpoint or one harmful hosted tenant.

Domain boundaries are computed consistently between analysis and the production resolver, so both agree about where a registrable domain starts.

False-positive control#

ClearDNS treats false-positive reduction as a first-class pipeline stage, built on a few principles:

• Popularity is a lens, never a verdict. Independent popularity and reference signals surface candidate false positives for review, but a popular domain can be a correct block and an obscure one a wrong block, so rank alone never decides.
• Automated per-domain analysis assists review. Candidates are individually evaluated against their claimed category, and where uncertainty remains, review errs on the side of not breaking legitimate sites.
• Deterministic rules remove clearly unsafe over-generalizations, such as classes of institutional domains that should not appear in content blocklists.
• Over-removal is detected and reversed. Cleanup passes are themselves verified; entries removed in error can be identified through independent checks and restored.
• Shared infrastructure receives special handling (below).
• Corrections are explicit. Known misclassifications are corrected rather than left to average out.

The important property: an upstream assertion is not automatically identical to a ClearDNS production assertion.

ClearDNS owns the production classification#

External inputs are evidence, not production authority. Once a classification reaches the ClearDNS production corpus, ClearDNS owns the resulting category decision and its false-positive responsibility.

ClearDNS does not mount a raw external list as unquestioned production policy. A production classification is the output of the pipeline on this page: normalization, category logic, consolidation, shared-infrastructure safeguards, cross-checking, corrections, freshness and production gating. "Which upstream list said this?" is a curation question. It is not necessarily the correct explanation of a ClearDNS production decision.

Why ClearDNS reports its reason, not someone else's blame#

The meaningful user-facing reason is the ClearDNS policy or category decision that acted. Upstream source attribution can matter internally during curation, but it is not an excuse to outsource responsibility for a production false positive.

Every resolved event carries the decision ClearDNS made, the reason for it, and the category that acted, and the ClearDNS Guard block page shows that same reason to the person who reached the blocked name. The accountable party for a ClearDNS block is ClearDNS.

Independent machine checks#

Some classifications can be corroborated through independent network-level checks that ask, in effect, whether the wider ecosystem agrees a name deserves its classification, and whether the name is even still alive.

Coverage varies by classification type, so those checks are treated as supporting evidence rather than universal authority, and the process is engineered so operational failures cannot masquerade as verdicts.

Shared infrastructure protection#

One of the largest false-positive risks in DNS filtering is a shared platform. A hostname on shared hosting, CDN, cloud, publishing or user-generated infrastructure can be harmful while the parent platform serves millions of unrelated legitimate sites.

ClearDNS's cleaning and enrichment stages preserve subdomain precision where promoting a classification to the parent would create collateral blocking. The rule is not:

one bad tenant means the entire shared platform is bad.

The same principle applies to network intelligence: address space belonging to large shared cloud platforms is explicitly excluded from the network-protection dataset, so a shared platform address is never blocked because one tenant behind it was listed.

Multi-category classification#

A domain relationship is not necessarily one-dimensional. The runtime policy representation preserves multiple relevant category signals for a hostname where the data supports them. A user's enabled policy categories determine whether those classifications produce a blocking decision.

Freshness and re-evaluation#

Internet infrastructure changes continuously. Domains expire, change owners, move hosting, become compromised, recover, or stop serving the content that caused a classification. Network ownership and reputation change too.

ClearDNS therefore treats intelligence as time-varying state rather than a one-time archive:

• dead domains are identified and pruned;
• classifications contradicted by newer evidence are re-filed or removed;
• protection datasets are maintained and refreshed in a way designed so that a failed or suspicious update cannot degrade the protection currently serving users.

Discovery from production observations#

De-identified production DNS observations can surface domains that may be missing from the current corpus. Those observations carry no ClearDNS policy, member or device identifiers and no client network address; what they contribute is the existence and outcome of a name in real traffic.

Discovered domains do not automatically become block rules. They enter the same validation and enrichment process as any other signal before any production classification.

The privacy properties of this rail are documented on the privacy page.

Privacy and Observability

Validate before enforcing#

New protection classes are validated for false-positive risk before broad enforcement. The internal rollout and validation process is not part of this public specification.

Domain intelligence and network intelligence are separate#

A domain classification answers a question about a DNS name. Network intelligence answers a question about the address returned by resolution. Those signals have different false-positive characteristics, so ClearDNS evaluates them at different stages:

query name
  v
domain policy
  v
resolution
  v
answer address
  v
network / country policy

This avoids pretending that domain metadata and destination-network reputation are interchangeable.

Country intelligence#

Country policy is based on the resolved destination-network view used by the resolver. It does not treat registration country, company headquarters, domain suffix and hosting destination as the same thing. This makes the behavior technically definable even for globally distributed services.

ClearDNS IP Intelligence#

Separately from the destination-address network and country policy on this page, ClearDNS operates a production IP Intelligence layer that resolves the network identity and coarse geographic context of the address a device connects from, from local intelligence first. That is a different concern from destination-address policy, which asks about the address a query resolves to. Its architecture, tiers, reliability model and privacy boundary have their own reference.

ClearDNS IP Intelligence

Address-family coverage#

ClearDNS network and address intelligence is dual-stack. The coverage each layer has:

Domain and category intelligence classify DNS names, so they are independent of the address family a name resolves to. ClearDNS IP Intelligence, Country Shield and Botnet Shield all evaluate both IPv4 and IPv6 addresses. No ClearDNS network or address-intelligence layer is limited to IPv4.

Runtime compilation#

Policy intelligence is prepared for efficient resolver use before it reaches query processing, so category checks do not slow ordinary resolution. The internal formats, build mechanics and storage topology are implementation details, not required evidence that ClearDNS performs its own curation.

From signal to active behavior#

A signal becomes active policy behavior only after validation, enrichment and a production quality gate. Timing varies by intelligence class: updated intelligence becomes active behavior promptly rather than instantly everywhere, and ClearDNS does not publish a fixed propagation SLA, because none exists. What it commits to is the reliability property: a failed or suspicious update never replaces the intelligence currently serving users.

Intelligence quality is continuously validated#

ClearDNS maintains an approximately 2.8 million-domain corpus across 13 categories. Inputs are signals rather than production authority. ClearDNS normalizes, consolidates, cross-checks, applies shared-infrastructure and false-positive safeguards, continuously re-evaluates the corpus, and owns the final production classification.

What the published numbers mean#

ClearDNS's compiled corpus stores unique domain entries, and one entry can carry several category classifications at once. Two consequences for any published counts:

• a per-category count is a membership count: how many entries carry that classification;
• category counts must not be summed to derive the total corpus, because entries overlap categories.

A corpus total is a count of unique compiled entries at a build snapshot and moves as entries are added, pruned and reclassified. Network-protection figures count the expanded IPv4 address coverage of curated ranges in the current snapshot, not a historical cumulative total. The conventions for reading all such figures are defined on the evidence page.

Evidence and Measurement

User rules and curated intelligence stay separate#

Custom allow and block rules are user policy; curated classification is ClearDNS intelligence. A user's allow rule exempts a name for that user's policy, and a user's block rule blocks it for that policy, but neither mutates the global classification corpus. The resolver applies the documented precedence: explicit user rules are evaluated before category intelligence, and enabled categories decide whether a classification acts at all.

That separation is what lets one user unblock a site for their own household without changing anyone else's protection, and it is also why false-positive reports are handled in the curation pipeline rather than by editing one user's policy.

Public specification boundary#

To preserve security, licensing obligations and proprietary know-how, this page does not publish:

• the source/feed inventory or source URLs;
• commercial counterparties;
• the identities of external services used for corroboration;
• private microservice names;
• feature-engineering details, source weights, confidence thresholds;
• model or provider names used in automated analysis;
• internal override or exception lists;
• production binary/index formats;
• infrastructure storage paths.

Machine-learning or AI-assisted tools may support parts of the review and enrichment process, but no single model output is production authority.

What can be independently evaluated#

• Does ClearDNS distinguish shared infrastructure from single-tenant domains?
• Are false positives corrected, and over-removals restored?
• Are stale classifications re-evaluated and dead domains pruned?
• Can a domain have multiple relevant category signals?
• Are explicit user rules independent of curated category intelligence?
• Is network policy separate from domain policy, with shared-platform exclusions?
• Does policy operate quickly enough for resolver use?
• Can ClearDNS explain to the user why a category decision occurred?

Those are product properties that can be tested without knowing the private source recipe.

Related technical references#

• DNS Policy Engine
• Performance and Reliability
• Privacy and Observability