TL;DR: I've read DJB's messages about qmail's clever design. IMHO, qmail's use of DNS has always optimized for the wrong thing.
What it should be optimizing, is client queries to the recursive server. Fixing that should be relatively simple, and would happen to make the CloudFlare deprecation of "*" QTYPE a moot point. I encourage DJB to follow this course of action, for the benefit of qmail users, if for no other reason. The rest of this message goes into why I think that was the wrong optimization choice. The point of the recursive, caching name server, is to do the heavy lifting, and all the iteration work. This is particularly true of CNAME chains. There are two query types which do not trigger additional processing by the recursive resolver, when a CNAME is encountered: QTYPE=CNAME, and QTYPE=ANY. Furthermore, if a CNAME chain involves multiple links on the same authority server, the server has the opportunity to return all of the contiguous links for which it is authoritative, in one single answer, rather than requiring multiple round-trips (which is the case if the QTYPE is ANY). Making an initial query for MX to a recursive resolver, with RD=1, will return the entire CNAME chain. It does not matter whether none, some, or all of the entries in that chain were in the cache before the query. It also does not matter whether the final query returns an MX answer, or "no data". In a world where DNSSEC signed zones exist, a query to a name for an MX, where other RRTYPEs exist but no MX exists, the answer will include a "proof" which signals all RRTYPEs at that name. This includes information about the presence or absence of A and AAAA types. The client (i.e. qmail), if upgraded to use DNSSEC-aware client DNS calls, would be able to further optimize its queries (A vs AAAA vs both A & AAAA) on the basis of the MX not existing. And, in some cases, if the MX does exist, the cache may return A/AAAA records in the additional section. Even if it does not, the latency difference between 1 query and 2 queries to a hot cache is insignificant (i.e. with both positive and negative cache entries) compared to the latency of having the cache forward the query to the authority server, even once, in the cold cache situation. Optimizing for performance against a cold cache is frankly as brain-damaged as optimizing for LAN performance at the expense of WAN performance, such as was done by certain versions of a certain desktop OS. Optimizing for a hot cache means not using the QTYPE=ANY. QED. IMHO. Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
