At 21:21 +0200 on 04/05/2008, Peter J. Holzer wrote about Re: current
usage of AAAA implicit MX?:
On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
At 12:56 -0400 on 04/04/2008, Tony Hansen wrote about Re: current
usage of AAAA implicit MX?:
>These questions are intended to find out what current IPv6 deployments
>do in these situations. When an MX is not found, are they already
>looking for both A and AAAA records, or are they only looking for A
>records. Are they following RFC 3974 or not? What's the installed base
>already doing?
RFC 3974 talks about Dual Stack set-ups and what an IPv4-Only Server
should do when presented with a Mixed MX or an MX that only points at
IPv6 AAAA records. It, BTW, REQUIRES an MX if there are any IPv6 MTAs
and only supports A-Fallback in the absence of an MX
No.
(ie: It does NOT define any attempt to look for AAAA records in the
absence of an MX after/before checking for A records).
Yes, it does:
| (1) Lookup the MX record for the destination domain.
[...]
| If NODATA (i.e., empty answer with NOERROR(0) RCODE) is
| returned, there is no MX record but the name is valid. Assume
| that there is a record like "name. IN MX 0 name." (implicit MX)
| and go to step (3).
[...]
| (3) If the sending MTA has IPv4 capability, lookup the A records.
| Keep the resulting addresses until step (5).
|
| (4) If the sending MTA has IPv6 capability, lookup the AAAA records.
Both A and AAAA records are looked up for the implicit MX.
It also states that in the presence of an MX containing IPv6 address
references, an IPv4-Only stack should ignore the IPv6 addresses
Yes, of course. It cannot reach them anyway. Just as IPv6-only hosts can
ignore A records since they cannot reach them either.
and only use the IPv4 addresses (and in a IPv6-Only MX to NOT do
IPv4-A-Record fallback).
Where do you read that?
My error. I did not notice the weasel wording at the end of step 1
that lacked a "bypassing step 4" after the "go to step (3)" which
would have applied step 4 ONLY to real (as opposed to
generated/simulated) MX records. Most of RFC 3974 talks about what to
do when you encounter a REAL MX (a case where step 4 is a valid step
since the REAL MX says to reference the AAA records even in the FQDN
MX x FQDN case).