Count the bytes before choosing padding
03Include the option header, existing OPT overhead and other options before checking a chosen target and size limit.
The four-byte minimum creates a real no-room boundary. These chosen bases are response-size examples, not query lengths or a default advertised size.
Source for this drawing: RFC 7830 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A padding policy must count the whole DNS message and leave room for its own header.
- RFC 7830 does not prescribe a padding amount or block size. Its padded DNS messages MUST NOT exceed the requestor’s advertised payload size; RFC 6891 §6.2.3 says values below 512 MUST be treated as 512. The effective size is not a guarantee of path MTU or delivery, and the advertised maximum is transaction-specific (§4; RFC 6891 §§6.2.3–6.2.4).
- The selected tea.example. query is 12 header bytes + 13 encoded-name bytes + 4 question bytes + 11 empty-OPT bytes = 40. The chosen 64-octet bucket needs 64−40−4=20 padding data bytes. The picnic.example. query has 16 name bytes and base length 43, so needs 17 data bytes. Do not omit the four-byte option header or count the existing OPT header twice.
- A chosen block policy can use N=(−(B+4)) modulo K, where B already contains the OPT record and all other options and K is the block size. If B=60 and K=64, N=0: adding the four-byte option reaches 64 without an extra block. This arithmetic is a teaching policy, not a universal rule from RFC 7830.
- RFC 8467 is a separate October 2018 Experimental publication, not a formal update of RFC 7830. Its §3 says Padding MUST be the last EDNS option applied before sending and that padding-size calculations MUST exclude TCP’s optional two-octet length prefix. Its published B=59,K=32 example reaches 64 DNS octets; counting the prefix as B=61 would incorrectly select 31 data bytes, yielding 94 actual DNS octets plus a two-byte prefix for a 96-octet TCP frame. A 64-octet DNS message is 66 octets with that prefix, before further overhead.
- RFC 8467 §4.1 recommends 128-octet query blocks and 468-octet response blocks (SHOULD), subject to encrypted transport and limits. This guide’s small 64-octet buckets are explicitly illustrative, not those recommendations. A message can fit the payload limit yet fail a chosen bucket policy; do not confuse policy failure with the RFC’s no-room-for-any-option exception.
- For an illustrative 512-octet limit, a response base of 508 can add a zero-data Padding option and exactly fit. A base of 509 leaves only three octets, so even a zero-data option cannot fit. This creates the response-size exception shown in the next chapter, without inventing a numeric padding default (§4).
Fictional offline DNS messages, local bounded parsing and chosen padding policies. Length figures describe DNS messages before transport overhead. No DNS traffic, encryption, anonymity measurement or production protocol stack is implemented.
Read the RFC section ↗