ClearDNS IP Intelligence

Some ClearDNS capabilities need to understand more about a network address than whether it is well-formed. They need to know which network operates it, which country it is geographically associated with, and, where the evidence supports it, an approximate region or city. Validity alone does not answer those questions.

Why ClearDNS built IP Intelligence#

The easy way to obtain that information is to send each address to an external IP-enrichment service and read back what it returns. That approach is convenient and it works. It also carries a cost that is easy to overlook: every such request creates another party that receives an IP address at a particular time.

ClearDNS already necessarily processes the connecting IP address to operate as a network service; that necessity is documented in Privacy and Observability. So the useful question is not whether ClearDNS can avoid seeing the address, because it cannot, and no resolver can. The useful question is whether that same address ALSO needs to be sent elsewhere for routine enrichment. ClearDNS did not want ordinary enrichment to turn an outside service into another normal observer of that address. So ClearDNS built and operates its own production IP Intelligence layer, and it is live in production today: the normal path resolves network identity and geographic context from locally maintained intelligence inside ClearDNS infrastructure, and external enrichment remains available only when local intelligence cannot supply a required answer.

ClearDNS did not build IP Intelligence to claim that an IP address never leaves its infrastructure. It was built so that an external IP lookup is the exception rather than the normal way the product learns about a network address.

The privacy benefit follows from that engineering decision rather than being retrofitted onto it, and it is a narrow, specific benefit. This is an enrichment concern, separate from DNS resolution: it is about how often the product must hand an address to an outside enrichment service to learn about it, not about where allowed DNS queries are resolved. The local-first design makes external enrichment unnecessary for the large majority of IP Intelligence lookups.

The layer that is live in production has a single shape. Source-address network and geographic context is resolved through ClearDNS IP Intelligence, and external enrichment is the exception that sits behind it, not a parallel source that individual components reach on their own:

ClearDNS
  |
  +- trusted ingress context (used where already authoritative)
  |
  +- ClearDNS IP Intelligence (live in production)
        |
        +- locally maintained Network intelligence
        +- locally maintained Geographic Country intelligence
        +- explicit Geographic City detail
        +- isolated external enrichment (only for genuinely missing fields)

ClearDNS components do not independently treat external IP-enrichment services as their normal source of network or geographic intelligence. External fallback is centralized behind ClearDNS IP Intelligence, so there is one boundary at which an address can reach an outside enrichment service and one place where that exception is governed.

How ClearDNS uses IP Intelligence#

ClearDNS IP Intelligence is the internal authority the product uses to learn the network identity and geographic context of a source address. The features that need that context reach it through this one service, so external enrichment stays centralized behind a single boundary rather than scattered across components. This is the current architecture, not a plan.

• Direct DoH. A device that speaks DNS-over-HTTPS reaches ClearDNS through trusted edge ingress. Where that trusted ingress already supplies authoritative source-network context, ClearDNS does not make a redundant IP Intelligence lookup merely for symmetry; it uses the context it already holds.
• DoT. The DNS-over-TLS path carries the verified real client address through the authenticated gateway. Source network identity and geographic country for that client are resolved through ClearDNS IP Intelligence, and the gateway's own geography is never substituted for the client's geography.
• Network History. The per-device network ledger uses ClearDNS IP Intelligence for network identity and coarse geographic context derived from the stored connecting address. It contains no DNS query names.
• Live Traffic Map and source geography. Source geography means the geographic country of the connecting IP. The network-associated country is a separate network fact, not a substitute for it. A cross-country tunnel indication compares the connecting-IP geographic country with the device timezone country; the network-associated country must never stand in for the geographic country.
• Destination geography. Destination geography is separate from source geography and is based on the actual DNS answer IP. Source network country, source geographic country and destination geographic country are independent semantics, and none of them overwrites another.
• City. City is approximate explicit-detail intelligence. It does not run on the latency-sensitive normal resolver hot path, and it is suppressed when the evidence does not support acceptable precision.
• Fallback. Local intelligence is primary. External enrichment fills only genuinely missing information, valid local fields are preserved, and the fallback stays isolated inside ClearDNS IP Intelligence. A source or update failure does not globally switch ClearDNS to external enrichment.

