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.

This page answers what data exists, why, for how long, and under which identifiers. What the product can actually do with the observability a policy owner enables, the historical Analyze views and their drilldowns, Instant Logs, and the policy-wide Live Traffic Map, is documented separately in Analytics and Live Observability. The two pages meet at one principle: historical query analytics, Instant Logs, the Live Traffic Map, Network History, device presence, security records and de-identified service intelligence are distinct data paths, not one undifferentiated log.

What a DNS resolver necessarily sees#

When a device asks ClearDNS to resolve a domain, the resolver must process certain information to do its job at all. Stated plainly, ClearDNS necessarily processes:

• the DNS question itself: the domain name and record type being asked;
• the network address the request arrives from: the connecting IP address;
• the policy, member and device binding the request authenticates as, so the correct filtering policy is applied;
• the time and the protocol and network context needed to process the request;
• the resolution and filtering outcome: the decision, the reason, and the answer returned.

Encrypted DNS changes who else can see this exchange. It does not change what the resolver sees. DNS-over-HTTPS and DNS-over-TLS protect the question and the answer on the network path between the device and ClearDNS, so networks in between cannot read them. The resolver at the other end of that encrypted channel still receives the question, because answering the question is the service. Any claim that a resolver "cannot see" the DNS it resolves would be false for ClearDNS and for every other resolver.

The IP address deserves the same plain treatment. An IP address identifies a network connection, not a person: receiving one does not tell ClearDNS anyone's name. But an IP address combined with an accurate timestamp can sometimes be correlated with subscriber records held by an internet service provider or another party, so it can constitute personal data under applicable privacy law. ClearDNS therefore does not describe IP addresses as harmless, and does not describe them as automatically identifying a person. This page states exactly where addresses are processed and where they are retained.

What ClearDNS does with this necessary information differs by data path. The classes below separate what exists only while a request is processed from what a product feature, a security purpose or service intelligence retains afterward.

Anonymous by Design and Zero-Identity#

ClearDNS is anonymous by design. The ClearDNS service does not require a conventional human identity to provide individualized DNS filtering. Policies, member scopes and devices are represented by ClearDNS technical identifiers rather than a name, email address, username or password.

The resolver authenticates the relevant policy and device, applies the configured filtering rules and returns the DNS result. ClearDNS does not use those technical identifiers to build a real-world identity profile, and does not enrich them against outside identity databases.

Payment providers such as Stripe, Apple and Google are separate supporting systems, not the ClearDNS identity system. They may hold information about a payer under their own services and legal obligations. ClearDNS receives the subscription or entitlement references needed to operate the purchased service, but the payment identity does not become the identity used by the ClearDNS DNS service.

The same separation applies to network information. An ISP, government or another party may independently possess information that can associate an IP address and time with a subscriber. ClearDNS does not perform that identity correlation. Within ClearDNS, the operational relationship remains the policy, member and device relationship documented here.

These operational identifiers can remain linked to ClearDNS records where a product feature or security purpose requires that linkage. This reference uses terms such as policy-linked and pseudonymous to describe that technical relationship precisely without redefining it as a conventional human account.

This is the meaning of Zero-Identity and Anonymous by Design: ClearDNS provides the product without requiring or constructing a conventional personal identity for the person using it.

Anonymous by Design is an architecture commitment, not a temporary signup convenience.

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.

A useful vocabulary for the rest of this page: information can be processed to answer the request, retained because a ClearDNS feature requires it, retained for security and operations, de-identified into service intelligence, or counted as aggregate product measurement. These are five different things, and calling all of them "logs" would obscure exactly the distinctions that matter. The rest of this page makes each one 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.

Temporary caching keeps the service fast without turning processing into a permanent record. The fact that information exists while a request is processed 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 is a full-product trial. It includes historical analytics so users can evaluate the complete product before choosing a plan, so policy-linked query analytics are recorded during the trial. After the trial, product states without historical analytics do not retain historical DNS analytics merely because ClearDNS is installed. 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. Historical records may include the DNS question, the time, the filtering result, pseudonymous policy/member/device context, and the network context needed to provide the feature, which can include the connecting IP address.

Retention and access. Historical DNS query data is retained for no more than 90 days and then ages out automatically. Access is scoped to the authorized policy dashboard and its exports. Moving to a product state without historical analytics stops new historical query collection; if historical analytics is enabled again later, an earlier ended history period is not restored as part of the new history period.

