Deprecating the DNS ANY meta-query type
blog.cloudflare.com
blog.cloudflare.com
Does no one at Cloudflare use dig?
I agree that applications shouldn't be issuing ANY queries¹ under normal circumstances but without being able to perform these queries in tools like dig, a lot of sysadmin/support staff time would be wasted. (AXFR isn't a suitable replacement in this situation because it's disabled or restricted practically everywhere these days.)
¹especially qmaild, even when fetching only MX records, the bug linked from the article will appear when there are enough MX records.
Looks like all the comments critical of Cloudflare's decision have been downvoted! I use ANY with dig (actually usually with nslookup because of my age) when I set up DNS entries and want to check what records my machine can see.
Oh. You said you are running nslookup. Most likely you are running it against a recursive server in which case ANY gives you what is in cache. So not what you want.
Edit: by the way, are you the one downvoting the posts critical of Cloudflare? I noticed you contribute to their repos on GitHub, and I didn't spot any downvotes on comments that are replies to yours.
You don't want to be using ANY queries in dig, anyway, because they already waste support-staff time. They're entirely too prone to tell you what's already in cache, which might not include the record type you wanted. (It'll probably work when talking to an authoritative server, but if you have to learn how to make things work against recursive/caching servers, it doesn't seem worth learning both methods.) If you want A records, ask for A records. If you want AAAA records or MX or TXT records, ask for AAAA or MX or TXT records. If someone else asks for A records, and then you ask for ANY records, you won't see the AAAA records, which can lead to a long wild-goose chase about who isn't supporting IPv6 properly. If someone else cached A, AAAA, and MX records, and you ask for ANY and don't see a TXT record, you can be super confused about why mail is failing a "nonexistent" SPF rule.
dig defaults to A, anyway. BIND's host command defaults to doing three queries, for A, AAAA, and MX.
Standards are good and should be followed for good reasons. They allow for both diagnostics (is that host down or are ping packets just filtered?) and the development of new protocols (nope, can’t use SCTP or anything other than TCP or UDP; they might be filtered).
It seems like Cloudflare just wants ANY to simply go away since it would make their lives easier. Well, tough cookies, this is the Internet, and here we obey the standards. The standards do not change just to make your business model easier. Make your own standard or protocol if DNS is so broken that you can’t adhere to it.
Also, this: http://dnsreactions.tumblr.com/post/113952923614/when-cloudf...
[0]: https://www.pcisecuritystandards.org/security_standards/docu...
That's a long way of saying "Be liberal in what you accept from others", which is a short way of saying "What security vulnerabilities? Everyone else on the ARPANET is a university researcher too, if they want an account on my system they can just ask."
Standards should be followed if and only if you intend to support the specific thing being standardized. Implement the smallest, most robust subset of the standard that you need to to get the job done (in a future-proof way, mind you; don't just skip out on things because a certain remote implementation doesn't require you to care, that too is terrible for security). If the standard is well-written, that's all of it, but the older internet standards by and large weren't.
Strawman.
> “don't just skip out on things because a certain remote implementation doesn't require you to care,”
Like Cloudflare wants to skip implementing ANY just because they wish it wasn’t in the standard? You don’t get to skip parts of the standard just because you claim it’s not “well-written”. If you care about standards, take part in the standardization work. If the current standards are bad, work on new replacements. You don’t get to pick and choose what to implement if a standards says it’s a MUST. If Cloudflare does this, they don’t get to call what they are offering “DNS”; it’s “CloudflareNS”, and they should get their own port number.
> 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.
This seems like a red herring. I bet there is pure business reasoning behind this decision. ANY queries are extremely useful for testing and debugging, as mentioned, and I cannot believe for one second that it's not trivial to implement something like fail2ban for ANY requests. How hard can it be to handle denying or dropping queries that are obviously an attack? Cloudflare can't handle simple reflection attack without tanking the usefulness of the query? It makes me rethink if Cloudflare is actually as good as it says on the tin.
> 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.
It isn't like they are saying no one should ever implement them, just that they aren't because of low utility in their environment vs relatively high cost.
But there are. Make the individual record type calls you need, and failing that, use a "axfr" transfers if you're permitted to based on IP security rules.
> assuming you are hosting DNS on cloudflare of course
That doesn't have much to do with it. Most of the DNS problems I run into involve 3rd parties. So the question becomes "how likely is it they're using Cloudflare?", the answer being "increasingly so."
iptables -A INPUT -p udp --dport 53 -m string --from 50 --algo bm --hex-string "|0000FF0001|" -m recent --rcheck --seconds 10 --hitcount 5 -j DROP
I might argue that resolvers should support the ANY query since they are just acting as a proxy/cache in front of the authoritative servers.