On Apr 14, 2009, at 3:25 PM, Todd Glassey wrote:
Daniel Senie wrote:
On Apr 14, 2009, at 2:54 AM, Douglas Otis wrote:
On Apr 13, 2009, at 7:01 PM, Mark Andrews wrote:
If a application is doing the wrong thing w.r.t. SRV records then
fix the application. The root servers can handle a A and AAAA
queries for ".". Most cache's will correctly
negatively cache such responses.
As for "MX 0 ." the sooner this gets defined as no SMTP service
for this domain the better. The cost for changing this is only
every going to increase.
It may take years before a significant portion of SMTP servers
recognize root domains as meaning no service. An alternative
would be to require MX records to assert SMTP service. A positive
assertion will not impose additional burdens on root servers, but
will necessitate explicit DNS provisions to exchange SMTP
messages. With 19 out of 20 messages being abusive and largely
from compromised systems, requiring a domain to assert their
intent to exchange public SMTP messages will encourage adoption
without burdening root servers with strategies sure to generate
extraneous traffic beyond their control.
SRV records have demonstrated the inability of roots to ensure
applications mitigate extraneous traffic. Expanding upon this
failure seems sure to result in a growing number of wildcard MX
records targeting roots. Negative caching of randomly spoofed
domains might not be an effective control. It seems unwise to
encourage a greater use of wildcard records that target roots.
I agree with Doug. The most reasonable course of action would be an
IETF document, perhaps a BCP, that indicates SMTP transports should
ONLY do MX lookups to find the mail server for a domain, and not
fall back on A records. I'd endorse this, and would work on such a
document if there were interest. The big question is whether it
would be done in DNSOP, since it affects how DNS records are
interpreted, or in the defunct SMTP group's list, since it affects
how mail servers interpret DNS information.
I specifically do NOT agree with the "MX 0 ." approach, and do not
see any reason why this would be a better solution than simply not
having MX records at all. True, during implementation of an MX
requirement, some portion of sites might have difficulty receiving
email until they add an MX record. But adding MX records is a well-
known process, and the effort for those domains that haven't
bothered with them in the past will not be onerous
Daniel the reason is simple - because defining a MX 0 shows a
specific intent. Having no MX record at all shows sloppy domain
management and that there was no properly formed domain profile in
the master public lookup's, i.e. DNS. By the way NEA desparately
needs the ability to find a MX service in its operations IMHO.
So the idea is that there really isnt a need to make the world a
better place for sloppy domain admin's, but that there is a need to
properly define the positive and negative status of any domain
element - including time servers (sorry couldnt help but sneak that
one in).
A related concern is the solution using "MX 0 ." then results in a
further need, a wildcard in every zone, so that the base domain name
is protected, and so that any hosts within the domain name are
protected. So for example, you'd need an MX on example.com, but also a
wildcard so that someone doing an MX lookup on www.example.com also
gets told to get lost. So this is a further argument in my mind for a
change in default SMTP transport behavior, as a zone with no MX
records at all would indicate "don't send mail here." A zone with an
MX on the domain name but nothing specified on a per-host basis or
wildcard indicates "we take mail, only for email addresses
@example.com". Again, this winds up being desirable as it should
result in less traffic in the long run being sent to web servers and
other servers that do not handle SMTP anyway.
As for the argument raised about IN-ADDR in relation to SMTP, there
are already large email outfits that refuse email from hosts that do
not have at least some result showing for a PTR lookup on the
connecting IP address. Whether you like it or not, that's already in
use, and it does block some spam.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