How this class is identified. These records remain linked to ClearDNS operational policy, member and device identifiers so the authorized dashboard can provide the feature. That technical linkage is separate from a conventional name or email account, and the records are never sold or used for advertising.

Data class 3: instant / live visibility#

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

Instant Logs is demand-activated live observability, not a continuously running query archive. ClearDNS activates the live-delivery rail for a specific policy when an authorized dashboard is actively using live visibility, with a brief continuation window so a reconnect does not create gaps. Outside active or recent live use, the resolver does not continuously populate that policy's Instant Logs buffer with query-bearing events.

While the live rail is active, query-bearing events are held in a short-lived, per-policy server-side buffer for real-time delivery and brief replay continuity. Each event has a hard maximum TTL of one minute from server receipt. That maximum may be shortened but not extended. Once an event exceeds the bound, it is excluded from the server-side live read and replay paths rather than remaining available as an Instant Logs history record.

The live buffer is not a persistent Instant Logs event database. The one-minute window is temporary delivery state, not a shorter version of Historical Analyze. An authorized dashboard can of course continue displaying an event it has already received during its own live session; the one-minute bound describes ClearDNS's server-side live replay state.

Historical Analyze is independent. When a product state includes historical analytics, DNS activity can separately enter that retained analytics rail and remain queryable under its documented retention rules. In a no-history product state, Instant Logs does not silently create a substitute historical query database.

This demand-activated, per-policy, hard-expiring live rail is one of ClearDNS's privacy-oriented architectural innovations: the service creates the temporary query-bearing state needed to provide live visibility when that capability is actually being used, instead of continuously accumulating a live-log archive in the background.

Live visibility is therefore 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 separate per-device record of network-address changes: when a device's connecting address changes, ClearDNS records the device relationship, the address and the time. The dashboard shows recent network context per device, including network name and coarse location derived from that address.

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.

Device activity and presence#

The dashboard shows whether a device has recently communicated with ClearDNS. This is deliberate product behavior, not incidental logging: near-real-time device state is one of the things the product is for.

Why it exists:

• Device status. A protection product should be able to answer "is this device actually protected right now" rather than "was it configured once".
• Troubleshooting. When DNS stops flowing from one device, recent-activity state is what makes the problem visible and diagnosable.
• Family and device administration. An administrator managing several members and devices needs to see which enrolled devices are live.
• Family safety. In rare circumstances, seeing whether a device has recently reached ClearDNS can help a parent understand whether a child's device is still protected and connected.

How it works, at the property level: ClearDNS uses recent service activity and lightweight connectivity checks to show whether a device has recently reached ClearDNS. Connectivity checks are liveness signals, not user browsing: they are not part of anyone's query history and exist only to keep device status current. Near-real-time device status is a deliberate product capability, not a byproduct.

The boundary, stated clearly:

A ClearDNS heartbeat is not GPS tracking. Device presence reflects when a device last communicated with ClearDNS. It does not report the device's precise physical location, and no location beacon exists in the product.

Where network-derived context appears, it is a separate and coarser thing: Network History stores the device relationship, the connecting network address and the time of an address change. Network and coarse location context shown in the dashboard is derived from that stored address at display time. It describes the network a device used, at network-operator and city granularity at most, and contains no query names and no GPS or precise positioning data.

Data class 5: security and abuse records#

ClearDNS may retain limited technical and network metadata needed to prevent abuse, protect authentication, investigate incidents and secure the service. These records are event-scoped (for example, a rejected authentication attempt or an anomalous administration request) and can include the connecting IP address.

Security records are separate from browsing data: they do not include DNS query names, they are not a user-facing DNS history feature, and they are retained for a limited period appropriate to their security purpose. 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: before use in this service-intelligence context, ClearDNS policy, member and device identifiers and the client IP are removed. What remains is the DNS observation itself, its classification outcome and coarse context. This data is separate from a user's policy-linked query history and is not used to reconstruct a user's browsing history.

ClearDNS uses de-identified as the data-class term for this rail: after the stated identifiers are removed, the events cannot be looked up by a ClearDNS policy, member or device identifier or client IP. They remain individual DNS observations and are not used to reconstruct a user's browsing history.

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 its own first-party product analytics.

That first-party analytics 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:

• First-party product analytics: product, acquisition and usage analytics; 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.

Why ClearDNS measures marketing performance#

