John C Klensin <[EMAIL PROTECTED]> wrote: > > 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.
True, but all of us are talking about the first, not the second. We aren't setting out to ask whether a _server_ supports SMTP -- we're asking what IP address a _domain_ advertises for receiving SMTP connections. The RFC2821 text about implicit MX states a fallback, in the absence of any MX RR, and it states it in terms of what the implied MX record must be assumed to be. > (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. Agreed. > 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, I'm not sure I understand. I hope you mean that the domain-name of the server need not be the same as the domain for which it receives email, which I consider a rather important architectural feature. > 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. (I'm sure I _don't_ understand that statement.) > 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. I can imagine other solutions, but I agree that MX RRs were essential to depretating forward-path. > 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. Agreed, I think... > 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", (I'm not sure we've yet found a better paradigm than recognizing them as different -- and assuming the existence of a gateway.) > 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. This looks interesting! > 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 I may be confused... One certainly can use DNS to state a preference for IPv4 or IPv6 and a gateway for the other, but this doesn't look to be doing that. > 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. The IPv4 horse is "long out of the barn", but not the IPv6 one. > (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". Agreed that those are not the right wayr: though "connection reset may be "close enough", "timeout" certainly isn't. > 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. Either of those would be an improvement. > 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 in our "real world," DNS appears to be our best tool. And I believe SRV RRs will get us there, though we need to be patient and might need to tweak their definition. > But that horse is not only out of the barn, it has long since > disappeared over the horizon. "Bring me that horizon!" -- John Leslie <[EMAIL PROTECTED]>
