RFC 7830 / START HERE
DNS padding, before the details
EDNS(0) means version zero of the Extension Mechanisms for DNS. Its Padding option adds extra bytes to a DNS message.
Encrypting a DNS question hides its contents, but message length can still help an observer guess what it contains. Padding increases that length to make simple size matching harder. It is useful only with encrypted transport.
The idea in one picture
Count the DNS message
Pad inside encrypted transport
Apply the response rules
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
RFC 7830 is a May 2016 Proposed Standard defining option code 12, its byte layout and request/response rules. It does not choose one padding length for every message. Later padding-policy guidance is a separate publication, not a new edition of this RFC.
A familiar example
Imagine two fictional questions whose DNS messages are 40 and 43 bytes long. With a four-byte option header and different amounts of padding, both can reach a chosen 64 bytes. Timing, counts and transport overhead can still reveal clues, so padding does not guarantee anonymity.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Hide a length clue inside encrypted DNSEncrypting a DNS exchange does not remove every clue about the messages inside it.→
- Decode the Padding option exactlyTwo 16-bit fields precede a variable data region, and zero data bytes is legal.→
- Count the bytes before choosing paddingInclude the option header, existing OPT overhead and other options before checking a chosen target and size limit.→
- Apply the request and response rulesA padded request, an EDNS-only request and a request without EDNS impose different response rules.→
- Keep the privacy and security limits visibleExtra bytes have costs, and they leave other side channels and transport responsibilities intact.→
This introduction explains RFC 7830 (2016). Read the original RFC ↗