Privacy and Observability

Privacy claims about a DNS service should distinguish processing from retention, and should distinguish one data path from another.

A resolver necessarily sees the information required to answer a DNS request while it is processing that request. The useful architectural questions are what is retained afterward, for what purpose, for how long, and with which identifiers attached.

ClearDNS separates observability into distinct classes instead of treating the word "logs" as one undifferentiated concept. This page describes each class separately.

Zero-Identity does not mean zero operational state#

ClearDNS uses operational identifiers for the policy, the member scope, the device, the resolver transport credential, and temporary dashboard sessions. Those identifiers let the service apply the correct filtering policy without a conventional profile containing an email address, username and password.

Zero-Identity is not a claim that networking occurs without an IP address. It is the architectural choice not to require a conventional personal account identity in order to provide individualized DNS policy.

Operational identifiers are pseudonyms, not a person's name, but records linked to a persistent policy or device identifier are described on this page as policy-linked or pseudonymous, never as anonymous.

Resolution and query-history retention are separate concerns#

The resolver does not require a permanent browsing-history database merely to answer DNS. Persistent policy-linked query history exists when the product state includes historical analytics, which covers the full-feature trial and the historical-analytics plans. In product states without historical analytics, the resolver does not create that policy-linked history.

The rest of this page makes that precise.

Data class summary#

This table summarizes the classes described in detail below.

Data class 1: transient resolver processing#

To resolve and filter a request, the resolver processes in-flight: the query name and type, the authenticated policy/member/device binding, current policy state, the connecting network address, the upstream response, the filtering decision, and timing/error state.

This is data-plane processing. Short-lived, bounded caches (for policy state, bindings and DNS answers) exist to keep the service fast; they expire on the order of seconds to minutes. The fact that information exists during processing does not by itself create user-visible history, service intelligence, or a retained record. Those are the separate classes below.

Data class 2: policy-linked query analytics#

Historical query analytics are a product feature: they exist so the user's own dashboard can answer questions like which device requested what, what was blocked, why, and when.

When this class is active. Historical analytics are part of the product states that include them:

The ClearDNS trial includes the complete product experience, including historical analytics, so policy-linked query analytics are recorded during the trial. After the trial, plans without historical analytics do not retain a policy-linked query history for the user. Choosing a historical-analytics plan is the product decision to retain query analytics; there is no separate off switch inside those plans, because historical analytics is a defining capability of those plans.

What a retained analytics record can include. Under the current implementation: the query name and type, the decision and reason, the operational policy, member and device identifiers, timestamps, resolver/network context (resolver location, protocol and connection metadata), ASN and country, the answered destination address where applicable, and client IP information in both full and network-truncated forms.

Retention and access. Analytics records are retained for up to 90 days and then age out. User-facing access is scoped to the authorized policy dashboard and its exports. When historical analytics becomes active again after a period in a product state without it, reads are floored so records from before the new active period are not re-exposed.

What this class is not. These are policy-linked pseudonymous records associated with ClearDNS operational identifiers rather than a conventional name or email account, and they are not sold or used for advertising. ClearDNS describes them as pseudonymous, not anonymous.

Data class 3: instant / live visibility#

Live logs solve a different problem from long-term history: seeing what is happening right now.

ClearDNS streams recent policy events to an actively authorized dashboard through a policy-scoped, bounded live buffer. Properties of the current implementation:

• events carry the query name, identifiers, decision, network context and the answered address, but no client IP;
• the buffer is a bounded ring designed for real-time display, not an archive;
• events are appended while live visibility is armed by an authorized reader or session; the live rail is bounded and is not continuously populated as a permanent history for inactive policies;
• access requires the same authenticated, policy-bound dashboard session as any other administration surface.

Live visibility is not the same thing as 90-day historical analytics, and the two are gated separately by product state.

Data class 4: Network History#

Network History records which networks a device has recently used. It is not derived from browsing data.

It is a dedicated ledger of network-address changes per device: when a device's connecting address changes, ClearDNS records the policy/member/device relationship, the address and the time. The dashboard shows the most recent network context per device, enriched with network (ASN) and coarse location information at display time.

Key property:

Network History is not DNS query history. The ledger contains no query names, and the dashboard feature never reads the analytics records.

These records exist for device and network visibility and related operational and security use, and they are linked to the operational policy/member/device state they describe.

Data class 5: security and abuse records#

ClearDNS may retain limited network/security metadata for abuse prevention, authentication integrity, incident investigation and protection of the service. These records are event-scoped (for example, a rejected authentication or an anomalous administration request) and can include the time, the event type, request metadata such as the path and user agent, the session reference, and the connecting IP and country.

Security records are separate from browsing data: they do not include DNS query names, and they are not a user-facing DNS history feature. Resolver credentials, invitation values and other possession-bearing secrets are kept out of ordinary logs.

Data class 6: de-identified service intelligence#

ClearDNS operates a separate service-intelligence path used to maintain and improve filtering quality, for example to discover domains that may be missing from the intelligence corpus.