ClearDNS uses first-party analytics to understand which campaigns lead to installations and subscriptions, improve its own website and apps, and support commercial analysis. This combines campaign information, device characteristics and interactions with ClearDNS's own pages, linked through pseudonymous visitor, policy, member and device identifiers. It does not require a name, email address or conventional account.

These identifiers allow ClearDNS to recognise returning visitors and connect activity across its website, dashboard and apps. The browser identifier can persist indefinitely through cookies and local browser storage unless those stored copies are cleared or removed. The app also supplies a device-derived identifier that can persist across reinstallation.

Visitor-linked marketing analytics records are retained indefinitely under the current configuration. This is separate from the historical DNS analytics described on this page, which are retained for no more than 90 days. Clearing browser storage or uninstalling the app does not delete records already retained on ClearDNS's servers.

Marketing and commercial analysis does not use DNS query history or browsing activity outside ClearDNS's own pages.

What upstream resolution sees#

ClearDNS terminates the device's encrypted DNS session at the ClearDNS edge. Authentication, policy selection and filtering happen there. If resolution is still required after those steps, ClearDNS makes a separate upstream DNS request from the ClearDNS execution context; it does not hand the external recursive service the original client transport session.

An upstream recursive service can observe the DNS question ClearDNS asks it to resolve, the timing of that request, the ClearDNS egress connection it arrives on and, when a policy owner has enabled ECS passthrough, the client-declared ECS prefix carried in that query. What ClearDNS withholds is its own internal identity: the upstream request carries no ClearDNS Policy ID, member or device identifier and no Resolver Credential, and its source address is a ClearDNS egress address, not the user's device address. That is a statement about what ClearDNS appends and withholds. It is not a guarantee that a question can never be associated with a person: the content of a question, its timing or a passed-through ECS prefix can be identifying on their own, and that limit applies to any resolver.

Client subnet (ECS). EDNS Client Subnet is the one DNS field that can carry a client-declared network prefix to a provider. By default, ClearDNS removes any ECS option a client query carries before upstream resolution, and ClearDNS never inserts an ECS option of its own. A policy owner can explicitly enable ECS passthrough for their policy. Under that setting, an ECS option present in the client's own query is left in place and travels with the upstream request to whichever provider that request goes to; ClearDNS does not restrict passthrough queries to particular providers, and a provider that ignores ECS simply does not use it. The default and the passthrough setting are therefore different boundaries, and only the passthrough setting exposes client-declared subnet information. What a provider does internally with the ClearDNS connection it sees, including any subnet logic it applies to the ClearDNS egress address, is provider behavior on ClearDNS infrastructure, not client data forwarded by ClearDNS.

How many providers see a question. Client requests and upstream requests are not a one-to-one stream. Queries answered from ClearDNS caching require no new upstream resolution, and concurrent identical resolution work is consolidated into one upstream request. In the other direction, one uncached question can reach more than one of ClearDNS's configured public recursive providers, in three ways. The first is latency hedging: ClearDNS sends the question to its primary provider for that location and, if the primary has not answered within a configured delay (currently 150 milliseconds), sends the same question to a second provider and returns whichever answer arrives first. The second is fallback after an upstream failure: if the primary attempt fails outright, with a network error, and time remains within the overall resolution budget, the same question is sent to a second provider. The third is sampled provider comparison: to keep its per-location view of provider performance current, ClearDNS selects uncached questions at random (currently with probability 1 in 256) and sends each selected question to its other configured providers as well, even when the primary was fast. A per-location cooldown of about five minutes between comparisons applies on a best-effort basis: it is a timestamp check rather than an atomic reservation, so questions arriving at the same moment can each be selected before the cooldown is recorded, and it bounds the usual rate rather than guaranteeing a strict maximum. Both figures are configuration values, stated as currently set, and ClearDNS does not publish a measured share of questions that reach more than one provider. The accurate statement is therefore: an uncached question can reach additional providers through latency hedging, fallback after an upstream failure, or sampled provider comparison. None of these mechanisms appends any ClearDNS identifier to the request.

The privacy distinction is therefore important: an upstream recursive service may see a DNS question and know that ClearDNS infrastructure asked it at that time, but ClearDNS does not attach the ClearDNS user's policy, member, device or resolver-credential identity to that upstream request.

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.

Payment providers are separate supporting systems, not the ClearDNS identity system. Their own identity relationships do not become ClearDNS's DNS identity model:

