Since the inception of the DNS protocol, there has been a special query type called ‘ANY’. When a query for that type was received, a DNS server, as the responder, was to return any (or all) the records for a name it had on hand. While that may seem quite clear, it isn’t.
In the DNS there are different kinds of responders that can be categorized in several ways. One way is to classify them as either authoritative servers or caching servers (or, yikes, both).
If an ANY query is made of an authoritative server, it’s pretty certain that all of the records for a name would be in the response. If the same query is made of a caching server, the response would consist of just what was in the cache — if anything was there already — which might not be all of the possible records offered by an authoritative server.
The first problem with this set of actions is that it confuses many application developers who use ANY to get, for example, both the IPv4 and IPv6 address records for a host. (The DNS uses different records for each.) An ANY query to a cache might get just the IPv4 address and not the IPv6 address — there is no way to know.
The second problem is that the ANY query becomes a tool for anti-social behaviour. One class of abuse is a flooding attack, where large amounts of useless and undesired traffic is sent to a service. The ANY query, with its large response sizes, assists in causing traffic floods making the ANY query a tool for bad.
Conversely, the best reason for having the ANY query has dissipated. It was once a tool for DNS administrators to quickly see what was at a name. There are other, better ways, to do this and in fact, with the onset of anycast, perhaps not as useful.
Given this state of affairs, protocol developers favoured a retirement of the ANY query. But in the DNS, with the desire for backwards compatibility, an all-out retirement is out of the question. The IETF issued ‘Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY’ (RFC 8482) providing a way for a responder to reply to ANY queries in a ‘soft retirement’ kind of way; not by eliminating them but by deflecting them.
The trouble is, the document lacks a single, clear, deterministic means for a responder to indicate that it doesn’t support ANY responses. In fact, the document includes many possible ways a server can indicate this. “Many possible ways” is not an endearing quality when one has to write the software that interprets the result.
Why is this a problem?
The problem lays not in the software or the protocol but in the reality of running the DNS.
DNS service delivery is expanding. Without a commensurate growth in experienced people to operate the service, we need to include less experienced people in operations centres. Unless we spend more to train more DNS experts to offset this, the protocol and the system around it has to evolve to be simpler and less complex. Having “many possible ways” to respond in the protocol is not a means to this end.
I gave a talk on this slightly-obscure topic twice in February, first at FOSDEM 2020 in the DNS Developer Room (1 February 2020) and then second at DNS-OARC’s 32nd workshop (8 February 2020).
The reactions to the talk included software developers agreeing that this complicates DNS code. Others responded that the document really doesn’t change anything as the net result is that the ANY query is no worse off. Back-to-back comments said the document simplified implementations by removing the need to find all the records, and then, that the document obsoleted parts of implementations.
It’s clear that one’s take on the approach to retiring features of the DNS protocol is not agreed upon. Beyond the ANY query, there are other features that ought to be retired, but there’s reluctance to do so because we want backwards compatibility.
As far as applications making use of the ANY query, it is true that workarounds exist, but they do take quite a bit of expertise to pull off. The motivating experiment that led me to see the impact of ‘many possible ways’ included polling the top of each TLD for all of its records. A growing number of TLDs are not fully responding to ANY queries, which has had an impact on the length of time the poll takes.
A suggestion to rewrite the poll to use parallel execution paths and individual queries was made during the lead-up to the talks. After the talks were made, I implemented these suggestions and the suggestions were correct: parallelism conquered the work. However, the resulting code base is much more complicated, in a way demonstrating there has been a shift of where ‘the work’ is done. This is ‘just’ a research project and not something critical, but it provides a discrete example of how ‘many possible ways’ results in more complicated systems.
The upshot is that it would be great if there is a cleanup of the DNS protocol and system that resulted in a simpler, clearer, and easier to manage and operate system. The way the ANY response is handled has not simplified the system. In fact, it has made it a bit harder. Perhaps this doesn’t matter much, but it is a concerning trend. And that is the obscure point of the talk.
Edward Lewis is a Senior Technologist in ICANN’s Office of the CTO.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.