commit b05ec6cbdacdf40d6c75326394461e22b7f8ab20
parent 9ef349af5c83f54b4d62fdcc90e9603aa55c149d
Author: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com>
Date: Fri, 12 Jul 2019 23:34:52 -0600
Apply Jonathan de Boyne Pollard's any-to-cname patch.
modifies the behaviour of qmail-remote to remove the workaround
that Dan Bernstein added on 1996-10-03 to work around a bug in
BIND versions earlier than version 4.9.4.
Applying this patch incurs a risk, but yields a benefit. It is
published in order to allow others to experiment with removing
the workaround.
The risk is twofold:
* qmail-remote will not be able to relay any mail if one's own
proxy DNS server is such a version of BIND. This is trivially
overcome by replacing such an old version of BIND either with a
new version of BIND that doesn't have the problem or with some
other proxy DNS server software entirely (such as dnscache).
* qmail-remote will not be able to relay mail to domains whose
content DNS servers use such versions of BIND, because the
"CNAME" resource record lookup will fail. To gauge the level of
this risk, notice that Dan's own 2002-12-17 survey of content DNS
servers reports a mere 2% of the "*.com." content DNS servers as
employing BIND version 4 (but doesn't report how many of that 2%
employ BIND 4 versions earlier than 4.9.4).
The benefit of this patch is that it reduces DNS query traffic
and proxy DNS server cache load.
* Without it, qmail-remote issues "ANY" queries. Some proxy DNS
server softwares (albeit not dnscache) pass such queries through
directly to the back end, meaning that every query issued by
qmail-remote will result in a back-end query to a content DNS
server, no matter if the necessary information is already cached.
Moreover: The results of such a query, which are often a large
collection of resource record sets of various types, are cached
in the proxy DNS server's cache, even though almost none of them
will be used. A caching proxy DNS server dedicated to serving
qmail will end up with all sorts of cruft in its cache that isn't
actually relevant to mail transportation, taking up space that
could be better put to use caching those resource record sets
that are relevant.
* With it, qmail-remote issues "CNAME" queries. All of the mainstream
proxy DNS server softwares in popular use (apart from dnscache,
because it has problems in this regard) don't pass such queries
directly through, and will answer them from their caches without
issuing a back-end query at all if the data are already there and
still current. Moreover: A caching proxy DNS server dedicated to
serving qmail will not have its cache cluttered with irrelevant
data.
Diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dns.c b/dns.c
@@ -197,7 +197,7 @@ stralloc *sa;
if (!sa->len) return loop;
if (sa->s[sa->len - 1] == ']') return loop;
if (sa->s[sa->len - 1] == '.') { --sa->len; continue; }
- switch(resolve(sa,T_ANY))
+ switch(resolve(sa,T_CNAME))
{
case DNS_MEM: return DNS_MEM;
case DNS_SOFT: return DNS_SOFT;
