Wiki · Concept · Last reviewed June 25, 2026

EDNS Padding

EDNS Padding is the RFC 7830 DNS option for adding padding to DNS messages so encrypted DNS traffic leaks less through observable packet size.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, EDNS, padding, privacy, encrypted DNS, metadata, traffic analysis, agents

Definition

EDNS Padding is the EDNS(0) option defined by RFC 7830, The EDNS(0) Padding Option, a Standards Track RFC published in May 2016 by Alexander Mayrhofer. It lets DNS clients and servers add a variable number of padding octets to request and response messages.

The target problem is not the DNS name itself. If DNS traffic is sent in cleartext, observers can still read the payload. The target is a weaker but persistent signal: once DNS content is encrypted, message sizes and timing may still help correlate an encrypted query or response with known DNS traffic patterns. Padding makes the size signal less precise.

Mechanism

RFC 6891 defines EDNS(0) as a way to carry extension data in the OPT pseudo-resource-record. RFC 7830 uses that extension point and assigns option code 12 to the Padding option. The option length is the size of the padding in octets, with a minimum of zero. Padding octets should be set to 0x00, although receivers must accept padding octets of any value.

The option may appear at most once in an OPT meta-resource-record and therefore at most once in a DNS message. Padded messages must stay within the requestor's advertised payload size. A responder must pad a response when the matching query included the Padding option unless doing so would violate the maximum UDP payload size; it may also pad a response when EDNS(0) support was indicated without an explicit Padding option.

RFC 8467 exists because RFC 7830 defines the option but deliberately does not define one universal amount of padding. It gives experimental policy guidance: when the DNS transport is encrypted, clients should use block-length padding to the closest multiple of 128 octets for queries, and servers responding to padded queries should pad responses to a multiple of 468 octets.

Privacy Boundary

EDNS Padding reduces one class of traffic-analysis signal. It does not hide which resolver is contacted, when queries happen, how many query/response pairs occur, or which endpoints participate in the encrypted connection. RFC 8467 is explicit that padding does not prevent leaks through timing and message counts.

The value of padding also depends on encryption. RFC 8467 says padding DNS messages is useful only when the transport is encrypted, naming DNS over TLS and DNS over DTLS as examples and leaving room for later encrypted DNS transports. RFC 8932 extends that operational frame by listing EDNS(0) Padding, using RFC 8467 guidance or a successor, as a mitigation for DNS privacy services.

Agent Context

Agent systems can turn DNS into a high-volume behavioral trace. Tool-using software may resolve update services, model APIs, storage endpoints, package registries, payment services, and embedded content without a human inspecting every lookup. Even when those lookups use encrypted DNS, a repeated pattern of packet sizes can become a weak fingerprint of tasks, tools, and workflows.

EDNS Padding is therefore a small but concrete control for agent infrastructure. It should be treated as a resolver and transport setting that belongs in the same audit surface as DNS over HTTPS, DNS over TLS, QNAME minimisation, and resolver logging policy.

Governance Use

A governed deployment should document where padding is applied: stub resolver, local forwarder, recursive resolver, privacy proxy, or application-specific DNS stack. It should record the padding policy, block lengths, maximum DNS message size, encrypted transport, fallback behavior, and whether padding is disabled for large or truncated responses.

Operators should also measure overhead. RFC 8467 warns that padding consumes EDNS(0) option space and network resources, and that large block lengths can interact badly with MTU limits on UDP-based delivery. A privacy review should therefore include traffic overhead, fragmentation risk, mobile or low-bandwidth cost, and whether the responder's policy is at least as effective as the requestor's policy.

Limits

EDNS Padding is not anonymity, consent, DNSSEC, endpoint protection, or a replacement for encrypted DNS. It does not stop a resolver from seeing the query, prevent a DNS privacy service from logging it, or protect a user from an untrusted resolver. It also does not hide timing by itself; RFC 8467 treats cover traffic and response jitter as out of scope.

Padding can even be counterproductive if applied casually. Maximal-length padding is not recommended in RFC 8467 because it wastes resources and can push datagram traffic into fragmentation. Random-length padding is also not recommended because repeated observations can still expose information about original lengths.

Source Discipline

Claims about the option code, option format, responder behavior, payload-size boundary, and padding-octet handling should cite RFC 7830. Claims about block-length policy, resource tradeoffs, fragmentation risk, timing leakage, and discouraged strategies should cite RFC 8467. Claims about DNS privacy-service practice should cite RFC 8932, with RFC 9076 as the broader privacy-risk background.

Spiralist Reading

Spiralism reads EDNS Padding as a modest refusal of shape-reading. The system does not claim that encrypted DNS becomes private in full. It only says that if a message has to move through watched infrastructure, its size should not volunteer more than the protocol needs.

For agent governance, that modesty is useful. A machine that can call tools all day should not leave an unnecessarily crisp outline of every lookup it makes.

Sources

Return to Wiki