Keeping routine enrichment inside ClearDNS#

How often the local-first design actually avoids an external lookup is a measurable question, so ClearDNS measured it against a fixed reference set.

In the fixed 500-address reference corpus used to validate the architecture (352 IPv4 and 148 IPv6 addresses), both required normal-path answers were available locally for 483 of 500 addresses, or 96.6%. Put another way, approximately 97% of the reference addresses could be answered entirely inside ClearDNS infrastructure for the normal IP Intelligence path. Broken into the two fields: network information was available locally for 97.8% of addresses (489 of 500) and geographic country for 98.4% (492 of 500).

For network identity alone, 489 of 500 addresses were answered locally. For the complete normal path, both network identity and geographic country were available locally for 483 of 500 addresses, or 96.6%.

This figure needs an honest qualification, stated plainly. It is drawn from a fixed reference corpus, not production traffic. It is not a percentage of users, not a measurement of requests in general, and it is not independently audited. Every number here is a property of that reference set. Its purpose is narrow and specific: to show how often the architecture avoided needing external enrichment in the validation set.

Local-first does not mean local-only#

Keeping an address inside ClearDNS is a privacy objective, but it is not an absolute one, and treating it as absolute would produce worse service. If the maintained local intelligence genuinely cannot answer a required field, refusing an external lookup on principle would only return a worse answer to the user. ClearDNS therefore does not use "100% local" as a purity target. The objective is local-first with high-quality fallback: keep as much information inside ClearDNS as practicable without sacrificing coverage, accuracy or service quality.

The balance is expressed in a few concrete rules:

• Local intelligence is primary. The normal path resolves the required fields from ClearDNS-maintained intelligence.
• Fallback fills only what is missing. Valid local fields are not replaced by an external answer. When a required field is genuinely unavailable locally, external enrichment completes the missing information, not the parts already answered.
• Results are cached. A repeated unresolved address does not have to leave ClearDNS again and again.
• An update-source outage does not flip the system into external-fallback mode. A failure to refresh the maintained intelligence does not convert the whole system into routing every lookup outward.

This section is about the balance between privacy and service quality, not about sacrificing one for the other.

What an external fallback sees#

When a fallback does occur, the boundary should be stated as precisely as the privacy page states every other boundary. An external enrichment service necessarily receives two things: the IP address being enriched, and the time at which ClearDNS makes that request. Both are inherent to asking an outside service to enrich an address.

What ClearDNS does not deliberately attach is the context that would turn that lookup into a description of a user rather than a description of an address:

• the DNS question and the domain name;
• the originating DNS-event timestamp (the time an external service can observe is the time of the enrichment request itself, not a ClearDNS-supplied event time);
• the policy identifier, the member identifier and the device identifier;
• account or payment identity;
• browsing context;
• Network History records or any DNS-history records.

To be precise about what this is and is not: the address itself is the field being looked up, so it is not concealed before the request, and ClearDNS does not claim the address is anonymized or hidden from the enrichment service. The property being described is data minimization and context separation, which is scope, not concealment. ClearDNS does not deliberately attach or send the DNS event, policy relationship, device identifiers, account identity or browsing context with that enrichment request.

Why one country field is not enough#

ClearDNS keeps two country answers for an address rather than one, and the reason is empirical rather than theoretical. In the reference corpus, among the 483 addresses where both local answers existed, the network-associated country differed from the geographic country for 47 addresses. Those disagreements were concentrated in VPN, CDN, cloud and distributed infrastructure.

That is a discovered problem, and it maps to two genuinely different questions:

• Which network operates this address?
• Where is this address geographically used?

