Explain encrypted DNS logs by tracing one record from live resolution to retained history. State the purpose, fields, scope, retention, key holders, authorized roles, and deletion path. Distinguish transport encryption from end-to-end encrypted storage, disclose what the resolver sees live, and show why aggregate evidence is the routine default.
That structure gives a privacy reviewer something testable. It avoids the weak assurance that data is simply “encrypted” and instead shows how a team reaches privacy-review readiness: the service can support a defined security or reliability decision without turning ordinary DNS activity into a broadly readable archive.
Open with the reviewer's decision
Do not begin with algorithms. Begin with the decision the reviewer must approve: perhaps confirming that a phishing rule reaches managed resources, diagnosing a payroll false positive, or preserving a short incident window. Name the population and owner. Then explain why aggregate coverage, policy outcomes, or a harmless known test are insufficient before requesting domain-level detail.
A purpose statement should be narrow enough to end. “Improve security” has no stop condition. “Determine whether three finance laptops attempted to resolve the reported hostname between 09:00 and 09:30” defines scope, evidence, readers, and closure. It also lets the reviewer challenge whether all three resources, every field, or the full half hour are genuinely necessary.
| Review question | Least revealing first evidence | Escalation only if needed |
|---|---|---|
| Is policy active? | Coverage and known-test outcome | One affected resource and policy result |
| Did a false block occur? | Support report and aggregate error trend | Hostname, rule, and short time window |
| Is an incident bounded? | Alert, resource set, and outcome counts | Purpose-limited retained activity |
Draw the plaintext boundary before the lock
Show the data path in ordinary language. A client sends a DNS request to a resolver, possibly through DNS over HTTPS or another encrypted transport. The resolver receives the hostname because it must resolve it and apply allow, block, or redirect policy. RFC 8484 defines HTTPS transport for DNS messages; it does not claim that the selected resolver cannot read the request.2
Next describe what becomes retained activity, when it is encrypted, and who holds the keys needed to open it. Separate transport protection, ordinary storage encryption, and end-to-end encrypted history. Storage encryption can protect a disk while leaving the service able to decrypt every row. An end-to-end design instead limits retained-history decryption to intended key holders, while honestly leaving live resolver processing outside that promise.
Turn log fields into purpose evidence
List each retained field and the decision it supports. A timestamp may bound an incident. A resource identifier may distinguish an affected endpoint from an entire team. A policy outcome may show which rule acted. If a field has no role in the stated decision, exclude it. RFC 9076 explains that DNS data can expose sensitive interests and can be correlated with other observations, so “only domains” is not a sufficient risk assessment.1
Write the interpretation limit beside the field description. DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URLs, typed searches, form entries, files, in-app chats, voice audio, or full browser history. A request may come from embedded content or background software. Reviewers need both boundaries: what the record may reveal and what it cannot establish.
Bring an access and retention proof pack
- Document the precise purpose, population, fields, time window, owner, and closure condition.
- Show the normal aggregate view and the approval step required before opening detail.
- List roles that can read retained history, grant them only within the relevant boundary, and test a role without access.
- Explain key generation, storage, recovery, rotation, removal, and loss instead of naming only a cipher.
- Demonstrate deletion, export handling, temporary-copy cleanup, and the effect of offboarding.
- Record the review result without copying private activity into tickets or presentation decks.
NIST treats privacy risk as something organizations manage alongside operational objectives, while its key-management guidance covers the full key lifecycle rather than algorithm selection alone.34 A useful proof pack therefore includes policy and people, not merely architecture. It shows that the smallest authorized group can answer the question and that access ends when the question closes.
Challenge the explanation with failure cases
Test a newly invited account before any scoped role is assigned, a reviewer whose role was removed, a lost user-held key, an expired retention window, and an exported record. Ask what support personnel, database administrators, and a compromised storage system can read in each case. A diagram is credible only when these negative paths match the explanation.
Also test over-interpretation. Give the reviewer one hostname generated by a background update and ask what it proves. The correct answer is limited: a resource or resolver produced a lookup in a time window. It does not prove who initiated it or what content appeared. Put that caution into review guidance so authorized access does not become unjustified surveillance.
Privacy reviewer questions on encrypted logs
Does encryption make DNS logs low risk?
No. Encryption narrows exposure while data is protected, but authorized viewers can still see sensitive context after decryption. Risk also depends on which fields are retained, how long they remain, who can export them, and whether a smaller aggregate can answer the operational question.
What should a privacy reviewer ask about live DNS processing?
Ask where a hostname is plaintext, which component applies policy, what transient operational data exists, and what is written after the response. A resolver must process the live lookup to answer or filter it. End-to-end encryption of retained history does not hide that live request from the resolver.
Can a DNS record prove that an employee visited a page?
No. A lookup may come from navigation, an embedded resource, prefetching, an update, or background application traffic. DNS also lacks the full URL, page contents, search terms, messages, and user intent. Treat it as one technical signal, not a behavioral verdict.
Review one Tenant history boundary
In Veilty, household resources belong to Spaces and team resources belong to Tenants. Reusable baseline and enforced policies can be assigned across Spaces or Tenants. A resource may override its boundary baseline, but it cannot weaken enforced policy. Invitations are account-scoped and grant no Space or Tenant access; 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 Tenant purpose, remove an unnecessary reader or field, and record its closure condition.