Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 11:50 10-11-2008, der Mouse wrote:
What the IETF _does_ have a chance to do here is to improve the quality
of a critical piece of Internet infrastructure (email without DNSLs in
today's net is either unusable or very heavily balkanized) by
standardizing those aspects that are in shape to be standardized.  The
IETF says "rough consensus and running code".  We have the running
code.  We even have something close to rough consensus in the field, in
the form of the many DNSL providers and users; I hope the IETF can
recognize that consensus and echo it enough to do what it can to help.

As this document is Standard Track, it's in the IETF stream. Documents on the Standard track require IETF review and the consensus of the IETF community. It's not the same as rough consensus in the field.

Quoting the document:

  "This document represents the consensus of the Anti-Spam Research
   Group of the Internet Research Task Force."

If this document is published in its current form, I suggest removing the IRTF Notice.

There is a large user-base for DNSBLs as it's viewed as a cheap (resource-wise) way to stop spam. Most MTAs have built-in features to query DNSBLs and reject incoming SMTP connections if the IP address is listed. Some vendors enable DNSBLs in the default configuration of the MTA they ship. This has lead to problems over the years as some DNSBLs were receiving queries even after they were shut down. Some of them resorted to returning positive responses for all queries get the attention of the mail administrator as it caused all mail to be rejected. The document recommends that:

  "DNSxL clients SHOULD periodically check appropriate test entries to ensure
  that the DNSxLs they are using are still operating."

That would require a change, for the better, in the implementation of DNSBLs in MTAs. I would go further and suggest that DNSxL clients should rate limit their queries if the test address does not exist and must not generate queries to the DNSxL if the test is unsuccessful after a period of time.

In Section 6:

  "A client MUST interpret any returned A record as meaning that an
   address or domain is listed in a DNSxL."

There have been cases where a mail server used a DNS server which returned an A record instead of NXDOMAIN. That can lead to incorrect results if the above recommendation is followed. It may be better for the client to validate the returned A record for correctness.

The Security Considerations could have been more exhaustive for a Standard Track document. For example, if the DNSxLs are unresponsive, it can affect mail delivery. DNSBLs are somewhat different from other DNS based services due to their controversial role. They are generally subject to Denial of Service and it is worth the emphasis instead of only having a pointer to RFC 3833.

  "Since DNSxL users usually make a query for every incoming e-mail
   message, the operator of a DNSxL can extract approximate mail volume
   statistics from the DNS server logs."

Operators of some types of DNSxLs might also be able to extract some information about the senders.

As mentioned in the document, name-based DNSBLs are also used to check the domains found in URLs in message bodies. That can lead to unintended information disclosure.

Regards,
-sm
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]