[Top] [All Lists]

Re: Minor is. It's not a pardigm change

2008-04-06 22:19:09
At 21:09 -0400 on 04/06/2008, Hector Santos wrote about Re: Minor is. It's not a pardigm change:

Hector Santos wrote:

The different here from what I am reading is that there seems to be this notion that the DNS resolver is always independent from the SMTP and its results drive the SMTP client - i.e, the SMTP client is not in the picture. I don't believe that concept can be presumed to be always true.

Clarification because DNS results always drives an SMTP client

What I meant is that a MX query returning NO RECORDS is what drives the SMTP to consider using a Implicit MX concept.

If the resolver always return a MX query result, then the SMTP client will never have any control here. I don't think using the zero preference is a reliable indicator to represent a raw A record for the domain.

I agree with your statements. For historical reasons we MUST allow use of the A records in the FQDN IN group (since no-one has had the guts to ramrod an RFC that says "Enough is Enough. MX has been in existence for 20 years and that is enough time to have gotten off your rumps and added MX records pointing at the A records that define your IPv4 MTAs. Thus as of this Flag-Day date the ability to access an IPv4 MTA via its A record instead of having a MX record point at that A record is forbidden and is no longer supported").

The fact we allow MX-less MTAs to be accessed via an A record is NOT a valid excuse to allow AAAA records to be used in this case. While that WAS an excuse to allow the A record to be used (ignoring the question of if this excuse is still valid), the existence of the MX record (and [all-most?] 100% support for the MX record in DNS code and 100% support for the MX record in the code with IPv6 support) that predates the existence of IPv6, means that it should be required to exist and point at the AAAA records that belong to IPv6 IPN monitoring MTAs. The use of AAAA records to locate an IPv6 MTA does NOT predate the existence of the MX and thus should be forbidden.

As to support of a IPv6 MTA (either via an IPv6-Only or Dual IPv4/IPv6 stack), we mandate that the IPv6 MTAs (and any IPv4 MTAs that share the IPv6 MTA's FQDN) be pointed to by a MX.

Thus the resolution logic is as follows.

1) Look for a MX. If found go to step 3. If not found set a NO-MX flag.
2) Pull the FQDN IN Group by acting as if a FQDN MX 0 FQDN was found in step 1.
3) Process the IN A/AAAA records in order (within MX Priority order).
4) For each A/AAAA selected in step 3, check for the NO-MX flag and if found ignore the record if it is an AAAA and immediately go to step 7. 5) Since NO-MX is not on, we found a real MX so process the A/AAAA as at present. ie: If an A, check if we have IPv4 Stack support, if an AAAA check for IPv6 Stack support. Lack of support goes to step 7. 6) Attempt to connect to the A/AAAA designated IPN. If we get a connection then process based on whatever return code we get (which may mean going to the next IPN in the list [step 3] or giving up). 7) The current A/AAAA record is no good, If this is not the end of the A/AAAA list, go back to step 3 and process the next IPN in the list. Otherwise go into the "No Usable IPNs" error state and deal with it appropriately.

NOTE: This method keeps the status quo for the case where ALL the MTAs for the FQDN are IPv4 MTAs (with or without a FQDN MX). It only says that MX-less FQDNs are serviced by those A records in the FQDN IN group and that any AAAA records found there are to be ignored.

Attachment: !3a-) Happy.gif
Description: GIF image

<Prev in Thread] Current Thread [Next in Thread>