On Wed, 26 Mar 2008, Jim Fenton wrote:
I keep trying to understand why the SMTP use of AAAA records should be any
different than its use of A records. Haven't heard a solid explanation,
nevermind seen consensus forming around it.
It seems there are two ways of looking at this:
(1) AAAA records in the IPv6 world should do exactly same things as A
records in the IPv4 world, so SMTP should look for an AAAA record in the
absence of an MX record, just as A records are used in the absence of MX
(2) Although some SMTP servers will continue to be found through A
records for legacy reasons, there is no longer a good reason for any new
server not to have a published MX record. SMTP clients (senders) will,
of course, need to continue to look up A records, but since there is
currently no significant use of AAAA records for email routing, we
should not perpetuate this legacy in IPv6 as it is in IPv4.
These are both reasonable positions, but I'm in camp (2). The
additional use of AAAA records for email address resolution would add
complexity to at least some implementations and test cases, and it
something that should never be needed: v6 mail handlers will just
publish MX records. There is probably a small DNS efficiency argument
as well, especially if the MX, A, and AAAA requests are not made together.
I agree with Jim's characterization and IMHO both positions are
I also prefer (2) because I don't think the original "A fallback" was
meant to stay there very long and we just never got around to
deprecating that feature. If you ask a random sampling of postmasters
and DNS domain owners, I doubt many would even remember right off the
bat that such a fallback exists. Further, given that the feature in
and of itself does not provide any additional value, I don't see why
the practise should be propagated to IPv6.
But if the majority were to favour (1), that would be fine with me as
Additionally I believe this is not an issue we as the IETF should get
stuck at for a longer period. Reaching closure, whichever decision it
is, in the timescale of a couple of months, is IMHO better than a very
strong consensus on the approach.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IETF mailing list