Summary

  • RFC 8482 offered optional ways to answer ANY with less data. A nonempty RRset could enter an ordinary cache and reduce repeated questions without a new client-wide refusal mechanism.
  • Choosing a few complete RRsets is not a promise to enumerate every available type. Nor is a minimal positive answer a negative statement about the types it omits.
  • Synthetic HINFO made the answer familiar to existing software, but could mask genuine HINFO in a cache. Its TTL traded present query reduction against future freedom to change the policy.

A code the client did not understand

The problem with a new refusal was not simply that an old client would display an unfamiliar number. According to RFC 8482, resolvers encountering the proposed unfamiliar response code would try other available authoritative servers. Work that one responder hoped to avoid could become work elsewhere.

The alternative supplied a nonempty set of resource records. An unmodified client could cache it. The same name need not provoke another ANY transaction immediately. Instead of teaching every resolver a new reason to stop, the responder used a familiar consequence of receiving an answer.

That comparison is the RFC's explanation of its design, not a universal law that every DNS error causes identical retries. The distinction matters because the mechanism depends on existing behaviour, not on a newly imposed guarantee about all clients.

Published in January 2019, RFC 8482 is a Standards Track document updating RFC 1034 and RFC 1035. Its specified behaviour is optional for initiators and responders. It did not abolish ANY or require every server to manufacture HINFO. It described ways an operator could reduce the scope of an answer while remaining intelligible to software already in service.

The question had legitimate users

ANY could help with debugging and examining a server's state for a particular name. Applications also used it as a shortcut, hoping to obtain records such as MX, A and AAAA in one exchange. These were not inherently hostile activities.

But the shortcut carried an assumption. An application could not rely on the query reaching an authoritative server and returning every existing RRset. RFC 8482 tells implementers who make that assumption to provide a fallback. Saving questions does not relieve an application of obtaining the information its own function requires.

Responders had reasons to limit the work. Some implementations incurred extra processing in assembling broad answers. Operators also had concerns about data collection. And a small UDP query capable of eliciting a much larger response was attractive for reflection amplification using a forged source address.

Smaller answers could reduce that attraction. This is not an estimate of present attack volumes or a measured amplification ratio. It does not classify every ANY query as an attack. Nor does limiting one convenient question make other publicly available DNS information confidential.

The design therefore had to accommodate two facts at once: some questions were useful, and answering them broadly was not costless. A cacheable minimum offered a response policy between assuming unlimited enumeration and devising a refusal that existing clients might pursue elsewhere.

ANY was a type, not an inventory command

In November 1987, RFC 1035 represented query type 255 with an asterisk. Implementations commonly call it ANY. The current IANA DNS parameters registry describes that value as requesting some or all records available at the server. HINFO remains type 13, for host information.

Registration supplies identifiers and meanings. It is not evidence of how many present-day servers implement any particular answer policy.

The separate fields of a DNS question also constrain the meaning of “any.” RFC 1034, issued in the same month as RFC 1035, distinguishes the queried name, type and class. ANY in QTYPE is not a wildcard in QNAME, and it is not AXFR zone transfer. Asking broadly about one name does not enumerate all names in a zone.

The response algorithm distinguishes zone data from cached data. A cache can answer from matching records it has available. It is not thereby promising a newly assembled survey of every type that authoritative servers might possess. The cache was already a reason to distrust an application's unstated expectation of exhaustive collection.

RFC 8482's relevant responder methods concern an existing QNAME, class IN and query type ANY. Except for the specified modifications, normal algorithms continue to apply. The policy is not permission to invent an existing name where none exists, or to describe an existing name as NXDOMAIN merely because the responder wants to avoid a broad answer.

A complete set could be an incomplete selection

One permitted method returns a single available RRset, or a small subset of the available RRsets owned by the queried name. Section 4.1 explicitly says there is no signal indicating that this selection is incomplete. An omitted TXT set cannot be treated as proof that the name has no TXT data.

Selection takes place between sets, not arbitrarily between members of one set. RFC 2181, published in July 1997, defines an RRset by the same owner name, class and type, with potentially differing record data. If an address RRset contains several records, returning one convenient member is not equivalent to returning the set intact.

The ordinary requirements for RRset completeness still matter. If a required set cannot fit in its entirety, truncation rules become relevant. Choosing fewer types is a different operation from cutting a required set short.

The TC bit does not erase that distinction. Its absence is not a certificate that every available type has been listed. A client can receive a complete selected RRset without receiving a complete inventory of the name. Reading a transport or message condition as an inventory promise adds information the answer does not contain.

