Decryption should happen outside the backend so the service can store and route encrypted DNS analytics without gaining routine access to readable history. Intended users decrypt only the evidence their role and purpose permit. Combined with aggregate-first review, short retention, and narrow scopes, this creates useful analytics without a central plaintext archive.
Use this architecture when retained domain-level evidence can answer a real security, reliability, or policy question but broad backend readability would create unnecessary exposure. Do not use encryption as permission to retain everything. First decide whether a count, policy outcome, or harmless test can resolve the issue without opening detailed activity.
Put the plaintext boundary after authorization
Draw the data path before evaluating the promise. A resource asks a resolver about a hostname. The resolver sees that live question because resolution and allow, block, or redirect decisions require it. If activity is retained, the protected record then travels through service routing and storage as ciphertext. Only an authorized client or separately controlled key service should turn that retained ciphertext into plaintext for the intended reader.
This boundary removes an important concentration of power: a database administrator, support operator, ordinary application process, or storage intruder should not automatically obtain readable history merely because they can reach backend infrastructure. It also makes an assurance testable. Ask the backend to return a retained record and confirm it receives ciphertext, not a hostname waiting for an application key.
RFC 9076 explains why the distinction matters. Individual DNS transactions and linked sequences can reveal interests and patterns even when the underlying DNS records are public. It also notes that lookups arise from primary navigation, embedded resources, applications, prefetching, and resolver work, so history is sensitive without being a reliable account of human intent.1
Compare three places a record can open
| Decryption location | Who can usually reach plaintext | Question to verify |
|---|---|---|
| Database or disk layer | Storage or database process | Can application and operator roles query readable rows? |
| Backend application | Service code and privileged operators | Can support or a compromised service invoke decryption? |
| Authorized client boundary | Intended key holder within approved scope | Can backend components complete the same decrypt? |
Disk and database encryption are still valuable. They can reduce exposure from stolen media, snapshots, or improperly discarded hardware. They do not by themselves stop the application that owns the key from reading every row. Client-side decryption addresses that different threat by withholding private keys and plaintext from the backend path. The buyer should verify key custody, not infer it from an “encrypted at rest” label.
The design also supports least privilege by separating policy administration from history reading. A person may need to change a filter without inspecting activity. Another may need a short incident view without membership or policy authority. NIST defines least privilege as allowing only the accesses necessary for assigned tasks; decryption capability should follow that same discipline rather than a broad administrator label.2
Make detail the exception path
- Write the decision to be made, its owner, affected resource set, and closure condition.
- Begin with policy state, coverage, aggregate allow or block outcomes, and a harmless known-domain test.
- If detail is necessary, specify the smallest Tenant, resources, fields, and time interval that can answer the question.
- Authorize a reader whose current role permits that Tenant history, then decrypt outside the backend.
- Record the conclusion without pasting hostnames into tickets, chat, spreadsheets, or unprotected exports.
- Close access, delete temporary plaintext, and review whether retention can now be shortened.
A useful example is a suspected false block affecting one finance resource. First check whether the policy is assigned and whether block counts changed. If those signals do not identify the cause, open only the resource, hostname result, rule, and short incident interval. Stop when the exception can be approved, rejected, or tested. Do not widen the window simply because the tool makes it easy.
Test the reader, not only the ciphertext
A successful authorized decrypt proves only the happy path. Also test an account member with no Tenant role, a policy administrator whose role lacks history access, a reader assigned to a different Tenant, and a member after removal. Each should fail to obtain usable key material or readable retained data. Test key loss, recovery, rotation, expiry, and export cleanup as carefully as initial access.
Inspect the backend side during the same exercise. Logs, traces, crash reports, support diagnostics, job payloads, and analytics indexes must not capture decrypted rows or keys. Verify that a rejected request does not leak a hostname in an error message. Finally, compare the authorization record with the actual client view so role language and cryptographic capability do not drift apart.
Avoid client-side privacy shortcuts
- Do not call transport encryption, disk encryption, and end-to-end encrypted retained history interchangeable.
- Do not grant every administrator decryption access for convenience.
- Do not retain broad detail before defining purpose, fields, readers, and deletion.
- Do not assume a client is trustworthy without device, session, key-storage, and export controls.
- Do not interpret a domain lookup as proof that a person viewed content or intended an action.
Client-side decryption narrows backend visibility; it does not erase risk after an authorized client opens data. Plaintext can still appear on screen, in memory, in an export, or in a copied case note. The operating process must minimize those copies and tell affected people what may be retained. Managed BYOD support in Veilty is planned for Enterprise use, so do not treat personal-device key handling as a current deployment path.
Client decryption boundary questions
Does client-side decryption hide live DNS requests from the resolver?
No. The resolver must process the live hostname to answer it or apply policy. Client-side decryption protects a different stage: retained activity after collection. Encrypted transport can protect the path to the resolver, but neither retained-history encryption nor transport encryption makes the live request unreadable to that resolver.
Is client-side decryption enough without role controls?
No. Cryptography must be paired with authorization, purpose, retention, and key lifecycle controls. A user who can obtain the relevant key material may read the protected history, so teams should test permitted and denied roles, remove stale grants, control exports, and rotate keys when membership changes.
Can decrypted DNS analytics prove what a person did online?
No. A DNS lookup may be triggered by navigation, embedded content, prefetching, an application, or a background update. It does not contain page contents, full URLs, search terms, chats, voice audio, or full browser history. Treat a decrypted row as limited technical evidence, not proof of intent.
Narrow one Tenant review window
In Veilty, team resources and retained history belong to a Tenant; household resources use a Space, represented as a tenant in the API.3 Reusable baseline and enforced policies can apply across Tenants or Spaces. A resource may override its baseline within the boundary, but it cannot weaken enforced policy. Invitations add account membership and do not grant Tenant or Space access; an assigned role does that afterward. Retained activity is end-to-end encrypted with user-held keys and visible only through permitted roles, while the resolver still processes live requests. Review one Tenant, begin with aggregates, authorize the shortest useful detail window, and close it when the named question is answered.