Ask a DNS vendor to separate six boundaries: encrypted transport, live resolver processing, retained fields, storage protection, key holders, and authorized access. Then test recovery, export, deletion, and account closure. “Encrypted” alone is not an answer; buyers need a data flow showing where plaintext exists and who can make it readable.
The outcome is a privacy due-diligence record that another buyer or reviewer can verify. It should name the activity kept, the purpose for keeping it, every party able to read it, the shortest useful retention period, and what happens when a user loses a key or leaves. This is more useful than asking whether a product “uses strong encryption.”
Define the private data decision
Begin with the operational question retained DNS activity must answer. A family might need to explain why one school service was blocked on a child tablet. A team might need to confirm which policy stopped a sign-in dependency during a short incident window. If aggregate counts answer routine health questions, detailed domains do not need to become the default view or the permanent record.
Write the minimum fields, readers, and duration before the vendor call. Distinguish account identity, device or resource identity, source network data, queried domain, response, matched rule, and timestamp. Each field should support a named decision. RFC 9076 notes that DNS transactions can expose sensitive associations and that privacy risks increase through observation, retention, and correlation.1 Encryption cannot make unnecessary collection necessary.
Separate six encryption boundaries
| Boundary | Question for the vendor | Evidence to request |
|---|---|---|
| Transport | Which links use DoH, DoT, DoQ, TLS, or another protected channel? | Current protocol and endpoint documentation |
| Live processing | Which service sees plaintext while answering and applying policy? | A request data-flow diagram |
| Retention | Which exact activity fields are stored, by default, and for how long? | Field inventory and retention settings |
| Storage and keys | What encrypts retained data, and who controls each decrypting key? | Key ownership and rotation description |
| Access | Which users, operators, support staff, or subprocessors can make detail readable? | Role matrix and audited access procedure |
| Exit and failure | What happens during recovery, export, deletion, backup expiry, and closure? | Testable lifecycle documentation |
Encrypted DNS transport protects a request on its route to the chosen resolver; the resolver still needs the live lookup to answer and filter it. Retained-history encryption is another boundary. Ask whether service-controlled keys, user-held keys, or both are required; where decryption occurs; whether key rotation re-encrypts old records; and whether support or recovery can silently create another readable copy.
NIST key-management guidance treats key lifecycle, protection, access, backup, recovery, and destruction as connected responsibilities rather than a single algorithm choice.2 Apply that discipline proportionally. A household does not need a cryptography audit, but it can ask who holds keys and what recovery reveals. A team can request architecture, role, audit, subprocessor, incident, and deletion evidence before approval.
Request evidence, not security adjectives
- Ask the vendor to draw one DNS request from the device through policy evaluation and into any aggregate or detailed history.
- Mark every place plaintext exists, every key needed later, and the organizations or roles capable of obtaining those keys.
- Compare default retention with the shortest configurable period and ask whether detailed retention can be disabled.
- Request the ordinary support workflow: what an agent can see, what consent is required, what is audited, and when access expires.
- Walk through lost-key recovery, member removal, export, individual-record deletion, full-account deletion, and backup expiration.
- Confirm whether subprocessors receive plaintext, ciphertext, identifiers, or support artifacts and which contractual limits apply.
- Record unresolved answers, the document or demonstration that will resolve each one, and the person accepting any residual risk.
Ask the same question in two forms: “Can your company decrypt retained activity during normal operation?” and “Under which support, recovery, legal, administrative, or failure conditions could anyone at your company make it readable?” A precise answer may differ by plan or deployment. Verify the purchased tier rather than assuming a public security page describes every account.
Run an encrypted activity review
- Use one representative resource and a provider-owned harmless test domain during a recorded, short diagnostic window.
- Confirm which resolver answered and which live fields were required to produce the allow, block, or redirect outcome.
- Have the least-privileged intended reviewer open only the activity needed to explain the result.
- Try with an unauthorized role and confirm that policy administration does not automatically grant activity-reading access.
- Export the smallest permitted sample, identify its protection and readers, then remove the local copy according to the test plan.
- Reduce retention or delete the test detail and confirm the documented treatment of indexes, exports, support copies, and backups.
- Remove the reviewer or resource, rotate the relevant key if supported, and verify that earlier access does not remain silently usable.
Judge only what DNS evidence can support. DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. A background update, embedded resource, prefetch, retry, or shared device can create a lookup, so encrypted detail is still not reliable proof of a person’s intent.
Spot answers that need a follow-up
- “Military-grade” names no data flow, endpoint, key holder, access path, or lifecycle.
- “Zero knowledge” needs a definition covering normal use, support, recovery, export, subprocessors, and closure.
- “We never sell data” does not answer what is collected, who can read it, why it is retained, or when it disappears.
- “Only administrators can view logs” needs the exact roles, scope boundaries, audit trail, and separation from policy editing.
- “Deletion is immediate” needs treatment of derived indexes, queued jobs, exports, backups, and legal holds.
- “Encrypted DNS is private” confuses protected transport with resolver processing and stored-history access.
Encrypted activity due-diligence answers
Does encrypted DNS mean the vendor cannot see a live DNS request?
No. DoH, DoT, and DoQ protect a request while it travels to the chosen resolver. The resolver must still process the live domain lookup to answer it and apply policy. Transport encryption, retained-history encryption, key control, support access, and deletion are separate questions.
Is encryption at rest the same as end-to-end encryption?
No. Encryption at rest can protect storage media while the service still controls keys that decrypt records. End-to-end encryption should identify the endpoints, key holders, recovery path, and any point where plaintext exists. Ask for a data flow and a demonstration rather than relying on the label.
Can encrypted DNS activity reconstruct a person's browsing history?
No. DNS activity may contain a domain lookup, resource identity, time, and policy outcome, but it does not contain page contents, full URL paths, typed searches, in-app chats, voice audio, or full browser history. Background apps, caching, prefetching, and shared devices also weaken conclusions about intent.
Review one private history path
In Veilty, live DNS requests must be processed to apply policy, while retained DNS activity history and summaries are end-to-end encrypted and protected by user-held keys. Access remains scoped to the permitted Space or Tenant role. That boundary does not turn DNS activity into page history, and it does not remove the need to minimize what a household or team chooses to retain.
Use the questions above to review one representative resource: begin with aggregate outcomes, open a short detail window only for a named mismatch, verify the permitted reader, and close the window. The useful next step is not a blanket claim about privacy; it is a documented answer showing which live data Veilty processes and how retained history stays under the user-key boundary.