Summary

  • An August 2026 individual Internet-Draft recommends that DNS servers normally answer QTYPE ANY with NOTIMP, while allowing a specific local reason to preserve older or minimal-response behaviour. The draft is not an RFC or IETF consensus.
  • Operators should retire ANY purpose by purpose: identify who sends it and why, provide explicit RRtype queries or a bounded local exception, test the replacement, and make every exception expire. An optional Extended DNS Error can explain a refusal, but it cannot prove that a dependency has migrated.

The quickest way to misunderstand DNS ANY is to read its name as a promise. A client asks for “ANY”; a server appears to be asked for everything. But the protocol history never produced one stable operational meaning for that exchange. What a server can return depends on where the question lands, what the responder knows, what it has cached and which interpretation it implements. At a delegation, even the boundary of the relevant data is contested. A recursive resolver's cache is not the authoritative zone. A response therefore says as much about the answering system and its momentary state as it does about the name.

That ambiguity is the starting point of draft-jabley-dnsop-no-longer-support-any-00, published on 6 August 2026. The individual draft recommends that DNS servers return RCODE 4, NOTIMP, for ANY unless a particular local reason justifies continuing either the historical RFC 1034/1035 interpretation or the minimal-answer approach permitted by RFC 8482. It also proposes an Extended DNS Error that could tell a client that ANY queries are unsupported on that nameserver.

The document is an active individual Internet-Draft. Datatracker assigns it no RFC stream and records only that an Internet-Draft exists. Its header says Standards Track is intended, but that is an author's destination, not evidence of IETF adoption, DNSOP consensus or a future RFC. The distinction matters because operators can study the proposal now without pretending that a collective standards decision has already been made.

One query code conceals several jobs

Operational dependencies do not organise themselves around standards terminology. A support engineer may use ANY as a quick look at records a server chooses to expose. A monitoring script may have inherited it from a period when responses were more expansive. A library may treat it as discovery. A diagnostic tool may use the answer shape to infer which responder it reached. An attacker may seek a large response for reflection and amplification. These are different purposes sharing one packet field.

They also have different replacement paths. A tool looking for mail-routing information can ask for MX. A check for nameserver delegation can ask for NS and, where needed, resolve address records deliberately. A service-discovery client should use the RRtypes defined by its own protocol rather than hope that an ANY answer contains a useful set. An operator investigating a cache needs an authenticated, local diagnostic surface; an arbitrary remote ANY response was never a reliable cache inventory.

A legacy binary that cannot be changed may need a temporary exception, but that is an asset-management problem, not a reason to preserve global ambiguity indefinitely.

Security pressure is real. RFC 5358 described how open recursive servers can be abused for reflected denial of service. RFC 8482 explains that large ANY answers have been attractive in amplification attacks and can consume server resources. Larger DNS messages also interact badly with UDP fragmentation; TCP fallback changes the cost profile rather than making capacity free. Yet “disable ANY” is not a complete anti-amplification policy. Other query and response combinations can still produce amplification, and authoritative capacity, response-rate controls, source-address validation and recursive-service exposure remain separate concerns.

The governance mistake is to let the abuse case erase the legitimate dependency question. A server-side default can be correct while a rollout around it is careless. If a change turns a nightly check into NOTIMP, the new response proves only that this server refused this query. It does not tell the operator which application sent it, what fact it wanted, whether that fact can be obtained through an explicit query, or whether the application will fail open, fail closed or silently continue with stale state.

Build a purpose register before changing the default

Before rollout, collect enough telemetry to group ANY traffic by operational purpose. That does not require permanent, indiscriminate query logging. A bounded observation window can record the receiving service, source class, authenticated tenant or internal workload where available, name class, transport, response size, recurrence and ownership signal. The objective is not to retain every name forever; it is to turn unknown traffic into a finite migration queue.

Each queue item needs a claim more precise than “uses ANY.” Record the decision the caller is trying to make. Does it need one RRset, several known RRsets, a diagnostic view of the authoritative server, or an inventory of a recursive cache? Is the caller controlled by the same organisation? Can it be upgraded? What happens when the answer is incomplete today? These questions often reveal that the old behavior was already unreliable, because ANY responses varied before the proposed change.

