--On Friday, July 18, 2014 14:59 -0400 John R Levine
<jo...@taugh.com> wrote:
>> Today's problem, IMO, is that, while there is little debate
>> about "DNS-based solution", or even "DNS-based solution
>> involving something special in the relevant MX record", I
>> haven't seen a careful analysis by DNS experts on which of
>> several DNS approaches have the least bad operational
>> properties.
>
> But, John, this is the one that's implemented in many popular
> MTAs, has been in daily use for the better part of a decade,
> and has no observed issues at all that I ever heard of. No
> doubt it sends some traffic to the root servers, but have any
> root server surveys ever even mentioned A or AAAA query
> traffic to "." ?
If you head read all of my note, you would have noticed that I
expressed a strong preference for staying with "MX ." unless
there were compelling reasons for doing something else.
"Compelling" is a pretty high bar, but I think we need to ask
and then listen. Also see below.
As to "no observed issues" and indications of support in the
many popular MTAs you have cited elsewhere, I think counting
SMTP implementations is essentially bogus for reasons discussed
(and claims made) in another thread on the IETF list. For those
with the patience for the analysis, see [1] below.
More relevant, I think, is that the deployment scale for this
convention has nothing to do with how many SMTP servers
implement it -- whether they do by string matching (also see
below) or by giving a "just stop here" interpretation to certain
types of DNS responses to lookup of MS DATA field contents. If
no one created an "MX ." entry, then the number or types of
servers who were prepared to deal with one in a special way
would be completely irrelevant and the number of queries to the
root would be zero. Now we both know that there are a bunch of
"MX ." records out there. I assume the number is not very large
compared to the total number of nodes in the DNS that own
address records or even that number less the number of nodes who
have MX records that point to SMTP servers. But the load on the
root as the result of this convention (whether "approved" by the
IETF or not) is, unless my brain is completely not working
today, dependent on how often such records are encountered less
the number of systems that trap the "." convention locally. If
the reason for asking for IETF approval is to encourage more
nodes to be associated with these records (otherwise, you
presumably wouldn't be looking for standards track) then more
"MX ." entries are likely to result in more DNS queries -- how
many more is, I believe, anyone's guess although I discuss some
parameters below.
Part of the issue here is an SMTP subtlety (or perhaps an RFC
5321 glitch). Your spec says (Section 3) "The DNS root is not a
valid host name, so a NULL MX record can not be confused with an
ordinary MX record." That is clearly true. But, while an SMTP
implementation could invoke the "operational necessity"
provision of 5321 and make a string comparison check rather than
sending a query to the root, SMTP does not require that the DATA
associated with an MX record pass SMTP tests of "valid host
name" (in SMTP a rather restrictive bit of local syntax); it
basically requires that whatever is out there be looked up, with
validity (getting back an address record) depending on what the
DNS has to say (see 5321 Section 5.1)
So, again with the stipulation that I may still not fully
understand the issues here, I'd look, not at numbers of SMTP
server implementations, or even the amount of traffic they might
carry, but the number of MX RRs with "." in the DATA. I'd
assume that number would grow significantly and asymptotically
after this specification is approved and more operators install
the records and then with the growth in the Internet (or the
DNS). The actual number of queries would depend on the subset
of those nodes that were hit, either intentionally or by
mistake. I don't think we have any way to estimate that. In
any event, if one believes in Internet growth and that "don't
send me mail" MX records are a good idea, there will be a lot
more of them in the future, maybe enough to justify a change now
if one is otherwise appropriate (or maybe not).
My apologies for not thinking of it sooner but, if I were
worried about DNS root server impacts (email messaging with
mistakes about domains may be such a small percentage of traffic
to not count) or even unnecessary DNS traffic minimization more
generally, I'd recommend that this new specification explicitly
update Section 5.1 of RFC 5321 to require that DNS servers make
a string-comparison test against "." (or whatever the string
turns out to be) and stop if it is found rather than doing DNS
lookups on whatever is in the data field. As an alternative,
5321 could be updated to require checking the contents of MX
DATA against the SMTP mailbox domain rules. Neither would
affect anything that exists today that is reasonable, but they
would move that check from an optimization that may not be
obvious from the current spec (and that requires invoking an
exception rule to be SMTP-conforming) to an explicit
requirement. Server implementers who haven't heard of this
spec would still invoke the DNS, but, as servers are upgraded,
it would put something of a damper on query growth.
> I can sorta kinda see not wanting to bless it in an RFC, but
> if we tell people to do something different, we'll just look
> ever more out of touch and they'll ignore us. Again.
<rant>
To the contrary, I think the problem here (if there is one) is
that these types of ideas are being invented, specified through
formal or informal private discussions, deployed, and then
brought to the IETF for standardization. Had this been brought
to the IETF and gotten the kind of review it is getting now
(including, in this case, a review by DNS folks that probably
would not have occurred in private discussions among email
people) before it was widely deployed, we could have had a
discussion about choices of strings, modifications or
clarifications to SMTP, etc., before the community reached the
point that a proposed change would have to be really strongly
justified in terms of its advantages before anyone would pay
attention. That is, IMO, where the traditional IETF way of
doing things by moving the _designs_ through cross area review
and consensus processes adds value. If we are at the point
where the best way to get work done is to prepare a
specification "outside", among enthusiasts, and without any
opportunity for cross-area and skeptical participant review, get
it deployed, and then hand it off to the IETF with statements
like "if we change this, they will ignore us. Again." --even or
especially when that is true-- we might as well hand all of our
standardization work off to ISO/IEC JTC1. They, I believe, can
do an editorial review and wield a rubber stamp more efficiently
than we can. That should be fine as long as long as there is
no expectation that they will do a competent engineering review.
And it might leave more time for the IETF to do careful
engineering reviews when that is actually useful. I guess I
should consider saying that at the plenary. :-( </rant>
That said, the developers of most of the SMTP servers you cite
are our friends and pay careful attention to our work. Several
are even active IETF participants. If we have a really
persuasive reason why a string change is needed --and it would
have to be both really persuasive and well-documented-- I think
experience indicates that they would adapt, even if they
continued supporting "." (however they do that) forever.
best,
john
[1] I vaguely remember a parallel ruckus on the IETF list in the
last week or three where something has been justified because a
number of providers, who are claimed to account for a really
large percentage of the email in the world, like it. To the
best of my (admittedly limited) knowledge, none of those
providers are running unmodified versions of any of the servers
you cited. Add all of the corporate/industrial systems that are
running Exchange to the list and there is plausible reason to
assume that an even larger fraction of total email traffic is
not now going through systems that we know are using this
convention.
First, if one or more of those existing implementations are
making explicit checks for "." in the DATA, they are immediately
irrelevant from a DNS standpoint: no queries are generated to
the root servers unless an implementation blindly picks the MX
DATA up and tries to obtain an address record and take action on
"no record of that QTYPE" failures. As mentioned above, SMTP
does not require that pre-lookup check. You may know which of
those implementations do that. I don't.
However, assuming that every one of them queries the root and
with the understanding that trying to use estimates about total
message traffic as a surrogate for the number of messages that
are likely to encounter non-mail-receiving domains is pretty
dubious, the argument that the community has to live with (and
maybe tune) DMARC because it dominates traffic (what was it,
63%), plus Exchange (maybe another 10%) gets turned around and
into a claim that the servers you are talking about account for,
at most, only 27% of message traffic. Could that be ok and
getting to 100% be a problem... maybe. I'm not competent to
judge.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
