Keep transport policy, heuristics and security separate
05A responder can guess likely useful types, or use different ANY policies for User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). These are optional choices with distinct tradeoffs, not an automatic sequence.
Separate UDP reflection illustration: a forged-source request causes a response toward the named source, so smaller answers reduce the possible reflected bytes. The client is not authenticated by that reduction.
Source for this drawing: RFC 8482 · Read RFC section 4.3 ↗
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 minimal answer reduces one amplification opportunity; it does not authenticate a client or guarantee a complete answer.
- The best-guess example returns available CNAME, MX, A and AAAA RRsets while suppressing others. It can be larger than the single-set or HINFO approaches. It does not promise that every request needs those types.
- A responder MAY behave differently by transport, for example conventional ANY over TCP and minimal ANY over UDP. Configuration controls MAY expose that choice; TCP is not required to return all records.
- Except for the specified optional changes, standard DNS response construction MUST continue. Guidance here is OPTIONAL, and the TC bit SHOULD NOT be set solely to mark a deliberate subset (§7).
- Smaller ANY responses can make a server a less useful reflector in spoofed-source UDP amplification attacks (§9). This does not prove that a client is legitimate, encrypt DNS, or eliminate denial-of-service risk.
The last state depicts a separate defensive size comparison, not an actual attack test. No DNS traffic is sent. The RFC supplies no fixed byte count or mandatory amplification ratio. Appropriate DNSSEC signatures remain required for the signed, DO=1 heuristic case (§4.3).
Read the RFC section ↗