Wiki · Concept · Last reviewed June 25, 2026

DNS over HTTPS

DNS over HTTPS, or DoH, is a Standards Track protocol for carrying DNS queries and responses inside HTTPS exchanges, moving resolver traffic into the same encrypted transport family used by the web.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, DoH, privacy, agents, metadata, surveillance

Definition

DNS over HTTPS is defined by RFC 8484, published in October 2018 as an Internet Standards Track document. The protocol sends DNS queries and receives DNS responses over HTTPS, with each DNS query-response pair mapped into an HTTP exchange. Its registered media type is application/dns-message.

DoH changes the transport path for DNS. Traditional DNS traffic is often visible to local networks, access providers, and other on-path observers. DoH uses HTTPS so those observers no longer see plaintext DNS queries in the same way. The chosen DoH resolver, however, still receives the DNS question and can be a powerful metadata point.

Mechanism

RFC 8484 allows both HTTP GET and POST. A DoH server must implement both methods. With POST, the DNS query is carried in the message body using application/dns-message. With GET, the query is carried through request variables in a way that can interact differently with HTTP caching and metadata behavior.

The protocol sits between stub resolvers and recursive resolvers. It does not redefine DNS names, records, or resolver policy. It defines a web-compatible transport binding: DNS messages travel as HTTP requests and responses over HTTPS.

Privacy Boundary

DoH is often discussed as a privacy technology, but the useful boundary is specific. It can protect DNS queries from local passive observation and some on-path tampering. It does not hide the query from the resolver that answers it, and it does not stop the later application connection from revealing the destination through account state, IP traffic, server logs, cookies, telemetry, or other identifiers.

This is why Oblivious DNS over HTTPS exists as a separate experimental design. ODoH adds proxy and target roles so no single DNS server entity should see both the client IP address and the DNS message contents. DoH alone does not make that split.

Agent Context

Agentic browsers, code assistants, crawlers, and workplace automation may generate DNS traffic before users understand what an action will contact. A package lookup, document fetch, tool call, web search, or embedded resource load can all create resolver-visible intent. If the agent or application chooses a resolver independently from the operating system or enterprise network, the governance question shifts from "was DNS encrypted?" to "who received the query, under what policy, and why?"

DoH therefore matters for AI Agent Observability. Resolver choice can affect logging, malware filtering, parental controls, enterprise monitoring, geolocation, latency, and incident response. Those effects can be legitimate or abusive depending on context.

Governance Use

A governed DoH deployment should record the resolver operator, resolver URI template, client class, application or operating-system control point, request method, media type, retention period, filtering policy, fallback behavior, and whether DNS logs are connected to account, device, agent, or workspace identifiers.

For agent systems, also record whether the resolver was selected by the user, enterprise policy, browser, extension, agent runtime, container image, or remote execution environment. Resolver policy should be visible in audits because DNS can reveal task intent even when the final web request fails.

Limits

DoH is not anonymity, consent, safe browsing, bot authorization, or proof that a request is legitimate. It encrypts one transport leg. The resolver may still log queries. The client may still send identifying HTTP traffic after resolution. A managed network may lose visibility it needs for security or compliance, while a centralized resolver may gain more cross-site knowledge than a local resolver had.

DNS over TLS, specified in RFC 7858, and DNS over QUIC, specified in RFC 9250, also address encrypted DNS transport with different protocol choices. DoH should be compared against those transports by deployment need, not treated as a universal upgrade.

Source Discipline

Claims about DoH methods, media type, request-response mapping, and Standards Track status should cite RFC 8484. Claims about DNS over TLS should cite RFC 7858. Claims about DNS over QUIC should cite RFC 9250. Claims about ODoH should cite RFC 9230 and preserve its Experimental status. Product claims require operator documentation.

Spiralist Reading

Spiralism reads DoH as a reminder that privacy is routing. Encrypting a question changes who can hear it, not whether the question exists.

That matters for agents because machines ask names at speed. The ethical practice is not to call encrypted DNS private and move on. It is to name the resolver, narrow the logs, expose the policy, and remember that a domain lookup can be a confession of intent.

Sources

Return to Wiki