Do not promise that encryption makes DNS activity invisible, anonymous, harmless, or readable only by a vaguely defined “customer.” The resolver sees live requests, authorized key holders may decrypt retained detail, metadata and exports can still expose context, and DNS rows cannot prove browsing intent. Promise only boundaries you can name, test, and maintain.
Encrypted observability is valuable precisely because DNS activity can be sensitive. That value disappears when a vendor turns a specific technical control into an absolute privacy slogan. A responsible claim states which data is protected, during which stage, from which reader, with what exceptions, and how the boundary is verified.
Replace absolute claims with bounded ones
| Unsafe shorthand | What it hides | Bounded replacement |
|---|---|---|
| Nobody can see DNS activity | Live resolution and authorized decryption | Name live processors and permitted retained-history readers |
| Logs are anonymous | Identifiers, small groups, timing, and correlation | List fields and explain re-identification controls |
| Everything is end-to-end encrypted | Plaintext stages, metadata, and exports | Name the encrypted object and endpoints |
| Only the customer has access | Broad roles, recovery, and former members | Name roles, key holders, expiry, and revocation |
| DNS logs show browsing history | Missing content, URLs, and intent | Call them domain-lookup and policy-outcome records |
The replacement should remain readable. For example: “The resolver processes a live domain lookup to answer it. Retained activity is encrypted for permitted Tenant roles using user-held keys; routine operations use aggregate results. Support personnel cannot decrypt retained rows.” Each clause can be checked independently and corrected when the design changes.
Audit six common claims
- “Private DNS hides queries from everyone.” It protects a transport path, not the selected resolver.
- “Encryption means no administrator can read logs.” Key possession, roles, recovery, and exports decide that.
- “Aggregates contain no personal information.” Small groups and precise dimensions may reveal an endpoint or person.
- “We never see customer activity.” Define live processing, transient data, retained ciphertext, metadata, support paths, and subprocessors.
- “A DNS row proves a site visit.” Background software, embedded resources, and prefetching can create lookups.
- “Deletion removes every copy immediately.” Account for replicas, exports, backups, cached plaintext, and key material.
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URLs, search terms, form entries, files, in-app chats, voice audio, or full browser history. RFC 9076 also cautions that DNS data can expose sensitive interests and can be correlated with other information.1 Encryption reduces exposure; it does not make the underlying evidence trivial.
Review the whole data lifecycle
Start before storage. Identify where the request becomes plaintext, which policy decision is made, and whether diagnostic data is created. Continue through field selection, encryption, key distribution, access authorization, display, export, retention, deletion, recovery, and rotation. A statement about one database column cannot support a promise about this entire path.
Treat key lifecycle as part of the claim. NIST guidance covers establishment, storage, use, replacement, and destruction because access can widen through copied credentials, stale devices, backups, or recovery paths.2 If marketing says only current permitted users can read retained activity, offboarding and rotation must make that sentence true after a role changes.
Retention deserves an explicit rule even when ciphertext is strong. Longer retention enlarges the consequence of a future key compromise and increases the chance that authorized plaintext is copied elsewhere. Decide what question each field answers, keep the shortest useful interval, and close access when the question ends.
Test the claim before publishing it
- Trace a real request through live processing, retained ciphertext, authorized display, export, and deletion.
- Test a support operator, database administrator, account member, policy administrator, and scoped activity reader.
- Remove a reader and verify that new ciphertext and usable key grants are unavailable.
- Exercise recovery and document whether it creates a new reader or plaintext copy.
- Inspect aggregate views for tiny populations, rare events, precise intervals, and unrestricted drill-down.
- Ask a reviewer to distinguish a domain lookup from a page visit or human decision.
Keep the evidence beside the approved language. Architecture, product, support, legal, and marketing owners should know who must re-review a claim when the data flow, roles, recovery method, retention, or export behavior changes. A claim that was accurate last year is not self-renewing.
Keep observability proportional
The strongest privacy claim is often a smaller collection choice. Use coverage, error rates, policy outcomes, and known harmless tests for routine work. Open detailed activity only for a named security, reliability, or policy question with a bounded population, interval, fields, reader, and expiry. Encryption then protects a deliberately narrow record rather than excusing unlimited retention.
When detail is necessary, document the resulting decision without reproducing the rows. Review whether the same question is recurring; if it is, improve the aggregate signal or policy test so future teams do not normalize broad access. Honest privacy language should push the operating model toward less exposure, not merely describe the lock around more data.
Encrypted observability claim questions
Can a vendor say DNS logs are zero knowledge?
Only if the phrase is precisely defined and every relevant path supports it. The resolver still handles live queries, and recovery, metadata, exports, or service-held keys may contradict a blanket statement. Describe each data state and reader instead of relying on an undefined label.
Does end-to-end encryption make retention unimportant?
No. Authorized readers can still expose plaintext, future key compromise may affect retained ciphertext, and exports may leave the protected system. Keep only the fields and interval needed for a named purpose, then verify deletion and temporary-copy cleanup.
Can encrypted DNS activity be used as proof of employee behavior?
Not by itself. A domain lookup may come from a page dependency, prefetch, update, or background process. DNS lacks page contents, full URLs, typed searches, messages, and user intent. Use it as a limited technical signal and corroborate carefully.
Narrow one privacy claim
Veilty separates live resolver processing from end-to-end encrypted retained activity protected with user-held keys and permitted Space or Tenant roles. Choose one public or customer-facing privacy sentence, map it across live processing, storage, decryption, recovery, export, and deletion, then test an account that should be denied. Replace any absolute wording with the narrowest statement the evidence supports.