Subscribe to receive notifications of new posts:

Deprecating the DNS ANY meta-query type

03/06/2015

3 min read

DNS, one of the oldest technologies running the Internet, keeps evolving. There is a constant stream of new developments, from DNSSEC, through DNS-over-TLS, to a plentiful supply of fresh EDNS extensions.

penguins
CC BY-ND 2.0 image by Antarctica Bound

New DNS Resource Records types are being added all the time. As the Internet evolves, new RR’s gain traction while the usage of some old record types decreases. Did you know you can use DNS to express the location of your server on the planet's surface?

Today, we are announcing that we are deprecating the DNS ANY meta-query. In a few weeks we'll be responding to those queries with rcode 4 / Not Implemented.

“ANY” is one of the special “magic” types in DNS. Instead of being a query for a single type like A , AAAA or MX, ANY retrieves all the available types for a given name. Over the years there have been many arguments over the semantics of ANY with some people arguing it really means ALL. Answers to ANY queries are among the biggest that DNS servers give out. The original reason for adding the ANY to DNS was to aid in debugging and testing and there is no real reason why a normal application would ever issue a ANY query.

ANY is not the only operation that lists records in DNS. The AXFR operation could be used to transfer all data for a DNS zone between two servers. A frequently recommended option is to restrict the scope of IP addresses that can perform this action and return REFUSED or drop the query for all others. The reason for this is security: people can easily learn the entire DNS zone with one command. In many case it is not okay for anyone to list all entries in your DNS zone. We believe the same holds for ANY and that an authoritative server should be allowed to refuse to answer it.

ANY queries are not widely used by any real world software. We aware of only two programs that issue ANY queries:

We strongly believe using ANY query type in both those cases was a mistake and should not be endorsed.

The usage of ANY by a Firefox caught us by surprise and increased the ANY queries load 8 fold:

ANY usage

Since Firefox reverted the use of ANY we expect this load to drop back to the level of a background noise. Unfortunately the most common users of ANY queries in practice are people trying to perform DNS reflection attacks, exploiting the unusual length of the ANY responses.

Disabling or throttling ANY is not unprecedented. UltraDNS disabled them briefly in 2013 with little impact visible to Internet users. A number of operators have refused to answer ANY queries over UDP, forcing the traffic to TCP, with the side effect that forged ANY queries are not amplified. Similarly a number of DNS operators use QoS techniques to limit how many ANY questions they will answer per second.

Attempting to handle ANY queries creates enormous complexity in our DNS server code base. It's almost impossible to generate a proper response, anyway. Consider load-balancing, geoip, CNAME flattening features, and on-the-fly answer generation.

Due to the lack of justified uses and to avoid code complexity, we have decided to completely phase out attempting to answer meaningfully the ANY qtype. In the near future we plan on returning NOTIMP return code in response to all ANY queries to our authoritative servers. This is the most truthful answer we can give as the code to process ANY type will be removed.

If you are aware of any software that relies solely on ANY queries, now is the time to fix it.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
ReliabilityDNSDNSSEC

Follow on X

Marek Majkowski|@majek04
Cloudflare|@cloudflare

Related posts