ietf-smtp
[Top] [All Lists]

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

2008-03-30 19:15:15

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