Hi.
I have a few questions that I don't want to clutter the IETF
list about but about which I would hope DNS experts, especially
DNS root operations experts, would step in if they have
opinions. IESG copied only for the record. I want to stress
that these are questions: I may know enough to ask them but
can't even competently speculate on the answers.
The new specification proposes what is, in essence, a
convention. If an SMTP-Sender (to use the original and very
precise terminology), while doing the required lookup for an MX
RR, encounters
IN MX 0 .
it is expected to abort the message-sending process -- no
further lookups, not connection attempts, no queuing.
At least in the near term, some SMTP Server ("MTA")
implementations will conform to that rule (many already use it)
and some won't. For the latter, they will presumably do what
the SMTP specs say to do. In summary, that is to look up the
address(es) associated with the root and try to open a mail
connection to one of them. When that connection fails
(presumably times out), the SMTP server may decide to try more
(or all) of the other addresses. When all of those it chooses
to try fail, it is then required to queue the message, retrying
the process (potentially to all 13 root servers) at regular
intervals for an extended period of time.
It is impossible for me to estimate the actual likely volume of
such connection attempts. I suggest that any such estimate
would be no better than a wild guess. It is clear that the
requirement for retries and the number of root servers (i.e.,
that there is more than one address record) provides a
multiplier effect on the number of MTAs and misdirected messages
that do not follow the convention.
Given that the DNS configurations for some domains are using
this convention now, it should be possible to measure
present-day SMTP connection attempts to the root servers. I
don't know if anyone has those data. Because such attempts
could originate from multiple causes, it might also be hard to
interpret if it existed... beyond my experience.
So, three (obviously-related) questions:
(1) I understand that there have been concerns from time to time
about the load caused by spurious queries to the root servers.
These would not be spurious DNS queries (I assume primarily UDP)
but spurious TCP connections to a port that I assume no
contemporary root server uses to accept mail. Is that potential
change in load an issue that anyone should be concerned about?
(2) Would you recommend that the root servers take any special
action to mitigate the potential problem? Such action might
involve a port 25 responder that immediately closes connections
(at least reducing timeout waits), or a fake SMTP server that
would allow a connection to be opened, then immediately send a
5yz response to the SMTP sender. If the SMTP specs are followed
by the sender, the latter would prevent attempts on other root
server address and the queuing behavior. Either obviously
involves some additional resources.
(3) Independent of the answer to the question above, does the
possibility of DNS operational impact as the result of this
convention merit comments in the I-D that are not now present
and, if so, what should be said?
Recommendation: if the participants in DNSOP consider either of
the above questions (and they are only questions) to be
significant, it may be worthwhile to ask the IESG to postpone a
decision on this document until this WG has an opportunity to
comment.
The above is obviously independent of the concerns about
terminology that I raised in my Last Call response. As some of
you know, sloppy and ambiguous terminology in discussions of the
DNS has become a pet peeve of mine. If no one else cares, or
cases enough to put effort into the problem -- even to prevent
new ambiguous usage from entering the vocabulary via IETF
standards track documents -- then I will go back to whining into
my beer and stop trying to waste other's time on the issues.
best,
john
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
