No. Private DNS transport such as DNS over HTTPS protects a query while it travels between a client and the chosen resolver; the resolver must still process the query to answer it or apply policy. Administrator visibility is a separate question governed by retention, fields, encryption keys, roles, exports, and access duration.
Treat these as two controls with different threat models. Transport privacy limits what an on-path network observer can read. Retained-activity privacy limits what people and systems can read after resolution. A deployment can have strong transport encryption and broad administrator logging, or plaintext transport and no retained history. One does not prove the other.
Draw two different boundaries
| Control | Protects against | Does not decide |
|---|---|---|
| Encrypted DNS transport | Ordinary on-path reading or alteration of the DNS message | What the selected resolver processes or retains |
| Retention policy | Unnecessary long-lived history | Who can decrypt records that are kept |
| End-to-end encrypted history | Unintended service or storage readers | Live resolver processing |
| Scoped roles and expiry | Broad or stale administrator access | What connection metadata exists outside DNS |
RFC 8484 defines how DNS queries and responses can be carried inside HTTPS.1 HTTPS protects the message between its endpoints. The resolver is one endpoint, so it obtains the DNS message. An internet provider or local Wi-Fi operator may see that a client connected to the resolver service, but not the ordinary plaintext DNS message inside the protected connection.
That does not make every transport path equivalent. Endpoint configuration, certificate validation, resolver selection, fallback behavior, browser settings, VPNs, and captive portals can change where DNS actually goes. Verify the path from the device instead of assuming that a settings label proves every application uses the intended resolver.
Follow one request
- The application or operating system creates a DNS question for a domain.
- The client sends the message through its configured transport to a resolver.
- The resolver reads the question, applies policy or performs resolution, and returns an answer.
- The service decides whether to retain any fields, aggregate outcomes, or no detailed activity.
- If detail is retained, encryption, key holders, roles, and recovery determine who can open it.
- Retention, deletion, exports, and temporary copies determine how long that visibility persists.
The resolver needs the domain to perform DNS work, but it does not thereby receive the whole browsing session. DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URLs, search terms, form entries, files, in-app chats, voice audio, or full browser history. A page can also trigger lookups for embedded content that a person never chose directly.
RFC 9076 describes how DNS data may reveal sensitive interests while also warning that queries can arise from navigation, prefetching, applications, and other indirect activity.2 This is why visibility needs two honest statements at once: domain activity is sensitive enough to protect, and too incomplete to treat as a behavioral verdict.
Design admin visibility separately
Begin with the administrator’s decision, not the availability of a query-log screen. Routine questions such as whether policy is assigned, whether a known test was blocked, or whether error rates changed often need only configuration state and aggregate outcomes. Open detail only when a named incident or false positive cannot be resolved without it.
- Specify the Tenant, profile, endpoint group, or resources covered by the review.
- Choose the shortest useful interval and the minimum fields needed for the decision.
- Separate policy-changing roles from retained-activity decryption roles.
- Require a named purpose, owner, approval, expiry, and closure condition.
- Keep exports inside an equally protected boundary and delete temporary plaintext.
- Record the conclusion without reproducing sensitive DNS rows.
Aggregate views still need care. A single endpoint, tiny team, rare event, or precise interval can make a count identifying. Limit dimensions and drill-down, combine or suppress small groups where appropriate, and prevent routine viewers from joining multiple reports into a detailed timeline.
Verify both privacy layers
For transport, test from the actual endpoint on office Wi-Fi, another network, and any relevant VPN or browser configuration. Confirm the intended resolver receives a harmless known query and check that no unintended plaintext fallback occurs. Test the failure behavior too; a private path that silently changes resolvers under pressure may violate the deployment’s trust decision.
For retained visibility, use accounts with different duties. Confirm a general account member and policy administrator cannot decrypt detail, a permitted reader can open only the intended scope, and expired or removed roles stop working. Exercise key recovery, rotation, retention expiry, deletion, and export cleanup. These tests prove a different boundary from the network-path check.
Avoid boundary confusion
Do not answer “who can see my activity?” with only “we support DoH.” Do not answer “is DNS private on public Wi-Fi?” with only a statement about encrypted storage. Avoid calling DNS activity complete browsing history, and do not call aggregates anonymous without examining population size and dimensions. Each answer should name the observer, data state, and control.
The practical outcome is an accurate privacy boundary. Users can understand what network transport hides, what the resolver must process, what is retained, and which administrators may read it. Operators can then improve each control without using strength in one layer to conceal exposure in another.
Transport and visibility questions
Can an internet provider read a DNS-over-HTTPS query?
The HTTPS connection protects the DNS message in transit from ordinary on-path inspection, though network observers can still see connection metadata such as the destination service. The selected DoH resolver receives the DNS message so it can answer the query.
Does using encrypted DNS require keeping a query log?
No. Transport choice and retention choice are independent. A resolver can process a live request without keeping a user-readable detailed history. Decide separately whether any fields are retained, for how long, in what form, and for which named purpose.
Can a DNS administrator see full website activity?
No. Even an authorized DNS activity view is limited to retained domain lookups and related policy context. It does not contain full URLs, page contents, searches, form entries, files, messages, voice audio, or a complete browser history.
Review one Tenant data path
Veilty’s resolver processes live DNS requests, while retained Space or Tenant activity is end-to-end encrypted with user-held keys and exposed only through permitted roles. Trace one managed endpoint from its DNS transport to its Tenant history. Verify the resolver path with a harmless test, then confirm an account without the activity role cannot decrypt retained detail. Document the two results separately.