Events on this path are structurally de-identified at the point of creation. A service-intelligence event contains the query name, the decision and its category/reason, the resolver location, the requesting country, the answered destination address where applicable, and a timestamp. It contains no policy ID, no member ID, no device ID and no client IP, and ClearDNS infrastructure names and reserved local-network names are excluded before emission.

ClearDNS calls this rail de-identified rather than anonymous: the events cannot be looked up by any ClearDNS identifier, but they are individual DNS observations, and ClearDNS does not overstate what removal of identifiers achieves.

Discovered domains from this rail do not automatically become block rules; they enter the validation process described on the intelligence page. This rail is maintained as part of the intelligence system: validated findings can become part of the maintained production intelligence corpus.

Data class 7: aggregate usage#

ClearDNS separately counts coarse product and service usage: how many queries a policy answered per hour, and whether product surfaces were used. Aggregate usage rows contain no query names and no client IPs, and this measurement path is kept apart from the critical policy directory so product measurement never becomes the authority for identity or billing state.

Aggregate usage is not DNS browsing history.

Product analytics are separate from DNS observability#

ClearDNS does not send its product-usage analytics to third-party analytics platforms. Instead, ClearDNS developed and operates ClearDash, its own first-party analytics system.

ClearDash is used to understand how ClearDNS products are discovered and used without introducing third-party analytics SDKs or advertising trackers into the product. It is separate from DNS resolution and DNS query history: it does not receive DNS queries and is not used as a secondary copy of resolver activity. Keeping this capability in-house lets ClearDNS control the collection path, data model and operational boundaries directly rather than outsourcing product observability to a third-party analytics provider.

The separation:

• ClearDash: product, acquisition and usage analytics; a first-party system; not a DNS query-history store; does not receive resolver DNS query events.
• DNS observability: the resolver- and product-state-specific rails described above; policy-linked query history where applicable, live visibility, Network History, and the security and service-intelligence rails.

What upstream resolution sees#

On a cache miss for an allowed query, the DNS question (the name and record type) is sent to ClearDNS's upstream resolution path. Hedging can place the same question on more than one path to reduce tail latency, and cache hits are answered at the edge without any upstream query.

The upstream resolver necessarily sees the ClearDNS infrastructure connection from which the recursive request arrives. ClearDNS does not forward the original user's client IP as DNS identity: EDNS Client Subnet (ECS) data from clients is stripped under the current configuration, and the policy, member and device identifiers and the Resolver Credential are never forwarded.

Billing identity and DNS identity#

A DNS request does not carry payment identity. Subscription state is maintained separately against the operational policy, so entitlement can be evaluated without making the Resolver Credential a payment credential, and payment records are not a recovery key for policy identity.

IP addresses, plainly#

ClearDNS is a network service, so it necessarily receives the network address from which a device connects. Depending on the feature and data path, IP/network information may be:

• processed transiently to return the DNS response and derive coarse network location;
• retained as part of policy-linked analytics, in the product states that include them;
• recorded separately as Network History, without query names;
• recorded in security events when an event warrants it;
• never included in de-identified service intelligence.

ClearDNS does not require a conventional name/email account to associate the operational policy with the device, and it does not sell DNS or network data for advertising. ClearDNS also does not claim that an IP address is anonymous: an address combined with time can be personal data, so this page states where addresses are processed and retained.

Resolver credential handling#

Resolver credentials and configuration-artifact capabilities are sensitive operational data. They are not copied into ordinary logs, analytics events, error messages, unnecessary URLs, or third-party product analytics. The app and backend use separate handling rules for sensitive resolver artifacts versus ordinary product state, including platform secure storage on devices.

Why ClearDNS has multiple rails#

Trying to use one global query log for every purpose creates unnecessary coupling. ClearDNS instead separates concerns:

resolver processing (transient)
        |
        +-> policy-linked analytics     (product states with historical analytics)
        |
        +-> bounded live visibility     (product states with live view; while armed by a reader)
        |
        +-> Network History             (address changes; no query names)
        |
        +-> security/abuse records      (event-scoped; no query names)
        |
        +-> de-identified service intelligence (no ClearDNS identifiers, no client IP)
        |
        +-> aggregate usage             (counts; no query names, no IPs)

Different rails have different identifiers, retention and access control. That is a more useful privacy architecture than asking only whether a single global "logging" switch exists.

Infrastructure visibility#

Encrypted DNS protects the DNS payload on the network path between the client and the ClearDNS transport endpoint. Infrastructure involved in transporting, executing or resolving the request can still observe the information its role technically requires. ClearDNS's privacy objective is therefore not to claim that computation happens without infrastructure; it is to minimize unnecessary identity linkage, keep data classes separated, use encryption in transit, and constrain what is retained for each purpose.

No conventional account graph#

Because the product does not require a normal email/password identity, ClearDNS does not attach DNS policy to an account profile in order to deliver individualized filtering. A policy remains an operational object; a device remains an operational binding; a browser session remains temporary administration state. That separation reduces the amount of personal account information that can be correlated with DNS activity by design.

Related technical references#

• Identity and Resolver Credentials
• Accountless Dashboard Authentication
• Domain and Network Intelligence
• Security Model