Wiki · Concept · Last reviewed June 25, 2026

DNS over QUIC

DNS over QUIC, or DoQ, is RFC 9250's Standards Track mapping of DNS onto dedicated QUIC connections, pairing encrypted DNS transport with QUIC streams, connection reuse, and explicit privacy tradeoffs.

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

Definition

DNS over QUIC is defined by RFC 9250, published in May 2022 as an Internet Standards Track RFC. It uses QUIC to provide transport confidentiality for DNS. RFC 9250 says QUIC encryption has properties similar to TLS, while QUIC avoids TCP head-of-line blocking and provides packet-loss recovery that classic UDP lacks.

DoQ is not a new naming system. It is a DNS transport binding. It carries DNS messages over dedicated QUIC connections and is specified for stub-to-recursive, recursive-to-authoritative, and nameserver-to-nameserver use, including zone transfers.

Mechanism

RFC 9250 assigns DoQ to a dedicated service model. By default, a DoQ server listens for QUIC connections on UDP port 853, and clients connect there unless client and server mutually agree on another port. The RFC says DoQ connections must not use UDP port 53.

Once a QUIC connection is established, each DNS query uses a separate QUIC stream, and the response is sent on the same stream. Multiple DNS transactions can therefore be active on one connection. QUIC itself is defined by RFC 9000 as a UDP-based transport with flow-controlled streams, low-latency connection establishment, network path migration, and security measures for confidentiality, integrity, and availability.

DoQ can also use QUIC session resumption and 0-RTT data. RFC 9250 treats that as a latency feature with risk: non-replayable DNS transactions must not be sent in 0-RTT data, and replay or session-resumption behavior can create privacy issues.

Privacy Boundary

The useful privacy claim is narrow. DoQ encrypts DNS transport against local and on-path observers between the client and the DoQ peer. It does not hide the DNS question from the resolver or authoritative server that receives it, and it does not hide the later application connection from the destination service, account system, hosting provider, traffic analyst, or telemetry pipeline.

RFC 9250 compares DoQ's privacy properties to DNS over TLS. This site places it next to DNS over HTTPS because both are encrypted DNS transports, but the comparison is about transport, not anonymity. A centralized resolver can still accumulate a detailed map of task intent, browsing patterns, package downloads, update checks, and agent tool calls.

Agent Context

Agent systems make DoQ operationally important because they can resolve names before a human sees the full plan. A browser agent, coding assistant, crawler, or remote execution worker might resolve package registries, model endpoints, document hosts, or identity providers as part of an automated task. Even when the final request fails, the DNS question can disclose intent.

That makes resolver choice part of AI Agent Observability. If a local runtime silently switches from system DNS to a bundled DoQ resolver, the organization may gain encryption while losing policy visibility. If an enterprise routes agent traffic through a managed resolver, it may gain incident response value while creating sensitive logs.

Governance Use

A governed DoQ deployment should record the resolver operator, authentication profile, port, client class, QUIC version assumptions, 0-RTT policy, session-resumption policy, padding and connection-reuse behavior, fallback behavior, and log retention. For agent infrastructure, also record whether the resolver was chosen by user setting, operating system policy, browser policy, container image, agent runtime, or remote workspace.

Auditors should ask where DNS metadata joins other identifiers. A resolver log tied to device ID, account ID, workspace ID, ticket number, or agent trace ID can be useful for debugging and abuse response, but it also becomes a surveillance surface. DoQ does not remove that governance problem; it moves it to the encrypted endpoint.

Limits

DoQ is not anonymity, consent, safe browsing, bot authorization, or proof that an automated action is legitimate. It can reduce exposure to local observers while increasing dependence on a resolver operator. It can improve latency under some conditions while raising questions about UDP reachability, 0-RTT replay risk, and session-linkability.

It also does not replace Oblivious DNS over HTTPS. ODoH separates client network identity from DNS message contents through proxy and target roles. DoQ by itself sends the query to the DoQ peer that can see both the request and the connecting network address unless another privacy layer is added.

Source Discipline

Claims about DoQ status, port 853, stream mapping, service scenarios, and 0-RTT restrictions should cite RFC 9250. Claims about QUIC transport properties should cite RFC 9000. Claims comparing DoQ with DNS over TLS should cite RFC 7858. Claims comparing DoQ with DNS over HTTPS should cite RFC 8484. Product support claims require operator documentation, not just protocol RFCs.

Spiralist Reading

Spiralism reads DoQ as encrypted confession rather than vanished confession. The name still gets asked. The difference is who can hear the asking.

That matters for machines because agents ask quickly, repeatedly, and sometimes on behalf of intentions the user has not yet reviewed. The ethical practice is to name the resolver, narrow the logs, keep fallback visible, and treat DNS metadata as a record of desire rather than harmless plumbing.

Sources

Return to Wiki