Tell the customer which component sees a live DNS request, whether activity is retained, who holds the keys, which roles can decrypt it, and when access and data expire. Separate aggregate reporting from detailed rows and support every statement with a test or control. That answer earns trust because it describes actual access, not encryption in the abstract.
A customer asking “who can read this?” is usually testing more than a permission screen. They want to understand the complete path from live request to retained record, including service operators, customer administrators, recovery mechanisms, exports, and offboarding. Give them a short direct answer first, then the evidence behind each boundary.
Answer in layers
Begin with live processing. The selected resolver receives enough of the DNS request to return an answer and apply policy. Encrypted transport can protect the message while it crosses a network, but it does not conceal the request from that resolver. Say what transient operational handling occurs and what, if anything, is written after the response.
Then explain retained activity. State whether detailed rows are retained by default or by choice, which fields they contain, how long they remain, and whether routine reporting can use aggregate results instead. Finally, describe the decryption boundary: who possesses or can obtain usable keys, which scoped role is also required, and whether support, infrastructure, or database personnel can produce plaintext.
| Moment | Customer question | Useful evidence |
|---|---|---|
| Live resolution | Who receives the hostname now? | Data-flow description and transient handling |
| Retained storage | What remains after the response? | Fields, encryption boundary, retention, and deletion |
| Authorized review | Who can cause plaintext to appear? | Role test, key path, approval, expiry, and audit record |
This distinction matters because ordinary storage encryption and end-to-end encrypted retained history answer different questions. Storage encryption can protect media while the service still holds a general decryption path. An end-to-end design should prevent unintended service roles from opening retained history, even though the resolver necessarily handles the live lookup.
Name every possible reader
- Customer members who can view aggregate policy or reliability results.
- Customer roles permitted to decrypt detailed retained activity.
- Vendor support, operations, security, and database personnel.
- Key-recovery approvers, backup holders, and emergency-access roles.
- Export recipients and external systems that receive copied data.
- Former members, lost devices, and stale credentials that should no longer work.
For each group, answer “never,” “aggregate only,” or “detailed under these conditions.” Avoid saying “only authorized users” without defining authorization. A buyer needs the scope, purpose, approval, duration, and revocation mechanism. If recovery creates an alternate path, include it; a path does not disappear from the threat model because it is labeled emergency use.
Also state what the data cannot show. 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 notes that lookups can arise from navigation, embedded resources, prefetching, applications, or resolvers, so a row should not be presented as proof of user intent.1
Turn the answer into evidence
Pair each claim with a negative test. Invite an account without assigning a scoped role and confirm it cannot open retained activity. Use a policy administrator without decryption permission. Remove a reader, expire a temporary grant, rotate affected keys, and verify that new history remains closed. Exercise recovery rather than describing it from a diagram.
Show retention and deletion with the same discipline. Confirm that an expired interval no longer returns detail, temporary plaintext is removed when review ends, and exports have an owner and deletion rule. Record the access decision without copying private hostnames into the ticket used to prove that governance occurred.
Use a customer-ready workflow
- Ask which decision the customer is evaluating and which population it affects.
- Draw the live, retained, decrypted, exported, and deleted states of one DNS event.
- List every human and system role at each state, including recovery and support.
- Show the aggregate view used for routine work and the escalation rule for detail.
- Demonstrate denial, expiry, removal, recovery, rotation, retention, and deletion.
- Give the customer the control owner and review cadence, not merely a feature name.
Avoid reassuring but empty answers
“Everything is encrypted” omits who can decrypt. “We cannot see your data” may ignore live resolver processing, recovery, telemetry, or exports. “Admins only” can hide a role that is far broader than the customer expects. Replace each slogan with a bounded statement that names the data state, reader, mechanism, and exception.
Do not overcorrect by dumping architecture on the buyer. Lead with their decision and give the shortest accurate answer. Offer deeper proof for reviewers who need it. The goal is not to sound maximally private; it is to make the actual privacy boundary easy to understand, test, and hold accountable.
Customer access questions
Does an administrator automatically need access to DNS history?
No. Policy administration, membership management, support, and retained-activity decryption are separate duties. A vendor should identify the exact roles that can open detail and demonstrate that an ordinary administrator or newly invited account cannot do so.
Is aggregate DNS reporting always safe to share broadly?
No. A tiny group, rare outcome, precise interval, or drill-down can make an aggregate identifying. Explain the dimensions, minimum group size, access boundary, and whether readers can combine reports to reconstruct a person or endpoint timeline.
Can DNS activity prove which page a person viewed?
No. DNS records concern domain lookups, not full URLs or page contents, and lookups may be generated by embedded resources, prefetching, updates, or background applications. Treat a DNS event as limited technical evidence, not proof of a person’s action or intent.
Review one customer answer
Veilty keeps retained DNS activity within its Space or Tenant boundary, end-to-end encrypted with user-held keys and available through permitted roles; the resolver still processes live DNS requests. Review one Tenant as a buyer would: identify every possible reader, test an account without the activity role, confirm the retention rule, and write a five-sentence answer that distinguishes live processing from retained-history access.