I'm no longer going to comment on the mail aspects of this MX
debate on the IETF list -- see the ietf-smtp list. But there is
an issue here with much broader implications...
--On Monday, March 31, 2008 9:36 AM +1000 Mark Andrews
<Mark_Andrews(_at_)isc(_dot_)org> wrote:
...
It's a natural back port of the SRV rules to MX.
"SRV 0 0 ." indicates "no service".
Well, strictly speaking, it doesn't mean that, regardless of
what the SRV specs say. What is means is "this service is not
advertised for this domain".
The lack of a SRV RRset means that.
If a service is associated, as
part of its protocol, with an established (not necessarily
well-known) port, then the only way to determine that the
service isn't offered is by attempting to connect to that port.
"SRV 0 0 ." is a affirmative statement saying there is no
service for this domain. There may well still be something
listening on the standard port processing transactions for
another domain.
You have similar today with MX records where host A can be
handling all email directed to domain B and host B is
handling all email directed to domain A.
SRV support was NOT grandfathered in for existing protocols
to avoid the well known port problem.
The default was for NEW protocols that decided to use SRV
records. SRV lookup is not optional in these cases.
If is isn't associated with a specific port, one may have a hard
time trying to find the service, but the only way to know that
is isn't being offered is scan ports looking for it its
symptoms. For good reason or bad, there are also all sorts of
ways to communicate the location of a service and the port to
use that have nothing to do with the DNS and DNS changes,
restrictions, and records cannot affect them. These are not
special properties of SMTP, with or without MX records; they are
properties of TCP. If one wants to fix those problems, then TCP
has to be changed to affirmatively return a "no service" message
if an attempt is made to connect to a port on which no service
is specifically listening.
It was obvious 20+ years ago that MX processing was broken
as there was no way to say "I don't want email".
First, it may have been obvious to you, but it wasn't obvious to
many of us. In the general case, it still isn't. But you
stated the situation exactly correctly. "MX 0 ." means "I
don't want email". "SRV 0 0 ." doesn't really indicate "no
service", it indicates "please do look for that service here".
"SRV 0 0 <hostname>" means look for that service here.
"." is not a valid hostname.
Looking
a the MX record, "MX 0 ." was the obvious solution. The
only reason I can see that it never went ahead was FUD.
While it is better than interpreting the lack of a bit in a WKS
record as "no service", it is still nothing more than an attempt
to use the DNS to say "please don't try a mail connection to
this domain". I think that is probably ok and would be happy to
see a proposal carefully considered to see if consensus could be
reached (as Frank points out, there was such a proposal but it
quietly disappeared, no FUD campaign needed).
The was FUD about the roots being overwhelmed by A lookups.
That FUD was raised again the moment this was resuggested.
But I note that
"please don't do X" is a solution to a different set of problems
than a solution that would prevent someone who is predisposed to
antisocial behavior from trying something. Since bad guys can
deduce addresses by scanning --and will certainly do so if we
make it sufficiently hard for them to use the DNS-- this type of
DNS change, it seems to me, would have little effect on the
antisocial. And, again, that isn't a statement about email
because it applies with equal force to any other application
service we have.
I'm not really worried about anti-social behaviour. I want
good behaviour for real users that send email to hosts that
don't have SMTP servers turned on. 1 week timeouts is not
good behaviour.
It's so obvious that some MTA's already implement it. Exim
is the example I've been told about.
The existing MX processing rules assume that *every* host
wants to receive email. The assumption has not been correct
for 20+ years.
The existing A processing rules assume that *every* host wants
to, or is at least able to, receive web connections, file
transfer connections, SIP connections, telnet connections,
Jabber connections, and, by the way, DNS connections. Changing
the MX rules won't change the assumption that every host
supports email. And most, it will make a statement of
preference that mail connections won't be accepted more clear.
And, viewed in that light, Exim's behavior represents a
willingness to honor a preference... a willingness that,
incidentally, can be bypassed by the simple expedient of giving
it an address in literal form rather than one that is processed
via the DNS. Of course, Exim can, and often is, configured to
reject mailbox(_at_)[ip-literal] addresses, but that behavior is
outside the standard.
john
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org