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#

observations / permitted intelligence inputs
        v
normalization and validation
        v
domain canonicalization
        v
consolidation with category context
        v
false-positive review
        v
cross-signal corroboration
        v
shared-infrastructure safeguards
        v
freshness / staleness controls
        v
category assignment (multi-category)
        v
production validation and gating
        v
compiled resolver representation
        v
continuous re-evaluation and discovery

The stages are more important than the name of any individual source.

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 with the same public-suffix logic the production resolver uses, so the analysis and the runtime 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 by automated analysis, with a deliberate conservative default-keep bias where uncertainty remains.
• 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.

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. The checking process is engineered so that throttling, transient failures or unreachable services can never masquerade as a verdict: an incomplete check is retried, not recorded.

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;
• the network-protection dataset is rebuilt on a regular schedule with integrity checks, and a failed or suspicious rebuild never replaces the last known-good production dataset. Serving slightly stale protection data is a mild degradation; serving a truncated or unverified dataset would be a real one, so the refresh fails safe.

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

Observe before enforcing#

New enforcement classes can be observed against real production traffic before enforcement is enabled. In observation mode the system records what it would have blocked without blocking anything, which allows ClearDNS to measure real-world false-positive behavior before a new protection affects users. The answer-address network protection described on the policy-engine page was introduced this way.

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.

Runtime compilation#

The production resolver does not parse millions of source text lines for each query. ClearDNS compiles policy intelligence into compact runtime structures that are loaded close to query processing and searched efficiently. The compiled corpus is versioned, which also gives production a clean rollback path.

The internal binary formats, hash layouts, build keys and storage topology are implementation details, not required evidence that ClearDNS performs its own curation.

From signal to active behavior#

The full lifecycle of a piece of intelligence:

signal / observation
        v
validation and enrichment
        v
production candidate
        v
quality gate
        v
compiled production intelligence (versioned)
        v
resolver distribution and cache refresh
        v
active policy behavior

Timing varies by intelligence class. The compiled domain corpus is rebuilt and redistributed as curation batches complete rather than on a fixed promise. Network-protection data refreshes on a regular schedule with integrity checks. Resolver-side caches of intelligence and policy state have bounded lifetimes, so a newly distributed dataset becomes active behavior within those bounds rather than instantly everywhere. ClearDNS does not publish a fixed propagation SLA, because none exists. What it commits to is the last-known-good property: a failed or suspicious rebuild never replaces the dataset currently serving users.

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