[dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards

[Michael Graff]

Packet size is harder to analyze. ANY often pulls some records that
aren't used, and if the site isn't configured carefully then ANY can
even end up falling back to TCP, costing bytes _and_ packets. On the
other hand, there are a huge number of Internet sites that don't have a
noticeable volume of unusual records and don't need TCP, and there's a
clear traffic win for every skipped query and skipped no-data response.

My guess is that with DNSSEC, this will be common, as often times the domain apex is where the email would be sent.  For my personal domain, that’s @flame.org<http://flame.org>, and weighs in at 1758 bytes to an ANY query right now.

Once this is done, the MX target then needs to be followed of course (or targets in the case of a failure to connect.)

In the following, I’m using ESND0.  If this isn’t true, we all know anything > 512 bytes as a response was a TCP hit.  I’m not as scared of TCP hits as others may be, but I do think they should be avoided when practical.

ANY comes in as 1769 with or without DNSSEC.  Had it asked for the MX directly, it would have gotten 60 bytes without DNSSEC, and 229 with.

If there was no MX record, I assume then another query would be issued for the AAAA and A records.  That’s two more queries, but both of which would be smallish in comparison to the ANY query.  The DNSSEC keys nearly always dominate ANY queries at the apex.

I’m happy we are discussing issues with ANY queries, and the fairly small number of clients that use them.  I would have to see hard numbers collected over a lot of data showing where the ANY query was actually better than following the <MX, AAAA, A> path.  Until data is collected from how people set up zones today, I’m not sure I can say one is better than the other, other than as a feeling that it might help reduce queries but I’m not sure it reduces bandwidth.

What problem are we specifically trying to solve here again?

—Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150312/0afa9f55/attachment.html>