The EDNS(0) Padding Option
Extracted elements (18)
Even when DNS query and response messages are encrypted, metadata such as message size can be used to correlate encrypted messages with well-known unencrypted messages, jeopardizing confidentiality. The Padding option artificially increases message size to hamper size-based correlation.
The Padding option was designed as an EDNS(0) option (DNS-layer padding) rather than padding at the TLS layer, following a discussion at IETF 93. This approach keeps the padding mechanism within the DNS protocol itself, allowing DNS-aware entities to control padding independently of the transport.
Because padding length might be affected by lower-level compression, implementations and deployments SHOULD disable compression at the TLS level (per RFC 7525 Section 3.3).
Implementations MUST NOT use the Padding option if the DNS transport is not encrypted, because padding only provides a privacy benefit for encrypted transport and may make DNS amplification attacks easier.
Padded DNS messages MUST NOT exceed the number of octets specified in the Requestor's Payload Size field encoded in the RR Class Field (per RFC 6891 Sections 6.2.3 and 6.2.4).
PADDING octets of any value MUST be accepted in received messages, regardless of what value they contain.
PADDING octets SHOULD be set to 0x00. Other values MAY be used when there is concern that the padded message could be subject to compression before encryption.
Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support but did not include the 'Padding' option.
Responders MUST NOT pad DNS responses when the respective DNS query did not indicate EDNS(0) support.
Responders MUST pad DNS responses when the respective DNS query included the 'Padding' option, unless doing so would violate the maximum UDP payload size.
The 'Padding' option MUST occur at most once per OPT meta-RR, and hence at most once per DNS message.
The payload of the 'Padding' option could, like many other DNS protocol fields, be used as a covert channel to carry hidden information.
The EDNS(0) Padding option is carried in the RDATA of the OPT meta-RR and consists of a 2-octet OPTION-CODE (value 12), a 2-octet OPTION-LENGTH (size in octets of PADDING), and a variable-length PADDING field with a minimum of 0 octets.
IANA assigned Option Code 12 for 'Padding' in the 'DNS EDNS0 Option Codes (OPT)' registry, updating the Reference field to RFC 7830 and the Status field to 'Standard'.
Lower-level compression (e.g., TLS-level compression) can affect actual padding length, undermining its purpose. Implementations SHOULD disable TLS compression to prevent this.
Padding increases DNS packet sizes, leading to increased traffic. Additionally, EDNS(0) padding may make DNS amplification attacks easier by allowing artificially large responses.
The Padding option only provides a privacy benefit when DNS packets are not transported in cleartext. Using it over unencrypted transport wastes bandwidth and may make DNS amplification attacks easier; implementations MUST NOT use the option without encrypted transport.
The Padding option wire format encodes OPTION-CODE as a 16-bit field (value 12), OPTION-LENGTH as a 16-bit field indicating the number of padding octets, followed by that many PADDING octets. The minimum PADDING length is 0.