Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
updates
Extracted elements (22)
A new RCODE approach for signaling that ANY queries are unsupported was rejected because resolvers receiving an unknown RCODE would resend the same query to all available authoritative servers rather than suppress future ANY queries for the same QNAME. Returning a non-empty RRset instead gives resolvers something to cache, effectively suppressing repeat queries.
ANY queries are frequently exploited for DNS amplification attacks using spoofed UDP source addresses; a small query can elicit a large response. Providing smaller responses makes authoritative servers less attractive as amplifiers. Zone mining is also a motivation for restricting full ANY responses.
Returning a subset of available RRsets in response to ANY is legitimate and consistent with RFC 1035, which can be read as meaning ANY does not always mean ALL (Section 3.2.3 of RFC 1035). The TC bit SHOULD NOT be set in such responses to indicate this is not a complete answer.
ANY queries used as an attempt to retrieve all RRsets (e.g., MX, A, AAAA for a mail domain) in a single query may not work as expected with implementations following this document. Implementers relying on ANY for this purpose SHOULD include a fallback mechanism.
The synthesized HINFO RRset in an ANY response, once cached by the initiator, might suppress subsequent queries from that initiator with QTYPE=HINFO, effectively masking any real HINFO RRset present in the zone. Operators serving zones that rely on HINFO SHOULD use the single-RRset method or select another RRtype for the synthesized response.
A DNS initiator MAY suppress future queries with QTYPE=ANY for a QNAME when its local cache contains a matching HINFO resource record with the CPU field set as described in Section 4. Alternatively, the initiator MAY respond to such queries from its local cache in the usual way.
A DNS initiator that receives an HINFO or single-RRset response to an ANY query MAY cache the response normally. Such cached records SHOULD be retained following normal caching semantics, as with any other DNS response.
A DNS responder MAY behave differently when processing ANY queries received over different transports — for example, providing a conventional ANY response over TCP while using a reduced response mechanism for queries received over UDP. Implementers MAY provide configuration options for this.
A DNS responder that receives an ANY query MAY decline to provide a conventional ANY response or MAY instead send a response with a single RRset (or a larger subset of available RRsets) in the answer section.
A system that receives an HINFO response SHOULD NOT infer that the response was generated according to this specification and apply special processing, because it is not possible to tell with certainty whether the HINFO RRset was synthesized. Systems SHOULD NOT rely on the specific HINFO RDATA values to distinguish synthesized from non-synthesized records.
Except as described in Section 4, the DNS responder MUST follow the standard algorithms when constructing a response to an ANY query.
If the DNS query includes DO=1 and the QNAME corresponds to a signed zone known to the responder, a valid RRSIG for the RRsets in the answer (or authority if answer is empty) section MUST be returned. If DO=0, the RRSIG SHOULD be omitted.
If the zone is signed, appropriate RRSIG records MUST be included in the answer when returning a subset of RRsets in response to an ANY query.
Implementation of the guidance provided by this document is OPTIONAL for both DNS initiators and responders.
The TC bit SHOULD NOT be set in the response when returning a subset of available RRsets for an ANY query, indicating that the response is intentionally incomplete rather than truncated due to transport limitations.
The TTL for the synthesized HINFO RRset SHOULD be chosen to be large enough to suppress frequent subsequent ANY queries from the same initiator with the same QNAME, and SHOULD be configurable by the operator according to local policy.
Where multiple RRsets exist at the QNAME, the responder SHOULD choose a small subset of those available to reduce the amplification potential of the response.
A 'best guess' mode returns all RRsets of RRTYPE CNAME, MX, A, and AAAA present at the owner name while suppressing others such as TXT and DNSKEY. This heuristic satisfies common application needs but produces larger responses than the subset or synthesized-HINFO approaches.
If there is no CNAME at the QNAME owner name, the response to an ANY query MAY contain a synthesized HINFO resource record. The CPU field of the HINFO RDATA SHOULD be set to "RFC8482" and the OS field SHOULD be set to the null string to minimize response size.
IANA updated the entry for TYPE * (value 255) in the "Resource Record (RR) TYPEs" registry. The meaning was updated to "A request for some or all records the server has available", and RFC 8482 was added as a reference alongside RFC 1035 and RFC 6895.
QTYPE=ANY queries are a well-known vector for DNS reflection/amplification attacks: a small spoofed UDP query can elicit a large response. Implementing minimal ANY responses reduces the amplification factor and makes authoritative servers less attractive as attack amplifiers.
The optional behavior described in this document to reduce the size of responses to ANY queries is compatible with DNSSEC use by both initiator and responder, provided RRSIG records are correctly included when required (DO=1 or zone is signed).