A host-information record that described no processor

A second method synthesizes HINFO when no CNAME is present at the matching owner name. RFC 8482 recommends a single HINFO record with RFC8482 as its CPU string and an empty OS string. This does not require permanently inserting that record into the zone's stored data.

The borrowed format is older than the new purpose. RFC 1035 gives HINFO two character strings, CPU and OS. It describes general host information and identifies procedures such as FTP's treatment of similar machines and operating systems as a use. An old record shape could now carry an answer whose principal operational value was that it could be retained.

For a record explicitly constructed by this method, the CPU string is not an observed processor architecture. The empty OS is still a zero-length character string, not an absent second field or a finding that the host has no operating system.

But a receiver cannot reliably identify the origin of arbitrary HINFO solely from those values. Section 4.2 cautions against concluding that this specification was used and applying special processing on that assumption. Recognizable text is not an authenticated policy flag.

The document separately permits ordinary caching. It also allows an initiator with matching cached HINFO of the described kind to suppress outgoing ANY queries, or to answer from cache as usual. Both points must survive the explanation: cached information can be useful without its contents becoming conclusive proof of how it was generated.

The old meaning could still have an owner

Borrowing HINFO had a concrete side effect. Once a synthetic record was cached, it could mask genuine HINFO in the zone, affecting a later direct HINFO query. An answer designed for one question could influence a subsequent question of another type.

RFC 8482 warns operators relying on conventional HINFO to choose the existing-RRset method or another record type. The observation that HINFO was rarely used, drawn from the authors' DNS observations and reported in 2019, is not proof that nobody depended on it. It is also not a new adoption census for 2026.

This was a semantic cost, not simply a few bytes of overhead. The familiar format made deployment easier precisely because existing caches would treat it as ordinary data. That same familiarity could put it in the way of a legitimate use of the original type.

There is a third option: guess the initiator's needs and return present CNAME, MX, A or AAAA sets while suppressing other types, such as TXT or DNSKEY. That answer can be larger. It is a permitted heuristic, not evidence that a server has correctly inferred an application's intention.

The lifetime of a decision

The synthetic record's TTL should be configurable. It needs to be long enough to reduce frequent repeat ANY queries from the same initiator for the same name. Yet a long lifetime can impede future changes to the operator's ANY policy. RFC 8482 states the tradeoff without prescribing a single number for every service.

RFC 2181 makes TTL a maximum retention time, not an obligation to retain a record for precisely that interval. Implementations may impose lower limits. An operator therefore cannot infer globally synchronized expiry from the value it sends, nor assume that changing the authoritative server instantly purges remote copies.

The policy has two moments: the responder's decision now, and the point at which a particular cache ceases to answer from an earlier decision. They need not coincide. Query reduction is obtained partly by allowing the earlier answer to keep doing work after its source has moved on.

Neither absence nor signature supplied a missing list

Negative DNS answers have their own rules. RFC 2308, published in March 1998, distinguishes NXDOMAIN name errors from the absence of requested-type data inferred from a suitable NOERROR response. Negative caching depends on response contents, SOA conditions and the scope of the saved result.

A nonempty selected or synthetic ANY answer is not, by itself, a negative assertion about all omitted types. A monitoring system that marks every absent type as nonexistent has made an additional inference. The sparse response did not authorize it.

Signatures do not fill that gap either. RFC 8482 requires appropriate RRSIGs for selected RRsets from a signed zone. In the synthetic-HINFO method, a valid RRSIG is required when DO is set and the responder knows the zone is signed; with DO clear, the signature should be omitted. The best-guess method also has signature requirements for a signed zone when DO is set. These branches should not be flattened into a claim that every answer must carry a signature, or that minimization excuses all signatures.

RFC 3225, from December 2001, supplies a useful limit on the flag itself: DO in the EDNS OPT flags expresses the ability to accept DNSSEC security records. It does not say validation has already occurred. That historical definition is relevant here; the document's older SIG, KEY and NXT procedures are not being presented as current RRSIG instructions.

Authentication of a returned RRset is not enumeration of omitted RRsets. The answer can satisfy its signature requirements and still lack types an application hoped to collect.

Nor does switching transport supply an unconditional escape. RFC 8482 permits different policies over UDP and TCP, including conventional ANY over TCP and minimal ANY over UDP. That is an allowed example, not a mandatory fallback that guarantees a comprehensive result. The operator's policy, the question and the cache path all remain part of the explanation.