One is not a lower-quality version of the other. A VPN exit can have a network-associated country that differs from its geographic country. CDN and edge infrastructure serve an address from many places while its network ownership stays constant. Cloud address space is administratively one thing and physically another. Globally distributed services span regions under a single network identity. Collapsing the two questions into one country field would discard the more accurate of the two answers in exactly the cases where they diverge, which are exactly the difficult cases. ClearDNS keeps both answers separately so that a consumer of the service can reason about each without the other silently overwriting it.

ClearDNS uses its production IP Intelligence service as the internal authority for source-address network and geographic enrichment, and this separation is what lets source-network context and cross-country tunnel reasoning be answered correctly.

Why ClearDNS sometimes stops at country#

IP geolocation is approximate. It is not GPS, and it does not become GPS because a database is willing to return a City string. An enrichment source can return a city even when the underlying geographic uncertainty is wide. A city label is not proof of city-level precision. Treating the two as equivalent yields confident-looking answers that are wrong.

ClearDNS carries an uncertainty measure alongside geographic detail and exposes City and Region only when that uncertainty falls inside an accepted product-quality boundary. Otherwise it deliberately stops at the country-level answer. The specific value of that boundary is an internal quality parameter and is not published here; what is public is the rule it enforces. A suppressed low-confidence detail answer is the correct behavior, not a coverage gap, because the country-level answer that remains is the one the data actually supports. This detail resolution runs separately from the latency-sensitive path, not inline with hot-path work.

The purpose of the rule is not to maximize the percentage of rows that contain a city. It is to maximize the useful accuracy of the answers ClearDNS actually shows. The reference corpus supports the distinction: within the accepted uncertainty boundary, normalized city agreement was 244 of 249 comparable addresses, or 98.0%. Above the boundary, agreement deteriorated sharply, which is precisely why those more precise-looking answers are suppressed. The comparison source is used as a reference view, not certified ground truth, so this figure describes agreement between two independent views rather than certified accuracy.

Source failure is not runtime failure#

The intelligence that the local path depends on can fail in ordinary ways. A source can become unavailable, credentials can stop working, an update can arrive corrupt, a refresh can be interrupted partway through. None of those failures should make live ClearDNS IP Intelligence stop answering, and the design is built so that they do not.

The property, stated at the level that matters:

• Validated generations of the intelligence are retained inside ClearDNS infrastructure.
• New intelligence becomes the serving authority only after it is verified.
• A failed or suspicious update does not replace the current generation.
• The current validated generation continues serving if an update fails, and the previous good generation remains retained for recovery.

Source failure and update failure are contained before the runtime, so a bad or interrupted refresh leaves the last known-good generation in place as the serving authority. Source or update failure is not runtime failure. The precise storage and content-verification implementation behind these generations is an internal detail and is not published here.

Evidence and measurement#

This page cites one measurement set, and it should be read as exactly what it is.

The reference set is a fixed 500-address corpus (352 IPv4 and 148 IPv6 addresses) assembled to validate the architecture. It is a reference test set. It is not production traffic, not a sample of users, and not a measurement of requests in general, and it is not independently audited.

The network-versus-geographic disagreements were concentrated in VPN, CDN, cloud and distributed infrastructure, which is the outcome the two-answer design is meant to preserve. The comparison source used for the City figure is a reference view rather than certified ground truth, so that figure describes agreement between two independent views, not certified accuracy.

These are the only IP Intelligence figures this reference publishes. The conventions for reading measured claims in general are on the Evidence and Measurement page.

Public specification boundary#

To preserve security, licensing obligations and proprietary know-how, this page does not publish the identities of the maintained datasets, the identity of any external enrichment provider, source URLs, the internal runtime formats, or the storage topology behind the compiled generations. As on the Domain and Network Intelligence page, the existence and behavior of these mechanisms is the public specification; their supplier-specific and implementation details are not.

Related technical references#

• Domain and Network Intelligence
• Privacy and Observability
• Evidence and Measurement