DNS-over-HTTPS encrypts DNS messages while they travel between a client and its chosen resolver. The resolver still processes each live hostname. Activity encryption addresses a later, different problem: protecting retained logs or metrics and controlling who can decrypt them. Neither transport nor storage protection justifies collecting more detail than a defined purpose requires.
Clear privacy terminology comes from naming the data, endpoints, moment, and key holders. “Encrypted DNS” alone is incomplete. It may refer to a protected network hop, an encrypted database, or end-to-end encrypted retained activity. Those controls can complement one another, but success at one boundary does not prove protection at another.
Follow one hostname across two privacy problems
Imagine a laptop needs the address for a payroll service. With DoH, the client packages the DNS question inside HTTPS and sends it to a chosen resolver. Network intermediaries on that path do not receive a traditional plaintext DNS packet. RFC 8484 defines that exchange and its HTTP behavior. At the destination, however, the resolver obtains the DNS message and must process the hostname to return an answer or apply policy.1
A second privacy problem begins if the service retains a record after resolution. Who can read that record tomorrow? How long does it remain? Which resource and policy labels accompany it? Can support, storage administrators, or a compromised database open it? Activity encryption answers questions about that saved representation. It does not retroactively hide the live hostname from the resolver that handled it.
Name the endpoints before saying encrypted
For DoH, the endpoints are normally the client and chosen recursive resolver. The useful claim is that the DNS message is protected in transit between them. It does not promise anonymity, prevent the resolver from logging, hide the destination connection after resolution, or ensure that the chosen resolver applies an organization policy. A browser can also select a resolver path different from the operating system or network.
For retained activity, ask who creates the ciphertext and who can decrypt it. Ordinary at-rest encryption may place both capabilities inside the service. End-to-end encrypted history should make intended users the relevant key holders and exclude unintended service roles from plaintext. Then ask about invitations, role assignment, key recovery, device loss, membership removal, exports, backups, and deletion. The access claim is only as strong as that lifecycle.
| Control | Primary protected boundary | Question it does not answer |
|---|---|---|
| DNS-over-HTTPS | Client-to-resolver DNS transport | Who can read retained history later? |
| Storage encryption | Stored files, disks, or fields | Does the service hold the opening key? |
| End-to-end encrypted activity | Retained history for intended key holders | What does the resolver see while answering live? |
Compare transport, storage, and retained history
Threat models make the differences practical. DoH helps against an observer on the client-to-resolver path, but not a resolver that mishandles live or retained data. Storage encryption can help after a disk is stolen, yet offer little against an application or administrator that has the key. End-to-end encrypted history can limit service-side reading of saved activity, but an authorized viewer may still expose plaintext after opening it.
Minimization remains independent of every cipher. RFC 9076 describes how DNS transactions can expose sensitive interests and be correlated with other data.2 Retaining fewer fields, for fewer resources, for a shorter period reduces what any authorized reader or compromised endpoint can reveal. Begin with aggregate policy coverage and outcomes, then permit detail only for a named question and bounded interval.
Test each claim at its own boundary
- For transport, verify the client uses the intended resolver and encrypted protocol on the real network path.
- For live processing, document which resolver component receives the hostname and applies policy.
- For retention, identify every saved field, its purpose, boundary, and deletion condition.
- For key ownership, test an account without a scoped role and a former member after removal.
- For exports and recovery, confirm whether plaintext or substitute keys can bypass the stated protection.
- For minimization, prove that a routine aggregate can answer the common question before opening detail.
Also verify DNS limits. DNS filtering can allow, block, log, or redirect a domain lookup under policy. It cannot read a page path, page contents, typed searches, form data, in-app chats, voice audio, files, or full browser history. DoH does not add those fields, and activity encryption does not transform a domain record into content evidence. Cached answers and alternate resolver paths can leave activity gaps.
Use privacy words that survive review
Prefer “DNS messages are encrypted in transit between the client and selected resolver” to “DNS is private.” Prefer “retained activity is end-to-end encrypted for permitted role holders” to “we cannot see anything.” Add the live-processing boundary, metadata boundary, recovery behavior, and authorization model. Precise sentences are longer, but they let a reviewer verify the claim and prevent one control from borrowing trust from another.
Avoid describing encryption as consent or purpose. A team still needs a reason to retain activity, a least-visibility default, scoped access, a review point, and deletion. NIST Privacy Framework guidance treats privacy as risk management connected to organizational needs, not as a checkbox supplied by cryptography.3 The right question is not only “is it encrypted?” but “why does this data exist, and who needs it now?”
Questions that separate DoH from activity encryption
Can a DNS-over-HTTPS resolver read the hostname?
Yes. DNS-over-HTTPS protects the message on the network path to the selected resolver. The resolver receives the DNS question so it can answer, filter, or route it. DoH reduces exposure to intermediaries on that hop; it does not make the live request opaque to the resolver.
Is database encryption the same as end-to-end encrypted history?
Not necessarily. Database or disk encryption may protect stored bytes while the service still controls the decryption key. End-to-end encrypted history makes a narrower claim: retained activity can be opened only by intended key holders. Review key ownership, recovery, exports, role removal, and plaintext lifecycle.
Do encrypted DNS transport and encrypted history hide browsing content?
No. They protect DNS messages or retained DNS activity at particular boundaries. DNS itself does not contain page text, full URLs, searches, chats, files, or voice audio. Other parties and controls may still observe connections or application activity, and authorized viewers may see decrypted domain-level history.
Separate live and retained data in Veilty
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; accepted members need assigned roles for 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. The resolver still processes every live request needed to answer and enforce policy. Review one privacy statement now and split its transport, live-processing, retention, and access claims.