• Payment providers may know who paid. Stripe, Apple, Google, and the banks and payment networks behind them process payment identity under their own terms and legal obligations. ClearDNS cannot anonymize, and does not claim to anonymize, records held by those parties.
• ClearDNS does not require the payment identity to become the DNS identity. What ClearDNS receives and retains is the entitlement relationship: a payment or subscription reference associated with the operational policy, and the subscription status derived from it. The DNS service continues to operate on the pseudonymous policy, member and device identifiers, and a resolver request never carries payment data.
• The separation is architectural, not cosmetic. Billing references attach to the policy object, not to the resolver credential, and payment information alone is never accepted as proof of policy ownership.

The practical boundary is simple: ClearDNS can operate the purchased DNS service from the policy and entitlement relationship without importing the payer's real-world identity into the DNS service. A provider may independently know its customer; ClearDNS does not use that external identity as resolver or Dashboard authority.

Local-first IP intelligence#

Several product surfaces, such as the activity map and Network History, need context about the network address a device connects from, and ClearDNS is a network service, so it necessarily receives these connecting IP addresses in order to operate at all. This section states the privacy boundary for how that address context is resolved; the architecture behind it is documented separately in ClearDNS IP Intelligence.

ClearDNS resolves IP intelligence local-first inside ClearDNS infrastructure, and uses an isolated external enrichment fallback only for genuinely missing fields. The required fields are resolved from locally maintained intelligence by default, so the ordinary path produces the answer within ClearDNS rather than exposing the address to an outside service. When a required field is genuinely unavailable locally, the isolated external enrichment fallback completes only that incomplete answer. This boundary must be stated accurately, because a fallback provider necessarily receives the address being looked up and can observe the time of that request:

• The request is made by ClearDNS infrastructure. The IP address being enriched is the only user/network datum deliberately included for that enrichment; ClearDNS does not attach the DNS question, domain name, policy/member/device identifiers, account or payment identity, or browsing context.
• It does not carry Network History records or any DNS-history records.
• ClearDNS does not deliberately attach the originating DNS-event timestamp; the time a fallback provider can observe is the time of the enrichment request itself, not a ClearDNS-supplied event time.
• ClearDNS caches fallback results to avoid unnecessary repeated enrichment calls for the same address.

To be precise about what the fallback is and is not: the address itself is the field being looked up, so it is not concealed before the fallback request. ClearDNS does not claim that the IP is hidden from the enrichment provider. The property being described is scope, not concealment: the fallback receives an IP address to enrich and nothing about the DNS event, the user's policy relationship, or the user's identity. External enrichment is invoked only when the local answer is incomplete.

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. An IP address identifies a network connection. ClearDNS does not enrich that address against subscriber-identity databases; another party that independently holds subscriber records may in some circumstances correlate an address and time with a person. This page therefore states where addresses are processed and retained without treating network identity as ClearDNS human identity.

Lawful requests and retained data#

Like any company, ClearDNS may receive legally valid requests for information. Two architectural facts govern what such a request can produce.

First, ClearDNS can only provide information that it actually possesses. The retained data classes on this page are the complete inventory of what possession means: policy-linked analytics in the product states that include them, Network History, security and abuse records, de-identified service intelligence, aggregate usage, first-party marketing analytics, and the operational policy, member, device and billing-reference state needed to run the service. None of this data is retained for the purpose of responding to such requests; it exists for the product and operational purposes described above, and lawful process can only reach what those purposes caused to exist.

Second, operating without a conventional personal account reduces the identity information ClearDNS holds, but it does not make retained technical records immune from lawful process. There is no conventional ClearDNS account database containing a user's name, email and password, so there is no such database to produce. Retained records are keyed to pseudonymous operational identifiers. However, where a retained record contains a network address and a timestamp, another party that holds subscriber records, such as an internet service provider, may in some circumstances be able to correlate that pair with a subscriber. ClearDNS does not claim otherwise, and does not claim that there is nothing a legal process could ask for.

The honest summary: the accountless architecture minimizes what exists, the data-class separation constrains what any one record links to, and what exists remains subject to the law that applies to it.

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 keeps the data categories above separate, with different identifiers, different retention and different access control per category. 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.

ClearDNS provides individualized DNS service without requiring a name, email address or conventional account. First-party marketing analytics uses the pseudonymous identifiers described above to connect interactions with ClearDNS's own website and apps.

Related technical references#

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