DNS transport encryption protects a live query while it travels between a client and its chosen resolver. Log encryption protects retained records after a system decides to save them. They cover different data states, threats, keys, and access paths. A service can implement either one without the other, so administrators must evaluate both separately.
This distinction gives a privacy reviewer a concrete outcome: a two-boundary assessment that says who can observe the live path, who can decrypt saved history, why any history exists, and when it disappears. It avoids both “the query is encrypted, so there are no logs” and “the logs are encrypted, so the network path is private.”
Draw two DNS privacy boundaries
| Boundary | Primary protection question | What remains unresolved |
|---|---|---|
| Client to resolver | Can an on-path party readily read or alter the exchange? | What the resolver processes or retains |
| Live resolver processing | Which service receives and acts on the DNS message? | Whether activity is saved afterward |
| Retained history | Who can decrypt stored events and summaries? | Whether collection was necessary |
| Review and deletion | Which roles can open history, for how long, and with what keys? | Page content or complete user intent |
DoH, DoT, and DoQ protect transport between a client and a selected recursive resolver.213 The selected resolver still receives enough of the live question to answer it and apply domain policy. Log protection begins only if an event, summary, or related metadata is retained. It may use storage encryption, application-layer encryption, end-to-end encryption, access controls, or a combination, each with a different trust boundary.
Follow one query through its lifecycle
- The client chooses a resolver and a transport, possibly through an operating system, browser, VPN, or application.
- The resolver processes the live question and returns an answer, block, redirect, or error according to its effective policy.
- The service decides whether to discard the event, aggregate it, or retain some detail for a stated purpose.
- If history is retained, keys, authorization, storage, exports, support access, and backups determine who may recover it.
- Retention and deletion rules determine how long that recoverable history and its copies remain.
A strong review follows all five stages instead of stopping at a protocol logo. RFC 9076 describes privacy risks both on the wire and in recursive resolvers, including the sensitivity of individual transactions and linked query patterns.4 The same document also makes clear that encrypted transport does not remove server-side privacy questions. Protection on one stage cannot be credited to another without evidence.
Test what each encryption claim means
For transport, identify the client, protocol, authenticated endpoint, fallback behavior, and resolver operator. A strict encrypted path that fails closed differs from an opportunistic path that can fall back to cleartext. A browser using DoH to a different provider also changes who receives the request. “Secure DNS” is incomplete evidence unless the endpoint and failure behavior are known.
For retained history, ask which fields are saved, whether identifiers are separated or minimized, who holds decryption keys, which roles can request decryption, whether support personnel can read data, how exports and backups are protected, and how deletion is verified. NIST defines data at rest as data in storage rather than transit, but that category alone says nothing about key custody or end-user access.5 Require the precise claim.
Decide whether history is needed
Begin with the operational question, not the available storage. Malware-block counts, policy-health metrics, or a failed endpoint may be answerable with aggregates. A named troubleshooting incident may justify a short window of domain-level detail. General curiosity does not justify indefinite history. Assign the smallest scope, named readers, expiry, and deletion rule before enabling or extending detailed retention.
Encryption does not make DNS history harmless. A hostname can suggest a service relationship or sensitive interest, and repeated queries can reveal patterns. At the same time, a query might come from prefetching, an advertisement, an update, or another background process. Protect retained activity as sensitive evidence while refusing to present it as a reliable transcript of a person’s intent.
Audit protection without opening everything
- Document one representative client-to-resolver path and verify its encrypted endpoint and expected failure behavior.
- Confirm the resolver that necessarily processes the live request without claiming that transport encryption hides it.
- Review aggregate outcomes first and state the exact question that would require event-level history.
- Use a permitted test role to verify access, denial, key ownership, and the boundary between separate Spaces or Tenants.
- Check retention, export, backup, and deletion behavior with synthetic administrative state, not a person’s unrelated activity.
- Remove temporary access and close the detailed review window when the named question is answered.
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. More retained DNS detail does not fill those gaps; it only creates a larger collection of domain-level events. Choose another control when the decision requires content or in-application context.
Reject common DNS-encryption shortcuts
- Do not infer zero retention from DoH, DoT, or DoQ support.
- Do not call storage encryption end-to-end without verifying key custody and decrypting endpoints.
- Do not assume role-based access replaces encryption or that encryption replaces role-based access.
- Do not retain more detail because encrypted storage is inexpensive.
- Do not describe a DNS event as page, search, message, or complete browsing evidence.
Transport and log encryption answers
Does DoH prevent the resolver from recording a query?
No. DoH protects the HTTPS transport to the selected resolver. The resolver must process the live DNS message to answer it and may be technically capable of retaining activity. Retention, minimization, access, and stored-data encryption are separate service decisions.
Is encryption at rest the same as end-to-end encrypted history?
Not necessarily. Encryption at rest can protect storage media while the service still controls decryption. End-to-end protection makes a stronger claim about who holds the keys and which endpoints can decrypt. Ask for the exact key and access boundary rather than relying on the word encrypted.
Should administrators retain detailed DNS history just because it is encrypted?
No. Encryption reduces some disclosure risks but does not create a purpose for collection. Prefer aggregate outcomes, retain detail only for a named operational or security need, restrict readers and duration, and verify deletion when that need ends.
Review Veilty history protection
In Veilty, review one resource inside its owning Space or Tenant. The resolver necessarily processes live DNS requests so it can answer, block, or redirect them. Retained DNS activity is a separate boundary: it remains scoped to that Space or Tenant, end-to-end encrypted with user-held keys, and available only through permitted roles. Start with aggregate outcomes, open detail only for a named purpose and short window, test that an unpermitted role cannot read it, then close the review when the purpose ends.