![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Thu, 17 Jan 2008, Mark Andrews wrote: > > a) when RFC 2821 was written IPv6 existed and RFC 2821 acknowledged > 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.
> > 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 additional section is a optimization. The lack of AAAA or > A records is NOT a bug.
Perhaps you could explain why the problem I described in the URL above 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.
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.