Summary

  • EDNS(0) Option 12 lets an encrypted DNS sender add arbitrary-length padding. It standardizes a wire container, not a privacy result: RFC 8467's 128-octet query and 468-octet response blocks are experimental policy choices.
  • Effective protection is jointly produced. The client requests and sizes query padding, the server chooses response behavior, the encrypted transport exposes its own records or packets, and the path imposes overhead and fragmentation limits. Timing, endpoints and query counts remain observable.

Consider two DNS-over-TLS resolvers that both advertise “padding enabled.” The first rounds every query to 128 octets and every response to 468. The second adds a constant 16 bytes. Both emit valid Option 12 fields. Only one meaningfully collapses many original message sizes into a common bucket; the other merely moves each recognizable size by a predictable amount.

That difference is the heart of the mechanism. DNS encryption protects the content of a transaction from an observer on the encrypted hop. It does not automatically hide the length of the ciphertext. Popular names, record types and answer shapes can produce distinctive query-and-response sizes. An observer who already knows those shapes may correlate an encrypted exchange with an unencrypted model without reading the name itself.

RFC 7830 supplies a deliberately small repair. EDNS already provides an OPT pseudo-record for negotiated extensions. Padding is Option Code 12 inside that space. It may appear at most once in a message. Its length field counts padding octets; zero is legal, although the option header still consumes four octets. Senders normally fill the bytes with zero, while receivers must accept other values. The bytes have no DNS meaning.

The specification stops before choosing how many bytes to add. That restraint matters. A standard option allows independent implementations to exchange padding without assigning a global privacy policy to the registry. RFC 8467 later evaluated policies and recommended, experimentally, rounding queries to the nearest multiple of 128 octets and responses to a multiple of 468. Buckets reduce the number of visible sizes. They do not make every message identical.

Even the recommended policy reveals a range. If the block size is known, a 256-octet query tells an observer that the unpadded message fell within a bounded interval. Repeated timings, the direction of traffic and the number of query-response pairs remain untouched. Encryption and padding may still leave the flow recognizably DNS. More elaborate cover traffic or jitter would address different signals and bring different costs.

The response is not a mechanical echo. When a query carries Padding, the responder must pad its reply unless that would exceed the permitted UDP payload. A responder may pad after an EDNS-capable unpadded request, but must not add the option when the requestor did not advertise EDNS. The request therefore creates bounded permission; it does not dictate a useful response length.

Size constraints turn privacy policy into path policy. Padding must be applied after other EDNS options because it consumes the space left for them. Its calculation excludes TCP's two-byte length prefix so a move between UDP and TCP does not announce a different bucket solely because of framing. Large blocks increase traffic. Near the path MTU they can cause fragmentation; beyond it they force fragmentation on UDP. RFC 7830 also warns that padding can increase amplification exposure and must not be used on cleartext DNS, where the name and answer remain visible anyway.

Encrypted transports rearrange the control surface. DoH can carry EDNS padding inside an authenticated HTTPS channel, but HTTP headers, cookies, connection behavior and timing create other correlation signals. DoQ may pad the DNS message or, when the QUIC implementation exposes the right API, align complete QUIC packets to a small set of sizes. The latter can account for acknowledgements and flow-control frames that DNS-layer padding cannot see.

The mechanism therefore has no single owner. A client controls its query and resolver choice. A resolver or authoritative server controls the response. A TLS, HTTP or QUIC stack can add or expose another framing layer. The network path determines which padded sizes arrive reliably. A valid standard option proves only that the message can carry extra bytes.

The running-code test is a distribution, not a checkbox. Operators need captures or equivalent telemetry showing the before-and-after size buckets, the share of padded responses to padded queries, the remaining unique patterns, added bytes, loss, truncation and fallback. Only then can they say whether padding expanded an anonymity set rather than decorating one flow.