Subject: [DNSOP] qmail misuses the DNS standards

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Mar 2015 17:58:40 -0700

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