Then assign a disposition:

  1. Replace. Name the explicit RRtype or purpose-built interface, the client version carrying the change and the test that proves equivalent behavior.
  2. Retire. Demonstrate that no current decision consumes the result, remove the call and watch for regression.
  3. Constrain. Where a legitimate local diagnostic use remains, bind it to an authenticated or network-bounded surface rather than preserving an arbitrary public answer.
  4. Except temporarily. If an unmodifiable dependency remains, name its owner, affected population, compensating control, expiry date and shutdown condition.
  5. Unknown. Treat an unidentified recurring caller as unresolved risk. Lack of an owner is not evidence that the traffic is harmless.

This register changes the rollout conversation. The question is no longer whether an organisation “supports ANY.” It is whether every observed purpose has a tested destination. A resolver team can change the default for the clean population first, hold a narrow cohort for a justified exception and remove the exception when the last caller migrates. Public authoritative service and trusted internal diagnostics need not share one policy simply because they share software.

NOTIMP is a boundary, not a migration report

RCODE 4 has a valuable property: it makes refusal explicit at the DNS response layer. That is better than manufacturing an answer whose contents a client may overinterpret. It can also be measured. Operators can count refusals, identify concentrations and compare them with the pre-change inventory.

But the code is deliberately coarse. It does not identify the caller's intended purpose. Middleboxes, forwarders and recursive resolvers may influence what a client ultimately sees. Retries can change transport or target. Some old clients may interpret the response poorly. A monitoring dashboard that shows a falling success rate still needs an owner capable of mapping the failures back to applications.

RFC 8914's Extended DNS Error mechanism adds context without changing this basic contract. An EDE accompanies ordinary DNS processing; it does not replace the RCODE or instruct a client to ignore it. More than one EDE may be present. Forwarding or rewriting EDE information is implementation-dependent, and optional text is intended for people, not as a machine-stable control field. When a message must be shortened, that text may be among the first things discarded.

The draft's proposed unsupported-ANY EDE can therefore improve diagnosis. A human seeing the reason can distinguish an intentional policy from a generic server defect more quickly. It should not become the migration oracle. A client must not parse an English sentence to select new query types, and an operator must not count EDE delivery as proof that the abandoned purpose has a replacement. The durable evidence is in the purpose register, client deployment and outcome test.

Test the decision, not merely the response

A successful server test is easy: send ANY and observe NOTIMP. A successful transition test is harder. For every replacement, construct the decision that depended on the old exchange. Does the mail diagnostic still find the applicable MX set? Does the delegation check correctly handle glue and follow-up address lookups? Does the service client ask for every RRtype its protocol actually needs? Does the local cache-inspection tool use an authorised interface whose scope and freshness are understood?

Test negative and partial cases as well. An empty RRset, a referral, truncation, DNSSEC validation failure and a delayed TCP retry can all change what the application concludes. Compare behavior across authoritative servers, recursive resolvers and forwarding paths rather than treating them as interchangeable. Where old and new clients coexist, measure the cohorts separately so a healthy upgraded majority does not hide a small but consequential dependency.

Rollout evidence should bind five items: observed purpose, replacement, owner, population and expiry. That is enough to expose most evasions. A replacement without a population may never have reached production. A population without an owner cannot resolve a failure. An exception without an expiry becomes policy by neglect. An expiry without a shutdown test merely creates another date to extend.

Sources

  1. Current draft record
  2. Draft history
  3. Revision 00 in HTML
  4. Revision 00 in text
  5. Revision 00 source XML
  6. DNSOP charter
  7. DNSOP documents
  8. RFC 1034: Domain Names—Concepts and Facilities
  9. RFC 1035: Domain Names—Implementation and Specification
  10. RFC 6895: DNS IANA Considerations
  11. RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
  12. RFC 8914: Extended DNS Errors
  13. RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks
  14. RFC 9364: DNS Security Considerations and Operational Requirements
  15. RFC 9499: DNS Terminology
  16. RFC 7766: DNS Transport over TCP
  17. IANA Domain Name System parameters
  18. IANA Extended DNS Error Codes
  19. Lu Heng: Minimum Initial Specification, Localized Future Decision
  20. Lu Heng: The Policy Mirror