Subject: Re: houston.rr.com MX fubar?

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Jan 2008 09:22:21 +1100

> On Tue, 15 Jan 2008, Mark Andrews wrote:
> >
> > 	Since there is no [MX] fallback to AAAA
> 
> Wrong. http://www1.ietf.org/mail-archive/web/ietf/current/msg49841.html
> 
> Tony.

	Since when has Informational been equivalent to Standard?

	Synthesizing a MX record on NODATA to a MX lookup or a
	subsequent AAAA lookup is bad engineering decision.  It
	will work reasonably well for IPv4 only + dual stack
	envirionment.  It will not work will for IPv4 only + dual
	stack + IPv6 only envirionment.

	The reason it is a bad engineering decision is that:

	* the IPv4 only world needs a MX to find a dual stack MTA to
	  relay into the IPv6 network.

	* the IPv6 world has a raft of solutions which will allow it
	  to initiate a connection to a IPv4 only MTA without having
	  to find a dual stack MX for the mail domain.

	* it changes the definition of what it means to exist in
	  the mail domain and you will have different MTA's making
	  different existance decisions.  Some will say that AAAA +
	  no MX exist but others will say that the site does not
	  exist.

	Do you really thing we should be trying to force a upgrade
	of all MTA's on the planet to support MX synthesis from
	AAAA when there is no engineering need to to this?

	MX from A was a transition strategy.  IPv6 only sites have a
	transition strategy that doesn't require synthesis.  It is
	advertise a dual stack MX.  At some point in the future sites
	will stop having a dual stack MX, the same way they stopped
	adding A records for mail only domains back in the 90's.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Jan 2008 11:25:49 +0000

> 	Since when has Informational been equivalent to Standard?

Since (a) there is no standards-track specification to override it, and
(b) all implementations follow RFC 3974, and (c) it's the obvious
extension of v4 behaviour to v6. I should have said in my previous
message that not only do the most popular MTAs fall back to AAAA, but BIND
also includes AAAA in the additional section of MX replies, which
re-inforces the RFC 3974 interpretation.

> 	AAAA when there is no engineering need to to this?

They have already been upgraded in this way. Even without fallback-to-
AAAA, they have to be upgraded to handle IPv6 anyway, because the IPv4
MX lookup algorithm breaks as I described in
http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html

> 	MX from A was a transition strategy.

It might have been intended that way, but it has become a permanent part
of the protocol.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WEST FAIR ISLE FAEROES: NORTHEASTERLY VEERING SOUTHEASTERLY 5 TO 7, PERHAPS
GALE 8 LATER. VERY ROUGH. SHOWERS. MAINLY GOOD.

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Jan 2008 12:18:50 +0000

On Wed, 16 Jan 2008, Tony Finch wrote:
>
> I should have said in my previous message that not only do the most
> popular MTAs fall back to AAAA, but BIND also includes AAAA in the
> additional section of MX replies, which re-inforces the RFC 3974
> interpretation.

Er, no it doesn't. I should have had some coffee before writing that reply
:-/

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT: SOUTH GALE 8 TO STORM 10 VEERING WEST 4. VERY ROUGH. SHOWERS.
MODERATE BECOMING GOOD.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Jan 2008 14:55:17 +0100

> Since (a) there is no standards-track specification to override
> it, and (b) all implementations follow RFC 3974, and (c) it's
> the obvious extension of v4 behaviour to v6.

That line of arguments is shaky for (a).  For (b) we have to see
what the "implementation and interop report" says, that could be
nothing, because 2821 forgot to mention AAAA - your observations
for popular MTAs not withstanding.  And while (c) is obvious this
could be a window of opportunity to kill this feature in 2821bis.

> it has become a permanent part of the protocol.

If the IESG approves 2821bis.  I don't believe in any "consensus"
if that's not a decision by a Chair or the IESG, but this 2821bis
detail is apparently getting "rougher".  I've no clear idea what
John meant in the discussion of IPv6 wrt SMTP here some days ago.

 Frank

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Jan 2008 09:19:32 +1100

> re-inforces the RFC 3974 interpretation.

	a) when RFC 2821 was written IPv6 existed and RFC 2821 acknowledged
	   its existance.  It did DID NOT say synthesize from AAAA.
	c) MX replies is *not* MX synthesis.

> http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html

	MX additional section is a optimization.  The lack of AAAA or
	A records is NOT a bug.
 
> It might have been intended that way, but it has become a permanent part

	And it has negative impacts on DNS caches and MTAs.
	There is no need to use the same kludge with IPv6.

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Jan 2008 11:29:49 +0000

> 	   its existance.  It did DID NOT say synthesize from AAAA.

RFC 2821 only talks about IPv6 domain literals. The MX resolution
algorithm in section 5 is written as if in complete ignorance of IPv6 so
it is reasonable to interpret it in the way that RFC 3974 does. If you
wanted to rule out MX synthesis from AAAA then it should have been written
down ten years ago. It's too late now.

> 	MX additional section is a optimization.  The lack of AAAA or

Perhaps you could explain why the problem I described in the URL above
isn't actually a problem.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST 4 OR 5, BACKING SOUTHEAST BECOMING CYCLONIC 5 TO 7, PERHAPS GALE
8 LATER. ROUGH. RAIN LATER. MODERATE OR GOOD.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Jan 2008 09:51:48 +1100

> down ten years ago. It's too late now.

	We 99.9% of the time write down what we should do.  We very
	rarely write down what we shouldn't do. 

	Just because *you* think it was written in complete ignoranance
	doesn't mean that it was.  If you follow what is written down
	there NOTHING breaks.  If you think you know better then things
	break.

> isn't actually a problem.

	It is not as problem.  Additional records have ALWAYS been
	optional.  Any MTA that doesn't look for address records
	if they are missing from the additional section is *broken*
	and won't work in a pure IPv4 world let alone a mixed
	IPv4/IPv6 world.
	
	The few cases where there have been such MTA's they get
	fixed / replaced because they fail to deliver email.  I've
	seen reports that a nameserver was broken because it failed
	to add additional records (usually because they were not
	in the cache).  Once you point out that it is the MTA that
	is broken that is the last of the complaint.

	There will always be developers that fail to read the
	specifications.  When the complaint comes that something
	is broken you bring out the specification and point out the
	fault.

	Mark

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 18 Jan 2008 09:30:22 -0500

>isn't actually a problem.

In my many years of dealing with DNS protocol definition and implementations
I have developed a moral: Optimization is the worst possible solution!

Placing A records in the additional section on an answer to MX query is an
attempt to optimize (or minimize) the number of queries needed by the MTA.
Due to this there are MTA's out there that will/can not ask the follow up
query if the desired address record is not in the additional section.

The fundamental question is which protocol implementation should change to
support the other ?
Mail people argue that DNS implementations should change,
us DNS people argue that Mail implementations should change/evolve.

I do not think we will ever agree.

Tony, in your message you talk about MTA doing extra "wasted" lookups.
Guess what, it is only a question of who does the work:
         the MTA
or      the recursive DNS resolver.

The only difference is that the MTA can scope the queries based on 
what transport
protocols it uses, and curtail the search once it finds an useable answer.
The DNS recursive resolver can only stop after it tries all names for all
transport addresses.

         Olafur