[Top] [All Lists]

Re: current usage of AAAA implicit MX?

2008-04-05 22:33:31

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


 (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).