2017-01-18
Exim, IPv6, and hosts that MX to localhost
For some time now, Exim on our external MX gateway has been logging messages like the following:
2017-01-17 14:14:55 H=... [...] sender verify defer for <qifgukejapwgau@azusa.us>: lowest numbered MX record points to local host
On the one hand, this is fair enough, because at the moment the MX
entry for azusa.us
is indeed:
azusa.us. 3600 IN MX 0 localhost.
On the other hand, Exim has a router option that is intended to
deal with this, called ignore_target_hosts
; it lets you list
any number of IP addresses which are supposed to be ignored if they
show up in the process of looking up things. This allows you to
ignore not just people who list MXs that resolve to 127.0.0.1 but
also people who, say, list RFC 1918 IP addresses in public DNS; your Exim can laugh at their attempts to
use these names as MAIL FROM
s on the public Internet.
We have had a ignore_target_hosts
setting for years:
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 255.255.255.255 : 169.254.0.0/16
(We would like to ignore the remaining RFC 1918 address space, but we actually use it ourselves and disentangling the resulting mess has so far been too complicated.)
So our Exim configuration certainly looked like it should have
rejected that azusa.us
MX entry instead of temporarily deferring
it as, basically, a DNS configuration error. It MX'd to localhost
and Exim even recognized that it did, since it was reporting just
that. After a bunch of flailing around, I worked out what was going
on: Exim was looking up the IPv6 address of localhost.
as well
as the IPv4 one, and the IPv6 localhost address was not ignored.
So when Exim saw this MX entry it did both A and AAAA lookups on
localhost.
, discarded the 127.0.0.1 A record because it matched
an entry in ignore_target_hosts
, accepted the ::1 AAAA record
because it didn't, and then reported the 'lowest numbered MX record
points to local host' error. The fix for this is straightforward;
we added ::1 to ignore_target_hosts
.
(I suspect that this started happening when we replaced Bind on
our OpenBSD internal resolvers with Unbound,
as Unbound internally provides A and AAAA records for localhost.
by default. Before then, all queries for localhost.
might have
failed entirely. I have no opinion on whether providing a localhost.
name in DNS is a good idea or not, because I haven't looked into
the reasons for why this was done.)
This is an especially interesting issue for me partly because it's yet another illustration of the ripple of changes that adding IPv6 causes. We don't even use IPv6 (yet), but here we are being affected by it and having to include it in our configurations none the less.