--On Thursday, December 16, 2010 10:53 PM -0800 SM
<sm(_at_)resistor(_dot_)net> wrote:
Hi John,
At 21:52 16-12-10, John R Levine wrote:
I think the answers to these questions are obvious, but
they're not obviously obvious, so:
I agree with SM's answers with one exception...
...
3a. Let's say I have these DNS records:
baz.example MX 10 mail1.baz.example
baz.example MX 20 mail2.baz.example
mail1.baz.example A 1.2.3.4
mail1.baz.example AAAA a:b::c:d
mail2.baz.example A 2.3.4.5
mail2.baz.example AAAA b:c::d:e
3b. Let's say I have these DNS records:
baz.example MX 10 mail1a.baz.example
baz.example MX 10 mail1b.baz.example
baz.example MX 20 mail2a.baz.example
baz.example MX 20 mail2b.baz.example
mail1a.baz.example A 1.2.3.4
mail1b.baz.example AAAA a:b::c:d
mail2a.baz.example A 2.3.4.5
mail2b.baz.example AAAA b:c::d:e
In both of these examples, a v4 client tries 1.2.3.4, then
2.3.4.5.
In both of these examples, a v6 client tries a:b::c:d, then
b:c::d:e
Yes.
A dual stack client tries 1.2.3.4 and a:b::c:d in either
order, then 2.3.4.5 and b:c::d:e in either order.
A dual stack client would favor the IPv6 address and try to
connect to it first.
From a mail specification standpoint, John is correct.
While a preference for IPv6 is part of various dual stack
specifications, it may not be operationally wise in all cases.
Put differently, application of a minimal change principle to
the RFC 974 / 5321 MX rules would say: "follow those rules but
do not attempt to connect to anything to which you are incapable
of connecting". That would be even more clear if we examine a
(very) slightly more complex example:
4. Let's say I have these DNS records (note that I've
made a small notational correction to the records, but
assume that John's intent was the same as what this
shows more explicitly):
baz.example. MX 10 mail1a.baz.example.
baz.example. MX 10 mail1b.baz.example.
baz.example. MX 20 mail2a.baz.example.
baz.example. MX 20 mail2b.baz.example.
baz.example. MX 10 mail1c.baz.example.
mail1a.baz.example. A 1.2.3.4
mail1b.baz.example. AAAA a:b::c:d
mail1c.baz.example. A 5.6.7.8
mail2a.baz.example. A 2.3.4.5
mail2b.baz.example. AAAA b:c::d:e
A dual-stack client selects one of 1.2.3.4, a:b::c:d, and
5.6.7.8 in any order, then, if necessary, tries one of the
remaining set in either order, then one of the remaining pair,
then the last one. Whether it tries both IPv4 addresses before
either IPv6 one, both IPv6 addresses before either IPv4 one, or
alternates is strictly up to the client and may (at the client's
option), be randomized. Only then does it (optionally, but
strongly recommended) move on to the 2.3.4.5 and b:c::d:e pair.
A client supporting either IPv4 or IPv6 but not the other
behaves identically to the dual-stack one except that it doesn't
try any addresses for which it does not have support. And a
client that is configured to not use some addresses (or that has
cached some indicative knowledge for a short time) doesn't
bother to try the excluded addresses either, no matter what the
criteria were for the exclusion.
If this story has a moral, it is that, if the operator
controlling the DNS records and the final destination server has
a preference at to the order in which things are tried, it may
be better off expressing that preference as in John's examples 1
and 2, rather than trusting to luck as in examples 3 and 4.
Thus it has been since RFC 974 -- nothing really new here other
than the application of common sense.
On the other hand, I tend to agree with John that it wouldn't be
a bad idea to have this a bit more explicit. But we actually
did do so in Section 5.2 of RFC 5321. I suppose that, if we
hadn't had our YAMs mashed before they were cooked, we might
have added this set of examples or something that would more
give their flavor, to that section. I note, fwiw, that the -04
version of the preevaluation template for 5321 does not call
this section out as needing change. If someone were motivated,
it wouldn't be a bad idea to update it (and to note that it
would have expired if it weren't in a "wait forever" state) or
to generate an erratum-like note to remind the forgetful editor.
john
best,
john