Buyers should evaluate DNS privacy claims by tracing one request through collection, live resolver processing, transport, storage, authorized decryption, sharing, export, retention, and deletion. Replace slogans such as “private,” “anonymous,” or “zero knowledge” with named data, readers, keys, and time limits, then require documentation or tests that support every boundary.
The practical outcome is a claim matrix that lets two products be compared without rewarding the boldest wording. Privacy is not a single checkbox: transport encryption, live processing, retained-history encryption, access control, minimization, and deletion protect different stages. A precise product can be the stronger choice even when its headline sounds less absolute.
Turn the claim into a data flow
Choose one ordinary lookup and ask what happens before, during, and after the resolver answers. Name the client and network, selected resolver, query fields, identifiers, policy decision, upstream requests, metrics, retained detail, support copies, exports, and deletion process. Include failure and recovery paths. A privacy promise that describes only stored rows may omit the live resolver and operational systems.
RFC 9076 explains that recursive-resolver selection has direct privacy consequences, that query transactions can be sensitive, and that requests may come from embedded content or prefetching rather than deliberate visits.2 It also notes that encrypted transports do not reduce the data available to the recursive resolver. Use those facts to reject both “DNS is public anyway” and “encrypted DNS is invisible” as incomplete.
Score eight privacy boundaries
| Boundary | Question to ask | Useful evidence |
|---|---|---|
| Collection | Which query, client, account, network, and policy fields exist? | Field inventory and purpose |
| Live processing | Which systems and parties receive plaintext to answer or filter? | Current data-flow diagram |
| Transport | Which hops are encrypted and authenticated? | Protocol and endpoint documentation |
| Retention | Which detail, aggregates, and security records remain, and for how long? | Retention schedule and deletion behavior |
| Access and keys | Who can decrypt or read each data state? | Role matrix, key custody, and denial test |
| Sharing | Which processors, authorities, or integrations receive data? | Subprocessor and disclosure terms |
| Export and recovery | Can plaintext copies or new readers be created? | Export controls and recovery design |
| Verification | How is the claim tested and corrected after change? | Audit, test result, owner, and review date |
Score the actual service tier and configuration, not the company in general. A consumer resolver, managed filtering plan, enterprise integration, and support channel may follow different data paths. Record “not documented” rather than guessing. Ask whether legal, abuse, reliability, billing, and security records sit outside the advertised retention statement, and whether account deletion removes linked identifiers and temporary exports.
Minimization deserves its own score. Routine management often needs resolver health, coverage, error rates, and aggregate policy outcomes rather than a long per-device query history. NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk, including data-processing relationships.3 A strong claim connects collected data to a purpose and removes it when that purpose ends.
Separate transport from retained history
DNS over HTTPS and DNS over TLS encrypt the client-to-resolver exchange, protecting it from ordinary on-path reading. The selected resolver still needs the DNS message to answer or enforce policy. RFC 8484 explicitly covers privacy considerations for the DoH server, while RFC 9076 warns that encrypted sessions can introduce correlation data.12 Ask which identifiers the client sends and which resolver endpoint receives them.
Stored-data encryption answers a different question. Server-side encryption may protect disks while leaving service operators able to read records. End-to-end encryption may narrow readers, but the buyer must still identify key holders, role grants, recovery, revocation, exports, metadata, and authorized plaintext display. “Customer controlled” is too vague unless the product names which customer roles and whether the vendor can create or recover a usable key.
DNS filtering can act on domain lookups and policy outcomes; it cannot read page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. A retained query can reflect background software, prefetch, or an embedded dependency rather than human intent. Privacy claims should call the data DNS activity, not a complete browsing record, and buyers should reject behavior scoring built on that ambiguity.
Verify the words with evidence
- Copy one material claim exactly and underline every undefined noun: private, anonymous, customer, log, encrypted, necessary, or temporary.
- Rewrite it as a testable sentence naming the data object, processing stage, protected reader, permitted reader, key holder, and time limit.
- Trace a harmless query through live resolution, retained detail, aggregate output, authorized display, export, recovery, and deletion.
- Test an account that should manage policy but should not read retained activity, plus a former or revoked reader where supported.
- Ask for the current privacy notice, retention schedule, subprocessor list, security description, and independent evidence relevant to the claim.
- Record exceptions, undocumented boundaries, evidence date, and the owner responsible for re-review when the system changes.
- Compare products on the smallest verified boundary that meets the purpose, not on the number of privacy adjectives.
Independent assurance can strengthen evidence, but a certification label does not automatically answer the DNS-specific question. Check its scope, date, product, systems, exceptions, and whether the report tests design or operating effectiveness. Public source code can support a client-side claim yet say little about hosted retention or operator access. Contracts matter, but buyers also need a technical boundary they can exercise.
Spot privacy-claim failures
- “We cannot see queries” fails unless it distinguishes live resolver processing from retained activity.
- “No logs” fails when log, event, aggregate, cache, security record, and temporary copy are not defined.
- “Anonymous” fails when timing, rare domains, device labels, account data, or small populations remain linkable.
- “End-to-end encrypted” fails when the encrypted object, endpoints, key holders, recovery, and exports are unnamed.
- “Industry-leading privacy” fails without a measurable comparison, current evidence, and a relevant scope.
- “DNS history shows user behavior” fails because lookups lack content and intent and may be machine-generated.
DNS privacy buyer questions
Does encrypted DNS mean the resolver cannot see a query?
No. DNS over HTTPS or TLS protects the message on the client-to-resolver transport, but the selected resolver receives the query so it can answer or apply policy. Encryption in transit does not by itself determine retention, administrative access, sharing, or deletion.
Is a no-logs claim enough to establish DNS privacy?
No. Ask which events, identifiers, aggregates, security records, billing data, and temporary copies exist; whether “logs” excludes any of them; and how deletion is verified. Also ask what the resolver processes live and which parties receive data before it is discarded.
Can DNS activity be anonymous when names are removed?
Not automatically. Timing, rare domains, small groups, device labels, IP data, and linked account records may enable inference or re-identification. A buyer should examine the remaining fields, population size, access rules, correlation paths, and purpose rather than accepting an anonymous label.
Evaluate Veilty with the same test
Apply the same matrix to Veilty rather than granting it special language. Veilty must process a live domain request to allow, block, or redirect it. Saved DNS activity records and summaries are end-to-end encrypted with user-held keys, belong to their Space or Tenant, and open only to members whose assigned roles permit access; account membership alone does not grant every Space history.
Veilty currently states standard retention of up to 24 hours for detailed saved activity and up to 30 days for private summaries, with detail possibly removed sooner when storage limits are reached. Verify that boundary against the current privacy notice, test one permitted and one denied reader, inspect only a harmless query, and compare the evidence with the exact purpose that justified retained activity.