Re: Minor isn't. It's a pardigm change

Hmm.  We are about to have "one of those" moments in which Dave 
and I agree (mostly) with each other about an architectural 
principle...
--On Sunday, March 30, 2008 4:46 PM -0700 Dave Crocker 
<dhc(_at_)dcrocker(_dot_)net> wrote:
> John Levine wrote:
> > But since everyone's going to have to add AAAA records anyway
> > to move to IPv6, it seems to me this is the least painful
> > time to make them add MXes for their mail servers as well.
> Folks are missing a very basic point:
>
>     To run an email server, today, an existing host only needs
> to make the server software operational.  No other change is
> required.  For example, no coordination with DNS
> administration is required.
>
>     The "simple" algorithm change that permits only the use of
> an MX, for v6 email address queries changes that.
>
>     This is a fundamental change in the complexity of email
> operations.
>
>     In other words, the change moves the MX from being an
> administrative convenience to instead being a core
> requirement, ie, barrier to deployment.
I am surprised that Dave didn't mention a separate, but 
complementary point.  We've actually had a lot of experience 
with trying to use table-based services external to an 
application, and one major experience with the DNS in 
particular, to indicate whether or not a service is present. 
The experience has not been good, partially because people 
change services around and then simply forget to update DNS 
records (or host table services fields).  For those who do not 
remember, I recommend rereading the last paragraphs of Section 
2.2 and Section 5.2.12 of RFC 1123 and trying to remember or 
reconstruct the conditions that caused them.
Using the DNS to _discover_ where to find the preferred server 
for a particular service for a particular domain is a different 
matter from using the DNS to determine whether or not a 
particular server supports a particular service.  The former is 
an appropriate function of a directory service.  The latter 
mixes things up in ways that reduce the robustness of the 
overall environment.  That is at least one of the reasons I had 
trouble decoding Doug's note that started the parent of this 
thread -- the notions of discovering the presumed location of a 
service and of verifying the presence of that service seemed 
hopelessly muddled together, as they have seemed to be in some 
other parts of the thread.
Two possibly-important asides...

(1) I do not agree with Dave that MX records are simply an 
administrative convenience (nor do I read his comment as 
implying that the DNS more generally is just an administrative 
convenience).  I think they are part of the architecture, an 
architecture that clearly includes DNS use.  I do think there is 
a case to be made that using MXs to isolate the location of a 
mail server from the domain at which the mail address is located 
is an administrative convenience, even though it is, as others 
have pointed out, critical enough to important operational 
service models that identifying and dismissing MXs that way is, 
IMO, inappropriate.  However, while the requirement for relaying 
has become less as we have evolved toward a fully-connected 
Internet, if MXs are relegated to "administrative convenience", 
we would, IMO, need to restore the original RFC 821 model of 
forward and reverse paths.   Put differently, one either has MX 
records or one has to have "came from" and "route through" 
functions in the mail transport syntax and model.  Getting rid 
of those functions turned MX from what might otherwise have been 
an administrative convenience into a fundamental part of the 
architecture.
But that modeling issue doesn't have anything to do with whether 
getting rid of implicit MXs, or restricting them to IPv4, is a 
good idea.  I do see a reason to do that in principle, but I 
don't think it holds up in practice: to the extent that 
"transport over IPv6" is a different service than "transport 
over IPv4", then one might reasonably have SMTP-related reasons 
for preferring one of those services over the other that were 
independent of the considerations of RFC 3484.   That might 
suggest DNS setups like
  foo.bar.baz.  IN MX 10 v4host.smtp.example.com.
                IN MX 5  v6host.smtp.example.com.
  v4host.smtp.example.com IN A 10.0.0.6
  v6host.smtp.example.com IN AAAA 2001:DB8::6
  ; smtp.example.com  IN AAAA 2001:DB8::6
  ;                   IN A 10.0.0.6

and, all other things being equal, avoiding the MX default to 
help force people to think about those issues.  But, as others 
have said at more length, it appears to me that the horse is 
long out of the barn.
(2) One of the reasons I felt that we should have done "TCPng" 
when we did IPv6 is that I believe, in retrospect, that 
TCP/IP[v4] seriously erred in letting "timeout" or "connection 
reset" be our only real ways to report "service not supported". 
I believe that a server should be able (and required) to return 
a definitive "no service on that port" message at the TCP level 
and perhaps that there should be a definitive way to probe for 
the presence of a service other than opening a TCP connection. 
I believe that having that type of functionality would be an 
effective way to deal with many of the issues that we are now 
trying to push onto the DNS even though it might raise some 
complex issues about negative response caching and would make 
operations like port scanning more efficient.
But that horse is not only out of the barn, it has long since 
disappeared over the horizon.
  john