Only people who need to answer a defined security, reliability, or policy question should be able to decrypt DNS activity. Keep routine reporting aggregate, separate administrative power from decryption authority, and grant detailed access within a named scope and time window. This creates key ownership clarity without making private activity broadly readable.
The useful question is not simply where a key file lives. Ask which people and systems can cause plaintext to appear, under what conditions, and what happens after membership, role, device, or recovery state changes. A sound answer covers authority, technical capability, lifecycle, and proof.
Start with the decision, not the job title
Write the decision that might require detailed activity: diagnose a false block affecting payroll, bound a reported phishing incident, or confirm why an enforced rule acted on a managed endpoint. Identify the affected Tenant, resources, interval, fields, decision owner, and stop condition. If aggregate policy outcomes or a harmless known test can answer it, no one needs to decrypt rows.
Avoid granting keys to broad labels such as “IT,” “owner,” or “administrator.” Those labels mix unrelated duties. A policy administrator may need to assign rules but never inspect history. An incident responder may need a short, case-bound view but no power to change membership. A privacy reviewer may need proof of the boundary without seeing any activity at all.
Separate four kinds of power
| Power | What it permits | Useful boundary |
|---|---|---|
| Policy administration | Change DNS rules and assignments | No automatic history access |
| Access authorization | Approve a detailed review | Named purpose, scope, and expiry |
| Cryptographic capability | Turn authorized ciphertext into plaintext | Intended key holders only |
| Recovery and rotation | Restore or replace access | Separate approval and recorded event |
End-to-end encryption is meaningful only when unintended service and administrative roles cannot decrypt retained history. Ordinary disk or database encryption may protect stolen storage while leaving the application able to open every record. Ask who creates ciphertext, where private keys are available, whether recovery creates an alternate reader, and whether exports leave the protected boundary.
Key control does not hide a live query from the resolver handling it. The resolver must process a hostname to answer or apply policy. It also does not make a DNS row complete browsing evidence. RFC 9076 explains that DNS transactions can expose sensitive interests and can originate from navigation, embedded resources, prefetching, applications, or resolvers themselves.1
Choose a key-holder model
A small organization may choose two or three scoped key holders so legitimate work does not depend on one unavailable person. A higher-risk environment may require separate approval before a qualified reader can decrypt. Personal or household use may keep keys with the people who own the activity boundary. The right model is the smallest group that can still meet response, continuity, and accountability needs.
- Prefer aggregate reporting for routine policy health and service trends.
- Keep decryption rights narrower than general administration rights.
- Require a purpose, population, interval, fields, owner, and expiry for detailed access.
- Separate recovery authority when one person should not be able to bypass normal review.
- Tell affected people what is retained, who may open it, and how a conclusion can be challenged.
DNS filtering sees 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. A key holder therefore receives sensitive but limited evidence. Access policy should forbid turning it into behavioral certainty or copying it into a more exposed ticket or spreadsheet.
Write the lifecycle before granting access
- Document key generation, distribution, device storage, backup, and approved readers.
- Define how a new member receives access without sharing another person's credential.
- Set the response for a lost device, suspected compromise, role removal, and departure.
- Decide whether old ciphertext is deleted or re-encrypted after rotation.
- Define recovery authorization, evidence, notification, and post-recovery rotation.
- Set retention and deletion before collecting detailed activity.
NIST key-management guidance treats key protection as a lifecycle discipline, including establishment, storage, use, replacement, and destruction.2 That matters here because a carefully limited initial grant can become broad access later through stale devices, copied exports, unmanaged backups, or an untested recovery route.
Verify that the boundary is real
Test negative cases, not only a successful decrypt. Use an account with no scoped role, an administrator without activity permission, a member whose role has expired, and a former member after removal. Confirm each cannot retrieve usable key material or open new retained activity. Exercise recovery and rotation, then check that old grants and temporary plaintext copies no longer work.
Record the authorization and resulting decision without reproducing the underlying history. Review key holders on a schedule and after every membership or organizational change. If the list grows because access is convenient, improve aggregate evidence or escalation procedures instead of normalizing more readers.
Key ownership questions
Should every DNS administrator hold activity keys?
No. Changing a DNS policy and decrypting retained activity are different powers. Many administrators can do routine work with policy state, coverage, and aggregate outcomes. Give decryption capability only to roles with a documented need, and test that an ordinary administrator cannot open detailed history.
Should a service provider keep a recovery key?
That is a risk decision, not a harmless convenience. A provider-held recovery path may improve availability but also expands who can potentially decrypt history. Document the threat model, authorization, audit trail, and user notice. If the privacy promise excludes provider access, the recovery design must preserve that boundary.
What happens when a key holder leaves?
Revoke the member immediately, remove future grants, rotate affected keys, and decide how old retained data will be deleted or re-encrypted. Verify the former member cannot obtain new ciphertext or wrapped keys. A directory change alone is not proof that cryptographic access ended.
Review one Tenant key boundary
In Veilty, retained DNS activity belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles. Invitations add account membership but do not by themselves grant Tenant access. The resolver still processes live requests. Review one Tenant, remove any reader who does not need detailed activity, test an account without the role, and document the next access review.