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

[SM <[e-mail]>]

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf