DNS activity should be encrypted because a sequence of domain lookups can expose interests, routines, services, and relationships even without page contents. End-to-end encryption narrows who can read retained history, but it does not conceal live requests from the resolver. Collect less, restrict roles, set short retention, and protect the detail that remains.
The practical outcome is privacy-preserving observability. A team can confirm that protective policy works, diagnose a false positive, or investigate a narrow incident without making readable activity history available to every operator, storage administrator, or service intermediary. Encryption is one boundary in that design, not permission to gather everything.
Treat lookup history as sensitive context
A DNS record usually contains less detail than browser history, yet repeated hostnames can still reveal which health provider, union, bank, collaboration system, customer, or security tool a resource contacted. Timing and frequency can add context. RFC 9076 describes privacy risks from DNS transactions and notes that requests can be correlated with other observations.1 A hostname is therefore sensitive evidence even when it is not a full account of a person's actions.
It is also ambiguous evidence. A lookup can be triggered by an embedded image, browser prefetch, background update, application telemetry, or the resolver itself. It does not establish that someone deliberately opened or read a page. Protecting activity from unnecessary readers reduces disclosure risk; written interpretation rules reduce the separate risk that an authorized reader overstates what a record proves.
Separate three different encryption jobs
| Control | What it protects | What remains outside that promise |
|---|---|---|
| Encrypted DNS transport | Requests between a client and resolver in transit | The resolver receives the lookup to answer it |
| Storage encryption | Files, disks, or database fields against some storage exposure | The service may still hold the decryption key |
| End-to-end encrypted history | Saved activity so only intended key holders can open it | Authorized viewers can still expose or misuse decrypted detail |
Do not accept the word encrypted without identifying endpoints, key holders, and lifecycle. Ask where plaintext exists during live resolution, who can decrypt saved history, whether support staff can obtain keys, how a new member gains access, what happens after role removal, and whether exports preserve the same protection. NIST guidance treats key management as a lifecycle covering generation, storage, use, recovery, and destruction, not merely an algorithm choice.3
Minimize before you encrypt
Begin with a decision, not a log switch. “Confirm the phishing baseline reaches managed laptops” may need aggregate policy outcomes and a known test. “Repair a payroll false positive” may require one affected resource, hostname, rule result, and short interval. Neither question requires a month of readable, person-level activity. NIST's Privacy Framework encourages organizations to identify and manage privacy risk alongside business needs.2
- Prefer counts, rates, coverage status, policy versions, and exception age before detailed records.
- Limit detail by Space or Tenant, resource group, incident, domain, and time window.
- Name the roles allowed to decrypt, the decision they support, and the closure condition.
- Set deletion and export rules before collection, including copies made during troubleshooting.
- Review whether the same operational result can be produced with less identifying context.
Design a bounded activity review
- Write the exact security, reliability, or policy question and the possible decisions.
- Confirm aggregate measures cannot answer it before enabling or opening detail.
- Select the smallest boundary, resources, dates, and permitted reviewers.
- Inspect only the fields needed, treating a lookup as technical evidence rather than intent.
- Make and verify the narrowest policy or support change, then close access and remove temporary copies.
Verification should match the original question. Check that the intended resolver handled a known request, the expected policy outcome occurred, the legitimate workflow still completes, and an unrelated resource was unchanged. DNS filtering can act on domain lookups and allow, block, or redirect results. It cannot see URL paths, page contents, search terms, files, form entries, in-app chats, voice audio, or full browser history. It can also miss paths that use another resolver, cached answers, direct IP connections, cellular data, or a VPN.
Test the privacy claim, not just the cipher
A useful vendor review follows the data. Ask which metadata remains outside encrypted history, whether aggregate reports are derived before or after decryption, how authorization is enforced, whether account recovery can expose content, and how offboarding affects keys. Review audit evidence for role and key changes without demanding that the audit trail reproduce private activity. Confirm deletion covers indexes, caches, backups under the stated policy, and administrator exports.
Also test failure cases: a removed reviewer, a newly invited account with no assigned role, a resource moved between boundaries, and a lost key. The goal is not to prove cryptography through a marketing screen. It is to confirm that people outside the permitted boundary cannot open retained detail, while authorized operations still have enough evidence to make a narrow decision.
Questions about encrypting DNS activity
Is DNS-over-HTTPS the same as end-to-end encrypted history?
No. DNS-over-HTTPS encrypts a DNS exchange between the client and the selected resolver. The resolver must still process the request, and transport encryption says nothing by itself about a retained activity record. End-to-end encrypted history is a separate storage and access design in which only intended key holders can open saved data.
Can encrypted DNS activity still identify a person?
Possibly. Encryption controls who can read the protected data; it does not make the plaintext harmless after an authorized person decrypts it. Resource labels, timestamps, rare domains, and surrounding context may identify someone. Limit collection, readers, exports, retention, and the conclusions an administrator is allowed to draw.
Should every DNS request be saved if the history is encrypted?
No. Encryption reduces exposure but does not create a reason to retain data. Start from the decision you need to make. Aggregate allowed and blocked outcomes may be enough. Save detailed activity only when a defined security or reliability question requires it, for the smallest relevant scope and a documented time window.
Narrow one retained-history boundary
In Veilty, household resources belong to a Space and team resources belong to a Tenant. Reusable baseline and enforced policies can be assigned across Spaces or Tenants. A resource may override its boundary's baseline, but it cannot weaken enforced policy. Account invitations grant no Space or Tenant access by themselves; after acceptance, assigned roles govern controls and retained activity. Saved history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver still processes live DNS requests. Review one retained-history purpose, remove unnecessary detail or readers, and document when the review closes.