I wasn't there, so I hope people who were will correct me if I'm
wrong.
RFC 821 came out in 1982. It makes only passing references to DNS,
because at the time the transition from HOSTS.TXT to the DNS had not
yet started. RFC 883, the first description of the DNS came out over
a year later in late 1983. It described the now abandoned MD and MF
records. According to RFCs 897 and 921, the transition to DNS started
in 1983, but HOSTS.TXT didn't go away until the end of 1985.
In January 1986, RFC 973 and 974 deprecated MD and MF records,
replaced them with MX, and defined the MX lookup with fallback to A.
While rereading 974, I note that it also recommends that clients do a
WKS lookup on each MX host to see if it actually supports SMTP and
discard the MX entry if it doesn't, but as far as I can tell, nobody
ever did that. Too bad.
No, spme people implemented it, but the problem was there were too many other
people who didn't bother setting up WKS records. Doing this check caused way
more problems than it solved.
So this means that SMTP had been in use for at least a year using
HOSTS.TXT, and then another couple of years using A, MD, and MF,
before MX came along, and I get the impression that MD and MF were
clunky enough that a most people just used the A record. Under the
circumstances, MX without fallback to A wouldn't have worked because
of the substantial installed base of mail servers using A records.
Yes, that's more or less the case.
Now fast forward 20 years. How many domains are there on the Internet
that accept mail from the outside world with only AAAA records?
I would assume none, but this is completely beside the point. We're trying to
design something here that is interoperable and which will last through to a
point where it is feasible to run a IPv6-only host. We have no way of knowing
for sure what that world is going to look like so we need to be very careful
when making fundamental architectural changes.
This also ignores the issue of what is the right thing to do in the
transitional case where there's no MX record but a mixture of A and AAAA
records. Only falling back to the A record subset seems, well, wrong.
Considering that most of the net still can't connect to IPv6 hosts,
it's rather unlikely that there are any at all other than perhaps a
few test setups. The issues of installed base that mattered in 1986
just don't exist now.
There are in fact plenty of A-record-only mail-receiving hosts out there, but
let's ignore that for the moment. The gap in your reasoning is that you're
assuming that just because the issues that led to this decision being made in
the past are no longer there no other issues have arisen to take their place.
The transition to v6 is going to involve, among other things,
renumbering nets from v4 into v6 address space, and then adding AAAA
records for all the hosts that have A records. Some of those hosts
are mail servers. Is it really an unreasonable burden to ask people
who are redoing their DNS anyway to add MX records for the small
number of mail hosts that don't already have them?
The answer is we don't know. What we do know is that it is currently not
uncommon for there to be problems setting up MXes. Mayvbe Keith is right and
this will change going forward - maybe, as IPv6 deploys and the need to
configure AAAA records, the widespread ability to set up MX and SRV will also
appear. (And wouldn't it be great if there was finally a way to get PTR records
set properly?)
But I've seen way too many examples of widespread cluelessness in various
service oferrings from people who really should know better to want to bet on
this being what happens.
Maybe somewhere
there is DNS management software so wierdly broken that it can install
AAAA records but not MX, but even if there is, that doesn't seem like
much of an argument compared to the advantages laid out in my last
message of having hosts default to not being mail servers.
I assume you're referring to the problem of mail sitting in the queues waitinfg
to be delivered to a system that's never going to accept it. I'm afraid I don't
buy your reasoning on this one either.
10 years or so ago this used to be a real issue - we used to get customer
complaints all the time about stuck mail to some router, or to lab PCs, or
whatever. Thinking back I would say this sort of thing was responsible for a
considerable number of support calls. (And interestly, the option of using an
MX record to redirect traffic to a stub server was rarely if ever selected as a
solution, often due to issue getting the necessary records installed.)
Fast forward to today, and I cannot recall a single such complaint in the last
couple of years. And this is in spite what is surely a huge drop in the overall
percentage of hosts able to receive mail.
Now, I'l be the first to admit I don't know why this has happened. If I had to
guess I'd say it's due to a bunch of different factors: Decreased use of host
names in email addresses as opposed to more general domains (e.g.,
ned(_dot_)freed(_at_)sun(_dot_)com vs.
ned(_dot_)freed(_at_)sam(_dot_)west(_dot_)sun(_dot_)com), increased
centralization of
email services bringing with it more consistent configuration, people caring
less about a few stuck messages in a queue full of blow-back spam, increased
used of wildcard MXes to redirect all mail for a given domain to a single
server, and spammers, faced with widespread use of reverse address checks,
abandoning the use of such addreses. But regardless of the reason the fact
remains that this just isn't the support issue it used to be.
Now, of course all this is anecdotal evidence at best, with all that implies.
I certainly don't have any statistically significant evidence here. But
apparently neither does anybody else (if they do they aren't talking about it),
so anecdotal stuff is likely the best we're going to get. And the bottom line,
for me at least, is that my own experience is that setting up MX records can be
problematic and A record fallback isn't a major source of operational
difficulty currently. Additionally, we have specifications (informational ones
to be sure, but specifications nonetheless) that say the fallback should be
done in the AAAA case, so this is how current implementations are likely to
work.
So I believe the correct course going forward is to have the same fallback
rules for AAAA that we do for A. Having said all this, it certainly isn't a
showstopper for me if this goes the other way, if for no other reason than the
fact that we'll have plenty of time to fix this if whatever decision we make
turns out to be wrong. The only outcome that is a showstopper for me is for
this issue to remain unresolved.
Ned