DNSBL BCP v.2.0

[Nick Nicholas]

Greetings:

With much help from the authors as well as the ASRG chair and Dave
Crocker, I have finally completed the revisions to the DNSBL BCP.  A
copy is beneath my .sig so that you may make your comments inline if
desired.  I tried to include as many comments as possible from the
discussion of the previous draft, but the authors and the editor deemed
it was necessary to decline to use some of the suggestions.

Flame away!  I'm wearing my Nomex suit.  :-)

Regards,

Nick


--
 
Nick Nicholas
Knowledge Engineer
Habeas Inc.
650-694-3320
nick@...


-------------------







Internet Draft                             Yakov Shafranovich (Editor)
Expiration: August 2007                       SolidMatrix Technologies
Network Working Group                           Nick Nicholas (Editor)
                                                                Habeas
                                                         Matt Sergeant
                                                           MessageLabs
                                                           Chris Lewis
                                                       Nortel Networks
                                                         February 2007


   Guidelines for Management of DNS-Based Reputation Systems for Email
      draft-irtf-asrg-bcp-blacklists-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF),
   its areas, and its working groups.  Note that other groups may
   also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

    Copyright (C) The Internet Society (2007).  All Rights Reserved.

Abstract
 
   The rise of spam and other anti-social behavior on the
   Internet has led to the creation of shared blacklists and
   whitelists of of IP addresses or domains. This memo discusses
   guidelines for management of public DNS blacklists.
   
   The document will seek BCP status. Comments and discussion of this
   document should be addressed to the asrg@... mailing list.
   
   
Table of Contents

   Abstract
   1. Introduction
      1.1  DNS-Based Reputation Systems
      1.2  Guidance for DNSBL Users
      1.3  Terminology
   2. Background.
      2.1.  Transparency
         2.1.2.  Listing/Delisting Criteria SHOULD Be Easily Available.
         2.1.3.  An Audit Trail SHOULD Be Maintained.
      2.2.  Listings and Removals
         2.2.1.  Listings SHOULD Be Temporary.
         2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be
                 Available.
         2.2.3.  Removals SHOULD Be Prompt.
         2.2.4.  Criteria for Listing and Delisting SHOULD Be Similar.
         2.2.5.  Removals SHOULD Be Possible in Absence of List
Maintainer.
   3.  Operational Issues
       3.1. Inactively Maintained Lists SHOULD Cease Operations.  
       3.2. Cessation of List Operations MUST Be Done in a Graceful
Fashion.
       3.3. Content of DNSBL Zone File SHOULD Be Limited.
       3.4. Special and Reserved IP Addresses MAY Be Used.
       3.5. Use of Collateral Damage MUST Be Disclosed.
       3.6. Special Considerations for Blacklists Listing Insecure
Hosts.
        3.6.1.  MUST NOT Scan Without Provocation.
        3.6.2.  Re-scan Periods SHOULD Be Reasonable.
   4. Security Considerations
   5. Informative References
   6. Author(s) Addresses.
   7. Acknowledgements.
   8. Full Copyright Statement.

   

1. Introduction.

1.1.  DNS-Based Reputation Systems

   Due to the rising amount of spam and other forms of network abuse on
   the Internet, many community members and companies began to
   create and maintain DNS-based reputation systems ("DNSBL") of IP
   addresses and domains identified as problem sources of email.  These
   lists also have been known as blocklists and blacklists.  These
   lists are used for filtering email.  DNSBLs are either public or
   private.  A public DNSBL makes its data available to any party
   seeking information from the list, but a private DNSBL is used
   solely by an organization for its own use and the data is not made
   available publicly.

   The first publicly available DNSBL using the Domain Name System (DNS)
   for distributing reputation data about email senders emerged in 1997,
   shortly after spam became a problem for network operators and email
   administrators.  This pioneer DNSBL focused on identifying known
   spam sources situated at static IP addresses.  Due to the broad
   adoption of this DNSBL, it had a devastating impact on static spam
   sources.  Consequently, abusers found other methods for distributing
   their spam such as relaying messages through unsecured email servers
   or flawed formmail scripts on web pages.  Additional DNSBLs were
   developed by others in order to address these changing tactics, and
   today more than 700 DNSBLs are in operation.
 
   Existing DNSBLs vary greatly in their policy, usage and and level
   of maintenance.  These guidelines try to lay out a set of best
   practices for running a DNSBL in an open manner with the hope that
   they will facilitate better management of DNSBLs, and provide better
   information for prospective users in selecting which DNSBLs to use.

   These DNSBLs vary widely in integrity, strategy, methodology and
   stability.  While listing criteria can sometimes be quite
   controversial, this document deliberately does not discuss the
   rightness or wrongness of any criteria.  We assert that DNSBL
   operators are free to choose whatever listing criteria they wish,
   as long as they are clear to their users what those criteria are.
   The DNSBL user has the responsibility to ensure that the listing
   criteria and other aspects of a DNSBL meets its needs.

   This document is also intended to provide guidance to DNSBL
   administrators so that they may be able to identify what features
   users would be interested in seeing as part of a high-quality, well-
   managed DNSBL, e.g., a clear listing and delisting policy to which
   the DNSBL administrator adheres strictly.  This document is intended
   to be normative rather than prescriptive:  it seeks to characterize
   the features of a well-managed DNSBL rather than setting out rules
   for how DNSBLs should be operated.

1.2.  Guidance for DNSBL Users

   When choosing to adopt a DNSBL, an administrator should keep the
   following questions in mind:

   1.  What is the intended use of the list?
   2.  Does the list have a web site?
   3.  Are the list's policies stated on the web site?
   4.  Are the policies stated clearly and understandably?
   5.  Are web pages for removal requirements accessible and
       functioning properly?
   6.  How long has the list been in operation?
   7.  What are the demographics and quantity of the list's user base?
   8.  Are comparative evaluations of the list available?
   9.  What do your peers or members of the Internet community say
       about the list.
   
   It is the responsibility of the system administrators who adopt one
   or more DNSBLs to evaluate, understand, and make a determination of
   which DNSBLs are appropriate for the sites they administer.  If a
   system or network administrator allows a third party to make
   blocking decisions for its network, then the administrator MUST
   understand the policies and practices of those third parties
   because responsibility for blocking decisions remain ultimately
   with the administrator.  A DNSBL does not prevent anyone from
   receiving email or any other Internet service.  A DNSBL *user*
   prevents service delivery using the DNSBL as a tool for doing so.

   DNSBL administrators are merely expressing an opinion through the
   publication of a DNSBL, and it is their absolute right to do so
   free of legal encumbrance, and in violation of this BCP.  However,
   it is through abiding by the guidelines set forth in this BCP that
   the administrators of a DNSBL may gain the trust of their users.

   These guidelines address public DNSBLs only and do not apply to
   privately operated DNSBLs.

1.3. Terminology.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC 2119].
   
2. Background.

   The Anti Spam Research Group (ASRG) was chartered to address the
   spam problem. The ASRG charter includes:

      "codification of best current practices in spam management"
         
   This note falls within that category by listing guidelines for
   management of public DNSBLs. This document will seek BCP status.

   NOTE: This document is a product of the Anti-Spam Research Group
    (ASRG) of the IRTF. As per section 3 of [RFC 2014], IRTF
    groups do not require consensus to publish documents.
    Therefore readers should be aware that this document
    does not necessarily represent the consensus of the
    entire ASRG.
       
   NOTE: This document is intended to evolve, based on comments from
         the Anti-Spam Research Group (ASRG) mailing list. It is
         certain that the current draft is incomplete and entirely
         possible that it is inaccurate. Hence, comments are eagerly
         sought, preferably in the form of suggested text changes,
         and preferably on the ASRG mailing list, at <asrg@...>.


2.1. Transparency.

   A DNSBL SHOULD carefully describe the criteria which are the cause
   for adding, and the criteria for removing an IP address or domain
   name on the list.  Such listing and delisting criteria SHOULD be
   presented in a clear and readable manner easily accessible to the
   public through a mechanism such as the DNSBL's web site. A DNSBL
   MUST abide by its stated listing and delisting criteria.  Entries
   that do not meet the published criteria MUST NOT be added to the
DNSBL.
 
   In other words, be direct and honest and clear about the listing
   criteria, and make certain that only entries meeting the published
   criteria are added to the list.  For example, some DNSBL operators
   have been known to include spite listings in the lists they
administer.
   There is nothing inherently wrong with this practice so long as it
   is clearly disclosed.  For example, a DNSBL described as listing open
   relays only MUST NOT include IP addresses for any other reason.  This
   transparency principle does not require DNSBL administrators to
   disclose the precise algorithms and data involved in a listing.

   Availability of documentation concerning a DNSBL SHOULD NOT be
   dependent on the continued operation of DNS for the DNSBL zone file.
   In other words, if the DNSBL documentation is located at
   http://example.com/dnsbl/, the documentation web site SHOULD remain
   available even if the DNSBL zone file is not available. See also
   Section 3.2

2.1.2. Listing/Delisting Criteria SHOULD Be Easily Available.
   
   Listing and delisting criteria for DNSBLs SHOULD be easily
   available and SHOULD be located in a place clearly marked
   in its own section of the web site affiliated with the DNSBL.
   
   DNSBLs often publish their listing criteria along with
   additional technical information about using the blacklist. This
   additional technical information can confuse end users, so a
   separate page or section on its own SHOULD be dedicated to
   detailing why a specific entry appears in the DNSBL.

2.1.3. An Audit Trail SHOULD Be Maintained.

   A DNSBL SHOULD maintain an audit trail for all listings and SHOULD
   make it publicly available in an easy to find location, preferably
   on the DNSBL's web site.  Please note that making audit trail data
   public does not entail revealing all information in the DNSBL
   administrator's possession relating to the listing; e.g., a DNSBL
   administrator MAY make the audit trail data selectively accessible
   in such a way that spam trap addresses are not disclosed.

2.2  Listings and Removals

2.2.1.  Listings SHOULD Be Temporary.

   With the exception of DNSBLs that that are based on data that does
   not change, such as those include the IP addresses associated with
   a specific country or geographic region, all listings SHOULD be
   temporary so that an entry will time out at some point in the
   future. For more aggressive spammers (e.g., those operating their
   own ISP) the temporary period MAY be as much as six (6) months.  
   However, longer periods SHOULD NOT be used since it is possible
   that an IP address or domain can change hands, possibly being
   allocated to a non-abusive user.
 
   Note that all listings being temporary does not mean that some
   listings will not remain after the initial timeout period. If the
   DNSBL administrator determines that the conditions for listing
   still exists, then the timer for determining timeouts MAY be
   renewed.

2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be Available.

   Discussions about whether a DNSBL should remove an entry MAY
   include activity in a public forum.  Methods for processing
   removal requests through private, direct exchanges, such as
   person-to-person email or a combination of web page requests
   and email responses, SHOULD be available.  As a minimum, the
   DNSBL SHOULD have a web page that has a removal request function
   (separate from the page describing listing criteria as per
   section 2.1.2).  The DNSBL SHOULD also make available an email
   address in order to handle issues other than blocking issues.
   
   The DNSBL administrator MUST NOT use the list in question in such
   a way that removal requests would be blocked, and, moreover,
   SHOULD make unfiltered mailboxes available in order to allow
   affected users to submit their requests.  In some cases it is
   impractical not to filter email to role accounts due to the amount
   of spam those mailboxes receive.  If filtering should be necessary
   in such circumstances, filtering methods with virtually non-
   existent false positive rates SHOULD be chosen.

2.2.3.  Removals SHOULD Be Prompt.

   Requests for removal SHOULD be honored without question.
   Although this approach allows people to submit a request and have
   any listed IP address removed immediately, it does not prevent
   the DNSBL administrator from re-listing the IP address at a
   later time (for example: subject to seeing more spam, or
   re-checking the IP address security). A re-listing MAY result in
   a longer timeout until the listing expires before it is eligible
   for removal.  Bounded exponential backoff is a good choice for
   listing timeout.

   Assuming the above is not possible and no listing reasons remain,
   removal at anyone's request SHOULD be prompt.  Removal requests
   SHOULD be acted upon within a period of 24 hours, and SHOULD be
   handled within three (3) days.

   Most DNSBLs can effectively use a "no questions asked" removal
   policy because by their very nature they will redetect or relist
   problems almost immediately.  They can mitigate more organized
   attempts to "game" the system by elementary checking and rate-
   limiting procedures, increasing lockout periods, rescans etc.
   Furthermore, a few IP addresses more or less do not make a
   significant difference in the overall effectiveness of a DNSBL.
   Moreover, a "no questions asked" removal policy provides the
   huge benefit of a swift reaction to incorrect listings.

   As an example, one popular DNSBL implementing a "no questions
   asked" removal policy also performs rate-limiting and malicious
   removal detection.

   Another important consideration supporting a "no questions asked"
   self-removal policy is that it forestalls conflicts between DNSBL
   administrators and organizations whose IP addresses have been
   listed.  Such a policy also can be an effective deterrent to legal
   problems.


2.2.4  Criteria for Listing and Delisting SHOULD Be Similar

   The criteria for being removed from a DNSBL SHOULD bear a reasonable
   relationship to the factors which were the cause of the addition to
the
   DNSBL.  If a listed entity fulfills all published requirements for
   removal from a DNSBL, then the DNSBL administrator SHOULD NOT
   impose any additional obstacles to remove a given entry from
   the DNSBL.  There SHOULD NOT be any extra rules for de-listing
   other than the ones listed in the published listing criteria.
   
   In addition, it is RECOMMENDED that all listings SHOULD be temporary
   as described in section 2.2.1. For temporary listings, it is not
   necessary to correct the causes of the listing in order to be removed

   from the DNSBL.

2.2.5.  Removals SHOULD Be Possible in Absence of List Administrator.

   Removals SHOULD be possible in the absence of the list administrator.

   If removals cannot be automated (e.g., via robot re-testing) then the
   DNSBL SHOULD have multiple administrators so that a removal
   request can be processed if the principal list administrator is
   on vacation or otherwise unavailable.

3.  Operational Issues.

3.1. Inactively Maintained Lists SHOULD Cease Operations

   If a DNSBL is no longer actively maintained, it SHOULD cease
   operations in accordance with the principles set forth in section
   3.2.

3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.

   When a DNSBL ceases operations and is taken out of circulation,
   it MUST do so in a graceful manner so that it does not create
   excessive DNS queries or list the entire Internet.
   
   The recommended approach is to put the DNSBL in its own second
   level domain, and then point the DNS NS records for that second
   level domain to 127.255.255.255.  The TTL for that record should be
   set at the maximum allowed period of one week.

3.3. Content of DNSBL Zone File SHOULD Be Limited.

   The content of a DNSBL zone file SHOULD be limited to DNSBL entries
   and relevant control information such as the TTL for the entry,
   explanatory TXT records, etc.  By virtue of using domain names, a
   DNSBL is a hierarchy with a root anchored in the global Internet.
   The DNSBL "query root" SHOULD be below the registered domain, so
   that the DNSBL information is not conflated with domain housekeeping
   information (e.g., name server, MX or SPF records).  By using this
   approach, DNSBL queries would take the form of
   "<query>.dnsbl.example.com" rather than "<query>.example.com".
   Further, this sub-tree should occupy its own zone.  This approach
   facilitates clear delineation of function as well as
   orderly DNSBL shutdown because the DNSBL nameserver records can be
   specified separately from the domain's principal nameservers.

3.4.  Special and Reserved IP Addresses MAY Be Used.

   The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
   any other permanently reserved or special-use IP addresses.  Such
   use MUST be disclosed in the documentation related to the DNSBL.
   Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
   to provide online indication of whether the DNSBL is operational.  
   In particular, most DNSBLs use a positive response for 127.0.0.2
   for this.  See reference [DNSBL-EMAIL] for additional information.

3.5. Use of Collateral Damage MUST Be Disclosed.

   Some DNSBLs have adopted a policy of using "collateral damage" as
   an intentional element of the list's operation.  When collateral
   damage is applied, a DNSBL listing is expanded to include IP
addresses
   under the control of a provider even though those IP addresses are
   not the source of abusive email.  The theory is that customers
   impacted by collateral damage will bring pressure upon the provider
   to take action against the customer which is the cause of the
   original listing.

   Collateral damage as a DNSBL policy is highly controversial, and
   discussion of the appropriateness of this policy is beyond the scope
   of this document.  However, if a DNSBL has policies and practices
   that include the imposition of collateral damage, such policies
   MUST be disclosed.

3.6.  Considerations for DNSBLs Listing Insecure Hosts.

   Some DNSBLs list IP addresses of hosts that are insecure
   in various ways (e.g. open relays, open proxies).  The following
   recommendations for such DNSBLs may not be relevant to
   regular DNSBLs.

3.6.1. MUST NOT scan without provocation.

   DNSBLs MUST NOT automatically probe for insecure systems without
   provocation. There is little agreement in the community as to whether

   or not such activity should be allowed, so this BCP adopts a more
   conservative policy.
   
   Therefore, scanning MUST be be targeted, rather than broad-based,
   with a given scan motivated by a specific reason to have concern
   about the IP address being scanned.  Examples of such reasons
   include delivery of a message to a spam trap address, receipt of
   a user complaint, or periodic testing of an IP address that is
   listed already.

     
3.6.2. Re-scan Periods SHOULD be Reasonable.

   If the DNSBL administrator re-scans a host in order to determine
   whether the listing SHOULD timeout or not, the re-scan period
   SHOULD be reasonable.  Automated re-scans SHOULD NOT occur more
   often than once every 24 hours.

4. Security Considerations

   Like all DNS-based mechanisms, DNSBLs are subject to various
   threats outlined in [RFC 3833].
   
5. Informative References

   [RFC 2026] Bradner, S., "The Internet Standards Process
   -- Revision 3", BCP9, RFC 2026, October 1996.

   [RFC 2014] Weintrib, A., Postel, J,; "IRTF Research Group
   Guidelines and Procedures", BCP 8, RFC 2014, October 1996

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997
 
   [RFC 3833] Atkins, D. and Austein, R.; "Threat Analysis of the
   Domain Name System", RFC 3833, August 2004

   [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and
   Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005

6. Author(s) Addresses.

     Yakov Shafranovich (Editor)
     SolidMatrix Technologies, Inc.
     research@...
     www.shaftek.org

     Nick Nicholas (Editor)
     Habeas, Inc.
     nick@...

     Chris Lewis
     Nortel Networks
     clewis@...

     Matt Sergeant
     MessageLabs, Inc.
     msergeant@...
     
     
8. Acknowledgements.

   We would like to thank John R. Levine, Alan Murphy and Dave
   Crocker for their insightful comments.

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

9. Full Copyright Statement.


   Full Copyright Statement

   Copyright (C) The Internet Society (2007). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Frank Ellermann]

Nick Nicholas wrote:

> you may make your comments inline if desired

Okay, you get it then in source order, from typo to whatever
else I might see.

>  whitelists of of IP addresses or domains. This memo discusses

s/of of/of/

>    create and maintain DNS-based reputation systems ("DNSBL") of IP
>    addresses and domains identified as problem sources of email.  These

Some DNSBLs are in fact "DNS based lists" used for other purposes
like Geo location.  If you haven't done it later you could note
that you're not talking about the general "DNSBL" concept.

>    These DNSBLs vary widely in integrity, strategy, methodology and

s/These//  They all vary widely.

>    7.  What are the demographics and quantity of the list's user base?

How are admins supposed to evaluate this ?  Sounds bogus for me.

>    9.  What do your peers or members of the Internet community say
>        about the list.

They all say it's bad for various conflicting reasons, none of them
related to any incident in the last five years.

>    If a system or network administrator allows a third party to make
>    blocking decisions for its network, then the administrator MUST
>    understand the policies and practices of those third parties
>    because responsibility for blocking decisions remain ultimately
>    with the administrator.

Yes.  And actually a list does NEVER make blocking decisions for a
list user, because nobody is forced to use it.  How about "uses the
proposals of a third party to make blocking decisions".

>    These guidelines address public DNSBLs only and do not apply to
>    privately operated DNSBLs.

s/do/may/ ?  Some proposals should also make sense for private lists.

>         Therefore readers should be aware that this document
>         does not necessarily represent the consensus of the
>         entire ASRG.

Is that necessary ?  As a BCP it will have IETF consensus no matter
what the ASRG situation might be.

>    public through a mechanism such as the DNSBL's web site. A DNSBL

s/through a mechanism such as/on /  No nonsense please, if it has no
Web site it's anyway bogus.

>    Availability of documentation concerning a DNSBL SHOULD NOT be
>    dependent on the continued operation of DNS for the DNSBL zone file.
>    In other words, if the DNSBL documentation is located at
>    http://example.com/dnsbl/, the documentation web site SHOULD remain
>    available even if the DNSBL zone file is not available.

I don't get this, if the list works like 2.0.0.127.example.net, then the
accompanying Web site SHOULD be located at http://example.net  Otherwise
the list is bogus and SHOULD NOT be used.  Of course it's fine if it has
other URLs for its policy.

>    With the exception of DNSBLs that that are based on data that does
>    not change, such as those include the IP addresses associated with
>    a specific country or geographic region

s/include/listing/ (?)

>    future. For more aggressive spammers (e.g., those operating their
>    own ISP) the temporary period MAY be as much as six (6) months.

+    own ISP) the temporary period could be considerably longer (e.g.,
+    weeks) as stated in the listing policy.

I don't get the idea of an arbitrary magic number "6 months".  For a
list with say bogon IPs it would be "as long as necessary", unlimited.
You address this later, but IMO no fixed limit also here is clearer.

>    However, longer periods SHOULD NOT be used since it is possible
>    that an IP address or domain can change hands, possibly being
>    allocated to a non-abusive user.

Add "unless it's the stated list policy to cause collateral damage
for users getting their IPs from spam-supporting organizations."

>    re-checking the IP address security). A re-listing MAY result in
>    a longer timeout until the listing expires before it is eligible
>    for removal.  Bounded exponential backoff is a good choice for
>    listing timeout.

ACK, and that upper limit could be worse than six months.

> 2.2.5.  Removals SHOULD Be Possible in Absence of List Administrator.

>    Removals SHOULD be possible in the absence of the list administrator.

Delete this line.

>    The recommended approach is to put the DNSBL in its own second
>    level domain, and then point the DNS NS records for that second
>    level domain to 127.255.255.255.  The TTL for that record should be
>    set at the maximum allowed period of one week.

Intersting, many DNS details are still a kind of mystery for me, users
would then try to ask a name server at 127.255.255.255, and because
that's a broadcast address on their own LAN they'd get an error, is
that the idea ?   Was that concept already tested anywhere ?

>    "<query>.dnsbl.example.com" rather than "<query>.example.com".

That's what I meant above, http://dnsbl.example.com for the Web site,
and other URLs for the case when the list is terminated.  Ideally as
redirection (moved permanently) to the more persistent URL.

>    The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
>    any other permanently reserved or special-use IP addresses.

No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
limit it as good as you can).

>    Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8

Indeed, and anything else is just wrong.

>    In particular, most DNSBLs use a positive response for 127.0.0.2

s/most/many/ and s/for/of/  You should also mention that lists SHOULD
support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
opposite (never listed), without ever returning 127.0.0.1 as a result.

>    for this.  See reference [DNSBL-EMAIL] for additional information.

Maybe that's not more needed if you explain the trivial concepts here.

>    [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and
>    Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005

If you keep RFC 1918 you've to list it as reference.  RFC 2119 should
be noted as normative - I think you've somehow lost the section with
normative references.

Nice draft, I like it, thanks,

 Frank



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Tony Finch]

"Nick Nicholas" <Nick@...> wrote:
>

The draft looks pretty sensible to me.

>1.1.  DNS-Based Reputation Systems
>
>   DNSBLs are either public or
>   private.  A public DNSBL makes its data available to any party
>   seeking information from the list, but a private DNSBL is used=20
>   solely by an organization for its own use and the data is not made=20
>   available publicly.

There are also commercial DNSBLs which are public except that "any party"
must be willing and able to pay.

>2.2.1.  Listings SHOULD Be Temporary.
>
>   With the exception of DNSBLs that that are based on data that does
>   not change, such as those include the IP addresses associated with=20
>   a specific country or geographic region, all listings SHOULD be=20
>   temporary so that an entry will time out at some point in the=20
>   future.

IP addresses can move country or region - consider an international ISP.
I don't think there are any certain unchanging attributes of IP addresses.

>2.2.3.  Removals SHOULD Be Prompt.
>
>   Requests for removal SHOULD be honored without question.

I think this requirement needs more hedging, since it depends on the
DNSBL listing policy. For example, the requirement is not appropriate
if the listing is based on who the address space has been allocated to,
especially if the reason is that it has been allocated to criminals.
In that case you expect to come into conflict with people who are listed.

>3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>
>   When a DNSBL ceases operations and is taken out of circulation,
>   it MUST do so in a graceful manner so that it does not create=20
>   excessive DNS queries or list the entire Internet.

What do you mean by "excessive"? Is this a reference to insane DNS
clients that generate more traffic when a DNS server goes away?

>4. Security Considerations
>
>   Like all DNS-based mechanisms, DNSBLs are subject to various=20
>   threats outlined in [RFC 3833].

The recommendations for DNSBL users should be in this section.  It's worth
emphasizing that spam is a security problem and that DNSBLs are one
of many ways to tackle it. DNSBLs usually relate to the SMTP client,
which can have a limited relationship to the origin of the message if
the client is relaying or forwarding. However RHSBLs exist as well,
which have no guaranteed relationship to the client or the origin of
the message, but can still be useful.

Tony.
--
f.a.n.finch  <dot@...>  http://dotat.at/
HUMBER: NORTHWESTERLY 5 OR 6. MODERATE OR ROUGH. WINTRY SHOWERS. GOOD.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 8-Feb-07, at 7:27 PM, Frank Ellermann wrote:

>>    create and maintain DNS-based reputation systems ("DNSBL") of IP
>>    addresses and domains identified as problem sources of email.  
>> These
>
> Some DNSBLs are in fact "DNS based lists" used for other purposes
> like Geo location.  If you haven't done it later you could note
> that you're not talking about the general "DNSBL" concept.

I think we entirely cover that under 2.2.1. Please let us know if you  
think we don't.

>>    7.  What are the demographics and quantity of the list's user  
>> base?
>
> How are admins supposed to evaluate this ?  Sounds bogus for me.

Certainly easy to lie about, but a BCP doesn't cover lying. It could  
certainly be stated on the DNSBL's web page, or could be stated on a  
separate page on whichdnsbl.com (yes, I made that up, though it is  
available!).

>>    9.  What do your peers or members of the Internet community say
>>        about the list.
>
> They all say it's bad for various conflicting reasons, none of them
> related to any incident in the last five years.

:-) Not sure how we could encode that in a BCP.

>>    If a system or network administrator allows a third party to make
>>    blocking decisions for its network, then the administrator MUST
>>    understand the policies and practices of those third parties
>>    because responsibility for blocking decisions remain ultimately
>>    with the administrator.
>
> Yes.  And actually a list does NEVER make blocking decisions for a
> list user, because nobody is forced to use it.  How about "uses the
> proposals of a third party to make blocking decisions".

Not sure which part you think is badly worded here. Please elaborate.

>>    These guidelines address public DNSBLs only and do not apply to
>>    privately operated DNSBLs.
>
> s/do/may/ ?  Some proposals should also make sense for private lists.

Possibly, but that is not the intention, and is not something we  
could BCP about IMHO. If a private entity wishes to follow these  
ideas then that's fantastic, but not what this BCP is about.

>>         Therefore readers should be aware that this document
>>         does not necessarily represent the consensus of the
>>         entire ASRG.
>
> Is that necessary ?  As a BCP it will have IETF consensus no matter
> what the ASRG situation might be.

I think this is just draft preamble, required for discussion here.

>>    public through a mechanism such as the DNSBL's web site. A DNSBL
>
> s/through a mechanism such as/on /  No nonsense please, if it has no
> Web site it's anyway bogus.

It's entirely conceivable that a DNSBL's public presence might be  
purely a yahoo-groups mailing list, or NANABL, or some-such. With  
FAQs and listing criteria regularly published to such locations.

>>    Availability of documentation concerning a DNSBL SHOULD NOT be
>>    dependent on the continued operation of DNS for the DNSBL zone  
>> file.
>>    In other words, if the DNSBL documentation is located at
>>    http://example.com/dnsbl/, the documentation web site SHOULD  
>> remain
>>    available even if the DNSBL zone file is not available.
>
> I don't get this, if the list works like 2.0.0.127.example.net,  
> then the
> accompanying Web site SHOULD be located at http://example.net   
> Otherwise
> the list is bogus and SHOULD NOT be used.  Of course it's fine if  
> it has
> other URLs for its policy.

There are major problems with this. What if you decide to stop  
running the DNSBL? See section 3.2. I see no reason to remove this  
section.

>>    With the exception of DNSBLs that that are based on data that does
>>    not change, such as those include the IP addresses associated with
>>    a specific country or geographic region
>
> s/include/listing/ (?)

Good catch. Thank you.

>>    future. For more aggressive spammers (e.g., those operating their
>>    own ISP) the temporary period MAY be as much as six (6) months.
>
> +    own ISP) the temporary period could be considerably longer (e.g.,
> +    weeks) as stated in the listing policy.
>
> I don't get the idea of an arbitrary magic number "6 months".  For a
> list with say bogon IPs it would be "as long as necessary", unlimited.
> You address this later, but IMO no fixed limit also here is clearer.

We've mulled over this a lot. Gone back and forth. In the end we said  
6 months because if we put no limit on then it's no help - a DNSBL  
could just set the limit at 30 years.  6 months is reasonable for a  
long listing, and this is very well covered by the last point in this  
section - that a temporary listing can easily be extended by (for  
example) receiving more spam from this IP/range.

>>    However, longer periods SHOULD NOT be used since it is possible
>>    that an IP address or domain can change hands, possibly being
>>    allocated to a non-abusive user.
>
> Add "unless it's the stated list policy to cause collateral damage
> for users getting their IPs from spam-supporting organizations."

Even the organisation can change hands. See above.

>> 2.2.5.  Removals SHOULD Be Possible in Absence of List Administrator.
>
>>    Removals SHOULD be possible in the absence of the list  
>> administrator.
>
> Delete this line.

Yup.

>>    The recommended approach is to put the DNSBL in its own second
>>    level domain, and then point the DNS NS records for that second
>>    level domain to 127.255.255.255.  The TTL for that record  
>> should be
>>    set at the maximum allowed period of one week.
>
> Intersting, many DNS details are still a kind of mystery for me, users
> would then try to ask a name server at 127.255.255.255, and because
> that's a broadcast address on their own LAN they'd get an error, is
> that the idea ?   Was that concept already tested anywhere ?

It has been discussed both here and in many other places.

>>    "<query>.dnsbl.example.com" rather than "<query>.example.com".
>
> That's what I meant above, http://dnsbl.example.com for the Web site,
> and other URLs for the case when the list is terminated.  Ideally as
> redirection (moved permanently) to the more persistent URL.

Not sure what you mean here. Hopefully you're agreeing with what I  
said above.

>>    The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
>>    any other permanently reserved or special-use IP addresses.
>
> No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
> abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
> limit it as good as you can).

list != result. We're not talking about the result IP here. Just what  
can be present in the DNSBL.

>>    Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
>
> Indeed, and anything else is just wrong.

Possibly/probably yeah. But this BCP doesn't cover that.

>>    In particular, most DNSBLs use a positive response for 127.0.0.2
>
> s/most/many/ and s/for/of/

I think "most" is fine. The second change is correct.

> You should also mention that lists SHOULD
> support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
> opposite (never listed), without ever returning 127.0.0.1 as a result.

Good point. We'll consider adding that. It's a good test for DNSBL  
validity.

>>    for this.  See reference [DNSBL-EMAIL] for additional information.
>
> Maybe that's not more needed if you explain the trivial concepts here.
>
>>    [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and
>>    Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005
>
> If you keep RFC 1918 you've to list it as reference.  RFC 2119 should
> be noted as normative - I think you've somehow lost the section with
> normative references.
>
> Nice draft, I like it, thanks,

Thanks for your comments. Very useful.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 8-Feb-07, at 9:20 PM, Tony Finch wrote:

>> 1.1.  DNS-Based Reputation Systems
>>
>>   DNSBLs are either public or
>>   private.  A public DNSBL makes its data available to any party
>>   seeking information from the list, but a private DNSBL is used=20
>>   solely by an organization for its own use and the data is not  
>> made=20
>>   available publicly.
>
> There are also commercial DNSBLs which are public except that "any  
> party"
> must be willing and able to pay.

I guess better wording might be: "but a private DNSBL restricts who  
has access to querying the list."

>> 2.2.1.  Listings SHOULD Be Temporary.
>>
>>   With the exception of DNSBLs that that are based on data that does
>>   not change, such as those include the IP addresses associated  
>> with=20
>>   a specific country or geographic region, all listings SHOULD be=20
>>   temporary so that an entry will time out at some point in the=20
>>   future.
>
> IP addresses can move country or region - consider an international  
> ISP.
> I don't think there are any certain unchanging attributes of IP  
> addresses.

I'd like to get more comment on that. Even international ISPs assign  
IP ranges within their country boundaries.

>> 2.2.3.  Removals SHOULD Be Prompt.
>>
>>   Requests for removal SHOULD be honored without question.
>
> I think this requirement needs more hedging, since it depends on the
> DNSBL listing policy. For example, the requirement is not appropriate
> if the listing is based on who the address space has been allocated  
> to,
> especially if the reason is that it has been allocated to criminals.
> In that case you expect to come into conflict with people who are  
> listed.

I strongly believe this is covered by the verbiage in this section.  
Should a criminal spammer find himself listed in the SBL (for  
example), he should be allowed to immediately request removal, and be  
granted that. As soon as he spams, he should be immediately relisted.  
And the limits on removals be made harder for him/her - see the  
second to last sentence in that first paragraph. The intention is to  
make innocent listings easy to remove, and criminal listings harder  
to remove.

>> 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>>
>>   When a DNSBL ceases operations and is taken out of circulation,
>>   it MUST do so in a graceful manner so that it does not create=20
>>   excessive DNS queries or list the entire Internet.
>
> What do you mean by "excessive"? Is this a reference to insane DNS
> clients that generate more traffic when a DNS server goes away?

A typical example of shutting down a DNSBL would involve setting the  
TTL to a very high value, to limit the number of queries that result.

>> 4. Security Considerations
>>
>>   Like all DNS-based mechanisms, DNSBLs are subject to various=20
>>   threats outlined in [RFC 3833].
>
> The recommendations for DNSBL users should be in this section.  
> It's worth
> emphasizing that spam is a security problem and that DNSBLs are one
> of many ways to tackle it. DNSBLs usually relate to the SMTP client,
> which can have a limited relationship to the origin of the message if
> the client is relaying or forwarding. However RHSBLs exist as well,
> which have no guaranteed relationship to the client or the origin of
> the message, but can still be useful.

I'm not sure we want to venture into that cesspool :-) But I'm  
willing to be persuaded otherwise.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 8, 2007, at 4:27 PM, Frank Ellermann wrote:

> Nick Nicholas wrote:
>
>>    7.  What are the demographics and quantity of the list's user  
>> base?
>
> How are admins supposed to evaluate this ?  Sounds bogus for me.

Perhaps whether a particular geographic area or type of enterprise
is being served?

>>    9.  What do your peers or members of the Internet community say
>>        about the list.
>
> They all say it's bad for various conflicting reasons, none of them
> related to any incident in the last five years.

This is not something one should believe from the DNSRBL operator,
so why make this a requirement?

>>    If a system or network administrator allows a third party to make
>>    blocking decisions for its network, then the administrator MUST
>>    understand the policies and practices of those third parties
>>    because responsibility for blocking decisions remain ultimately
>>    with the administrator.
>
> Yes.  And actually a list does NEVER make blocking decisions for a
> list user, because nobody is forced to use it.  How about "uses the
> proposals of a third party to make blocking decisions".

It might even be better to only call this a blocklist or black-hole
list, rather than a blacklist.  These two areas provide grounds
for meaningless legal tussles designed to waste money.  Who is
blocking is an important concept to clarify, as well that a block-list
is not "blacklisting" as often defined in the law.

>>    These guidelines address public DNSBLs only and do not apply to
>>    privately operated DNSBLs.
>
> s/do/may/ ?  Some proposals should also make sense for private lists.
>
>>    public through a mechanism such as the DNSBL's web site. A DNSBL
>
> s/through a mechanism such as/on /  No nonsense please, if it has no
> Web site it's anyway bogus.

It might become a required strategy to not rely upon web sites when they
become DDoS targets.  It seems contacts should be generalized to allow
greater flexibility.

>>    Availability of documentation concerning a DNSBL SHOULD NOT be
>>    dependent on the continued operation of DNS for the DNSBL zone  
>> file.
>>    In other words, if the DNSBL documentation is located at
>>    http://example.com/dnsbl/, the documentation web site SHOULD  
>> remain
>>    available even if the DNSBL zone file is not available.
>
> I don't get this, if the list works like 2.0.0.127.example.net,  
> then the
> accompanying Web site SHOULD be located at http://example.net   
> Otherwise
> the list is bogus and SHOULD NOT be used.  Of course it's fine if  
> it has
> other URLs for its policy.

There are TXT records that might accompany the IP address information  
that
can provide contact information.  Of course it would be rather painful
should the contact information be an 800 phone number.

>>    future. For more aggressive spammers (e.g., those operating their
>>    own ISP) the temporary period MAY be as much as six (6) months.
>
> +    own ISP) the temporary period could be considerably longer (e.g.,
> +    weeks) as stated in the listing policy.
>
> I don't get the idea of an arbitrary magic number "6 months".  For a
> list with say bogon IPs it would be "as long as necessary", unlimited.
> You address this later, but IMO no fixed limit also here is clearer.

Frank is right.  6 months does not make much sense.  Such a set
interval can be rather easily gamed.  A good operation will apply
different criteria for various networks regarding such intervals as well
as requests for delisting.  The level of cooperation varies widely and
this too affects these parameters.

>>    However, longer periods SHOULD NOT be used since it is possible
>>    that an IP address or domain can change hands, possibly being
>>    allocated to a non-abusive user.
>
> Add "unless it's the stated list policy to cause collateral damage
> for users getting their IPs from spam-supporting organizations."

How about:

A listing should not extend beyond what the operator has determined
to be beyond that offering a reasonable expectation that the
address is likely to be under different administration.  The operator
may make exceptions based upon various factors, such as the past
behavior of the network's management across the related addresses.

>>    re-checking the IP address security). A re-listing MAY result in
>>    a longer timeout until the listing expires before it is eligible
>>    for removal.  Bounded exponential backoff is a good choice for
>>    listing timeout.
>
> ACK, and that upper limit could be worse than six months.
>

s/exponential backoff/exponentially extended periods/

>> 2.2.5.  Removals SHOULD Be Possible in Absence of List Administrator.
>
>>    Removals SHOULD be possible in the absence of the list  
>> administrator.
>
> Delete this line.

Agreed.

---
3.3. Content of DNSBL Zone File SHOULD Be Limited.

The DNSBL "query root" SHOULD be below the registered domain, so
that the DNSBL information is not conflated with domain housekeeping
information (e.g., name server, MX or SPF records).  By using this
approach, DNSBL queries would take the form of
"<query>.dnsbl.example.com" rather than "<query>.example.com".
---

This would be a problem only when zone transfers are used to distribute
data.

> That's what I meant above, http://dnsbl.example.com for the Web site,
> and other URLs for the case when the list is terminated.  Ideally as
> redirection (moved permanently) to the more persistent URL.
>
>>    The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
>>    any other permanently reserved or special-use IP addresses.
>
> No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
> abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
> limit it as good as you can).
>
>>    Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
>
> Indeed, and anything else is just wrong.
>
>>    In particular, most DNSBLs use a positive response for 127.0.0.2
>
> s/most/many/ and s/for/of/  You should also mention that lists SHOULD
> support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
> opposite (never listed), without ever returning 127.0.0.1 as a result.

Just exclude 127.0.0.1 to prevent exploits that might rely upon an
unexpected self references from an otherwise trusted domain.

---
There is nothing inherently wrong with this practice so long as it
is clearly disclosed.  For example, a DNSBL described as listing open
relays only MUST NOT include IP addresses for any other reason.  This
transparency principle does not require DNSBL administrators to
disclose the precise algorithms and data involved in a listing.
---

s/as listing open relays/as only listing open relays/

---
2.1.3. An Audit Trail SHOULD Be Maintained.

A DNSBL SHOULD maintain an audit trail for all listings and SHOULD
make it publicly available in an easy to find location, preferably
on the DNSBL's web site.  Please note that making audit trail data
public does not entail revealing all information in the DNSBL
administrator's possession relating to the listing; e.g., a DNSBL
administrator MAY make the audit trail data selectively accessible
in such a way that spam trap addresses are not disclosed.
---

It is not possible to disclose _any_ email information without also
disclosing where the message was obtained.  It is simply impossible
to fully redact a message to provide such an assurance of
non-disclosure.

How about:

An operator should maintain an audit trail for their own private
use.  This information should _not_ be made public unless the
entity making the request is considered trustworthy.

In response to Tony:

A list closed to only those that enter into a contract is not a
"public" DNSRBL.  A contract supersedes casual expectations
expressed in this document.

-Doug




_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Bill Cole-2]

At 1:22 PM -0800 2/8/07, Nick Nicholas wrote:

>Greetings:
>
>With much help from the authors as well as the ASRG chair and Dave
>Crocker, I have finally completed the revisions to the DNSBL BCP.  A
>copy is beneath my .sig so that you may make your comments inline if
>desired.  I tried to include as many comments as possible from the
>discussion of the previous draft, but the authors and the editor deemed
>it was necessary to decline to use some of the suggestions.
>
>Flame away!  I'm wearing my Nomex suit.  :-)

Just a couple of minor quibbles:



>3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>
>    When a DNSBL ceases operations and is taken out of circulation,
>    it MUST do so in a graceful manner so that it does not create
>    excessive DNS queries or list the entire Internet.
>
>    The recommended approach is to put the DNSBL in its own second
>    level domain, and then point the DNS NS records for that second
>    level domain to 127.255.255.255.

s/to/to a hostname that resolves to/

It's amazing how many people think that's it's OK to point an NS
record at an IP address...


>   The TTL for that record should be
>    set at the maximum allowed period of one week.


One week is NOT the maximum value for a TTL. One week is the top
value that BIND will honor. TTL's can in theory be about 68 years
(2147483647.)  Alternate wording:

    The TTL field for the NS record and the A record it points to should
    be set to 604800 (one week) because larger values are not universally
    honored.




--
Bill Cole
bill@...


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 8-Feb-07, at 11:21 PM, Douglas Otis wrote:

>> I don't get the idea of an arbitrary magic number "6 months".  For a
>> list with say bogon IPs it would be "as long as necessary",  
>> unlimited.
>> You address this later, but IMO no fixed limit also here is clearer.
>
> Frank is right.  6 months does not make much sense.

Please re-respond in light of my response to Frank here.

> ---
> 3.3. Content of DNSBL Zone File SHOULD Be Limited.
>
> The DNSBL "query root" SHOULD be below the registered domain, so
> that the DNSBL information is not conflated with domain housekeeping
> information (e.g., name server, MX or SPF records).  By using this
> approach, DNSBL queries would take the form of
> "<query>.dnsbl.example.com" rather than "<query>.example.com".
> ---
>
> This would be a problem only when zone transfers are used to  
> distribute
> data.

... which covers all public DNSBLs, surely? Or at least those that  
have any hope of becoming popular (i.e. those that follow best  
practices). I don't see any reason you'd want to remove this section.

> ---
> There is nothing inherently wrong with this practice so long as it
> is clearly disclosed.  For example, a DNSBL described as listing open
> relays only MUST NOT include IP addresses for any other reason.  This
> transparency principle does not require DNSBL administrators to
> disclose the precise algorithms and data involved in a listing.
> ---
>
> s/as listing open relays/as only listing open relays/

Good.

> ---
> 2.1.3. An Audit Trail SHOULD Be Maintained.
>
> A DNSBL SHOULD maintain an audit trail for all listings and SHOULD
> make it publicly available in an easy to find location, preferably
> on the DNSBL's web site.  Please note that making audit trail data
> public does not entail revealing all information in the DNSBL
> administrator's possession relating to the listing; e.g., a DNSBL
> administrator MAY make the audit trail data selectively accessible
> in such a way that spam trap addresses are not disclosed.
> ---
>
> It is not possible to disclose _any_ email information without also
> disclosing where the message was obtained.  It is simply impossible
> to fully redact a message to provide such an assurance of
> non-disclosure.

Hence why this is a SHOULD not a MUST. It's a tricky line - compare  
for example the disclosure given by PSBL (almost full spamtrap hit  
contents) vs SBL. Both presumably maintain an internal audit trail,  
but one is public and one is private, but both are reasonably well  
run DNSBLs.

Matt.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Daniel Feenberg]

On Thu, 8 Feb 2007, Matt Sergeant wrote:

>>>
>>>  Requests for removal SHOULD be honored without question.
>>
>> I think this requirement needs more hedging, since it depends on the
>> DNSBL listing policy. For example, the requirement is not appropriate
>> if the listing is based on who the address space has been allocated to,
>> especially if the reason is that it has been allocated to criminals.
>> In that case you expect to come into conflict with people who are listed.
>
> I strongly believe this is covered by the verbiage in this section. Should a
> criminal spammer find himself listed in the SBL (for example), he should be
> allowed to immediately request removal, and be granted that. As soon as he
> spams, he should be immediately relisted. And the limits on removals be made
> harder for him/her - see the second to last sentence in that first paragraph.
> The intention is to make innocent listings easy to remove, and criminal
> listings harder to remove.
>

Is this always desirable? Does anyone here have any statistics about how
long a spammer can spam on average before being picked up by DNSBLs? My
impression from our use of Spamhaus is that detection is slow. On our
system with about a 1,000 active mail accounts only about 1% of spam
source IP addresses were seen more than once in the test week, suggesting
to me that it would be difficult to tell if spamming had ceased in less
than several months unless one had a very large set of spam traps.

If removal must be automatic, doesn't that unnecesarily give the spammer
twice as long on the IP address? It seems like that would double the
amount of uncaught spam. I would have thought that confirming a delisting
with the ASN abuse contact or providing reverse name look to a non-generic
host name would be reasonable precaustions a DNSBL might wish to impose
before delisting an address, and that in any case it should be up to list
policy.

There is a principle of statistics that if your detector sees only a small
fraction of events, then variation in the rate is mostly random, and not
evidence of variation in the underlying process.

Daniel Feenberg


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Frank Ellermann]

Matt Sergeant wrote:

>> Some DNSBLs are in fact "DNS based lists" used for other purposes
>> like Geo location.  If you haven't done it later you could note
>> that you're not talking about the general "DNSBL" concept.

> I think we entirely cover that under 2.2.1. Please let us know if
> you think we don't.

Yes, I read it top down, and the first definition sounded like "it's
only about 'B' as in 'bl[ao]ck'".  Later you have "or anything" with
a 'B' as in 'based'.  IP-based geo-location - as far as you believe
in it - can be completely unrelated to 'bl[oa]ck'.

If you want to cover the latter maybe state it earlier, before 2.2.1.
It's certainly a nice example why decisions to block "countries" by
IP could indicate a dangerous degree of ignorance on the side of the
list user.  The location could be wrong, it could change any time,
and if users block complete countries they MUST NOT send any abuse
reports to mailboxes in this country while they block the replies.

That's a general principle, if users block something they MUST NOT
send mails to the (from their POV) blackholes, replies won't work.
You could recommend that users blocking IPs should also refuse to
transport messages to the blackhole.

>>>    9.  What do your peers or members of the Internet community say
>>>        about the list.

>> They all say it's bad for various conflicting reasons, none of them
>> related to any incident in the last five years.

> :-) Not sure how we could encode that in a BCP.

How about simply removing (7) and (9) ?  Or replace it by a general
advice "try to find and evaluate opinions of third parties about the
list in question".  My interpretation of (7) would cover "OPM is for
IRC geeks, therefore it can't be good".  And that's wrong.  For (9)
I got "read NANAE", but admins should not waste time there, unless
they really like it.

  [about "allows a third party to make blocking decisions"]
>> actually a list does NEVER make blocking decisions for a list
>> user, because nobody is forced to use it.  How about "uses the
>> proposals of a third party to make blocking decisions".

> Not sure which part you think is badly worded here. Please elaborate.

- If a system or network administrator allows a third party to make
- blocking decisions for its network, then the administrator MUST
[...]
+ If a system or network administrator uses the proposals of a third
+ party to make blocking decisions, then the administrator MUST
[...]

>> s/through a mechanism such as/on/  No nonsense please, if it has
>> no Web site it's anyway bogus.

> It's entirely conceivable that a DNSBL's public presence might be
> purely a yahoo-groups mailing list, or NANABL, or some-such.

No, this is not entirely conceivable for a DNSBL with its own zone.
If it can answer queries for 2.0.0.127.dnsbl.example "hosts", then
it can also answer a query for host dnsbl.example, and they can
then arrange that "GET dnsbl.example HTTP/1.0" returns something
useful.  If it's a FAQ explaining how to use a YahoGroup or NANABl
it's not ideal, but acceptable as least common denominator.

It's a good convention, it should be recommended.  My attempts to
convince Jeff that say http://multi.surbl.org should work, and that
http://surbl.org (without "www" label) should of course also work,
failed.  But maybe he'll believe it if you state it as SHOULD... :-)

A low hanging fruit, please don't miss it.  It also simplifies the
documentation of tools querying DNSBLs, "... queries x.y.example,
for technical listing details see http://y.example".  If it's not
predictable where a DNSBL has at least a HTTP redirection to its
policy it only makes the maintenance of such tools more difficult.

 [upper limit for a listing]
> We've mulled over this a lot. Gone back and forth. In the end we
> said 6 months because if we put no limit on then it's no help - a
> DNSBL could just set the limit at 30 years.

Yes, I'm not very happy with RFCI listings where the evidence is
several years old (of course RFCI is a set of RHSBLs today, no more
DNSBL, and likewise SURBL is no real DNSBL, but most parts of your
draft also work for RHSBLs).

But "6 months" is still an unnecesary magic number.  If it's the
stated listing policy to note "postmaster@ bounced 2003-04-01, and
will be listed until they request it in a MAIL FROM postmaster@, and
click on an URL in the reply", then that's as it is, not nice, but
also not unreasonable.  Maybe what you really want is that lists
MUST publish the upper limit in their policy (?)

> this is very well covered by the last point in this section -
> that a temporary listing can easily be extended by (for example)
> receiving more spam from this IP/range.

Yes, a second case where reading the I-D bottom up could be better
than top down <gd&r>  If you insist on a magic number 6 months is
certainly long enough, maybe already too long.

>>> However, longer periods SHOULD NOT be used since it is possible
>>> that an IP address or domain can change hands, possibly being
>>> allocated to a non-abusive user.

>> Add "unless it's the stated list policy to cause collateral damage
>> for users getting their IPs from spam-supporting organizations."

> Even the organisation can change hands. See above.

Caveat emptor.  If a tainted IP is worthless, this could be a part
of the "excommunication after XAB" concept.  Maybe only RIRs can
clean tainted IPs.  Of course users need to know that they're in
for a fundamentalistic armageddon with this approach.

  [127.255.255.255]
>> Was that concept already tested anywhere ?
> It has been discussed both here and in many other places.

If the "namedroppers" and similar cabals like it it's fine.

 [RFC 1918]
> list != result. We're not talking about the result IP here.

Sorry, I got that wrong.  If a DNSBL lists private IPs in addition
to the known 127.0.0.2 test entry it should be very clear about it
in its policy.  Maybe repeat this as "security consideration", it
could cause havoc.  Please add an informative reference to RFC 3330,
it has a nice fresh overview of all special IPv4 addresses.  There
ought to be something similar for IPv6, but I don't know where.

>>> In particular, most DNSBLs use a positive response for 127.0.0.2
>> s/most/many/ and s/for/of/
> I think "most" is fine. The second change is correct.

I try to use "combined lists" where possible, limiting the number
of DNS queries, and for combined lists 127.0.0.2 is only one of the
positive responses.  Proposed text:

| In particular, DNSBLs use a positive response of 127.0.0.2 or
| other values in the 127.0.0.0/8 range excluding 127.0.0.0/31
| (see RFC 4632 for the notation).

>> You should also mention that lists SHOULD support 127.0.0.2 as
>> "always listed" test entry, and 127.0.0.1 for the opposite (never
>> listed), without ever returning 127.0.0.1 as a result.

> Good point. We'll consider adding that. It's a good test for DNSBL
> validity.

Yes, that's the idea.  DNS based tools won't directly check q=ns to
catch any 127.255.255.255 condition.  Two test queries (127.0.0.2
as listed, 127.0.0.1 as not listed) could detect "osirusoft" stunts.
Or whatever "monkeys" finally did for its formal net suicide.

Frank



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Bill Cole-2]

At 11:44 PM -0500 2/8/07, Matt Sergeant wrote:
>On 8-Feb-07, at 11:21 PM, Douglas Otis wrote:

[...]

>>3.3. Content of DNSBL Zone File SHOULD Be Limited.
>>
>>The DNSBL "query root" SHOULD be below the registered domain, so
>>that the DNSBL information is not conflated with domain housekeeping
>>information (e.g., name server, MX or SPF records).  By using this
>>approach, DNSBL queries would take the form of
>>"<query>.dnsbl.example.com" rather than "<query>.example.com".
>>---
>>
>>This would be a problem only when zone transfers are used to distribute
>>data.
>
>... which covers all public DNSBLs, surely?

I think not. DNSBL operators seem to be very fond of rbldnsd, which
does not implement zone transfers. I can't speak for how Spamhaus
moves zones to its authoritative servers or in from primary sources
like the CBL, but their data feeds to big users are via rsync of
rbldnsd data.

HOWEVER, Mr. Otis is missing a more important aspect.

Putting a DNSBL right on a registered domain means that the roots for
the registry-level domain (i.e. the gtld-servers.net machines for a
.com) can be put in a bad spot for a shutdown. The recommended
shutdown procedure (as well as simply wiping out the zone) leaves any
ongoing DNS burden primarily on the nameservers for the parent zone
of the DNSBL, and it would be bad for DNSBL operators to dump that on
others.

--
Bill Cole                                  
bill@...


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 9-Feb-07, at 7:46 AM, Daniel Feenberg wrote:

>> I strongly believe this is covered by the verbiage in this  
>> section. Should a criminal spammer find himself listed in the SBL  
>> (for example), he should be allowed to immediately request  
>> removal, and be granted that. As soon as he spams, he should be  
>> immediately relisted. And the limits on removals be made harder  
>> for him/her - see the second to last sentence in that first  
>> paragraph. The intention is to make innocent listings easy to  
>> remove, and criminal listings harder to remove.
>
> Is this always desirable?

No. That's why it's a SHOULD.

> If removal must be automatic, doesn't that unnecesarily give the  
> spammer twice as long on the IP address?

Technically yes. But the majority of spammers aren't going to go  
through the removal process, simply because they don't want to end up  
having that discussion.

A good example of a DNSBL that honours immediate removal requests is  
the CBL. One of the very first DNSBLs (the one that became MAPS RSS)  
also did this.

> It seems like that would double the amount of uncaught spam. I  
> would have thought that confirming a delisting with the ASN abuse  
> contact or providing reverse name look to a non-generic host name  
> would be reasonable precaustions a DNSBL might wish to impose  
> before delisting an address, and that in any case it should be up  
> to list policy.

Absolutely. This BCP is just a list of recommendations for that  
policy (especially the SHOULD parts). We think automatic removals are  
best practice because they help keep FPs low, but not every DNSBL  
will agree.

Matt.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 9-Feb-07, at 9:31 AM, Bill Cole wrote:

>>> This would be a problem only when zone transfers are used to  
>>> distribute
>>> data.
>>
>> ... which covers all public DNSBLs, surely?
>
> I think not. DNSBL operators seem to be very fond of rbldnsd, which  
> does not implement zone transfers.

My bad - I consider a zone transfer in this day and age to be an  
rsync :)

> Putting a DNSBL right on a registered domain means that the roots  
> for the registry-level domain (i.e. the gtld-servers.net machines  
> for a .com) can be put in a bad spot for a shutdown. The  
> recommended shutdown procedure (as well as simply wiping out the  
> zone) leaves any ongoing DNS burden primarily on the nameservers  
> for the parent zone of the DNSBL, and it would be bad for DNSBL  
> operators to dump that on others.

Right - this was our original intention.


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 9, 2007, at 6:31 AM, Bill Cole wrote:

> At 11:44 PM -0500 2/8/07, Matt Sergeant wrote:
>> On 8-Feb-07, at 11:21 PM, Douglas Otis wrote:
>
>>> 3.3. Content of DNSBL Zone File SHOULD Be Limited.
>>>
>>> The DNSBL "query root" SHOULD be below the registered domain, so
>>> that the DNSBL information is not conflated with domain housekeeping
>>> information (e.g., name server, MX or SPF records).  By using this
>>> approach, DNSBL queries would take the form of
>>> "<query>.dnsbl.example.com" rather than "<query>.example.com".
>>> ---
>>>
>>> This would be a problem only when zone transfers are used to
>>> distribute data.
>>
>> ... which covers all public DNSBLs, surely?
>
> I think not. DNSBL operators seem to be very fond of rbldnsd, which  
> does not implement zone transfers. I can't speak for how Spamhaus  
> moves zones to its authoritative servers or in from primary sources  
> like the CBL, but their data feeds to big users are via rsync of  
> rbldnsd data.

When a DNSBL is successful at blocking bad actors controlling perhaps  
thousands of systems, defending against a DDoS becomes a major  
concern.  Even the mention of SPF in this document indicates an  
extreme naiveté about DDoS risks.  I had hoped to make a presentation  
in MAAWG about this concern, but the board decided this might upset  
investments made by key promoters of Sender-ID.  Anyone should be  
able to register their SMTP path.  An inherently safe approach would  
be to first authenticate the SMTP client, and then associate various  
originating domains with SMTP client names.  A similar strategy could  
indicate the possibility of a DKIM replay.  There are many ways this  
can be safely done and still achieve similar goals.

Although Frank scoffed at the DDoS concerns related to SPF, testing  
scripts feed with various input parameters that parse and expand SPF  
records suggests there should be significant warnings associated with  
this approach.  It would seem that this DNSBL draft might be more  
concerned about seeing DNSBLs go away.  This might be sooner than  
anyone may have wanted.  Having them go away "gracefully" still means  
someone is paying for bandwidth without any benefit.

Zone transfers are unhelpful for two reasons as they are:
   1) not responsive to changing behaviors
   2) prone to attack unless defended by ACLs

Suggestions that web servers should be used and share the same name  
server as that of the DNSBL places even greater burdens upon those  
attempting to defend their service.  Why not mention the use of TXT  
records as a means of noting contact information?  Why must this be  
done via a web site?  Why avoid flexibility?  Where is the  
compassion? : )

> Putting a DNSBL right on a registered domain means that the roots  
> for the registry-level domain (i.e. the gtld-servers.net machines  
> for a .com) can be put in a bad spot for a shutdown.

There are many labels involved in a BL transaction using  
d.c.b.a.example.com.  When example.com wants to gracefully shutdown  
as described (although this is not likely to achieve the desired  
result of stopping undesired transactions), this can be done at 'a'  
labels just as well.  These labels must be avoided within any shared  
zone anyway.  The statement about where the zone should exist is not  
needed.  The wording used simply indicates a lack of consideration  
given related threats.

> The recommended shutdown procedure (as well as simply wiping out  
> the zone) leaves any ongoing DNS burden primarily on the  
> nameservers for the parent zone of the DNSBL, and it would be bad  
> for DNSBL operators to dump that on others.

Returning records for each transaction will quickly cause removal of  
DNSBLs likely embedded in some script that an MTA operator may not  
even be aware of.  An announcement that DNSBL 'X' is about to stop  
functioning in this manner should get operators attention.  Those  
ignoring the warning will quickly make corrections thereafter.  
Otherwise, expect wasted traffic to continue for years.  This  
sentence mentions SPF, where this is to be considerate of DNS TLDs?  
What about being considerate to the Internet as a whole?

I posted slides presented to the ISOI II at:
http://www.sonic.net/~dougotis/isoi/

These slides are similar to those presented at the DNS-OP WG.

-Doug







_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 9-Feb-07, at 1:36 PM, Douglas Otis wrote:

> Even the mention of SPF in this document indicates an extreme  
> naiveté about DDoS risks.

Not really. The mention of SPF should go - it was a bad choice. The  
rest of your email seemed to have nothing whatsoever to do with this  
draft, but perhaps if you want to re-word it without getting all  
wrapped up in the presence of three letters in the draft then it  
might be clearer what you're trying to say.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

[FYI: I'm mostly just observing, letting the discussion run...  But this
deserved comment in terms of the intent behind the BCP]

Douglas Otis wrote:
>
> On Feb 9, 2007, at 6:31 AM, Bill Cole wrote:
>> I think not. DNSBL operators seem to be very fond of rbldnsd, which
>> does not implement zone transfers. I can't speak for how Spamhaus
>> moves zones to its authoritative servers or in from primary sources
>> like the CBL, but their data feeds to big users are via rsync of
>> rbldnsd data.

> When a DNSBL is successful at blocking bad actors controlling perhaps
> thousands of systems, defending against a DDoS becomes a major concern.

Yes, but I don't think anything in the BCP predisposes compliant
operators putting themselves at risk of DDOS or any other hazard more
than is minimally necessary to provide the service in the first place.
As a general principle, we tried to avoid anything that would do that.

> It would seem that this DNSBL draft might be more
> concerned about seeing DNSBLs go away.  This might be sooner than anyone
> may have wanted.  Having them go away "gracefully" still means someone
> is paying for bandwidth without any benefit.

DNSBLs going away ungracefully has been a source of considerable adverse
press about them.  The suggested process appears to be the best way to
reduce bandwidth (both for the DNSBL and third parties) without listing
the world.  You seem to prefer the blacklist the world concept
(wildcarding results).  That's a VERY VERY bad idea because reality
causes everyone shutting down that way to be perceived as irresponsible
idiots, and damages the reputation of DNSBLs in general.  The ripples of
the OSIRUS and Monkeys shutdowns are still reverberating and smear all
subsequent DNSBLs.

The intent of the described process is this:

1) The registered domain remains useful and unflooded with DNS queries
(whether regular queries or wild resolvers).  (This was an issue with
both Osirus and Monkeys)
2) The TLD servers aren't flooded (for each query or wild resolvers)
3) the world isn't blacklisted
4) The user of the DNSBL eventually notices, without suffering a
complete loss of email.

By doing the DNSBL's base zone below the registered domain, you can have
a NS server separate from the registered domain.  You can shut down
such a DNSBL by setting the DNSBL's NS to point somewhere in 127/8
(other than 127.0.0.0/24, say[+]).  Since the NS TTL has been set high,
a DNSBL query won't requery it (off the registered domain's NS) very
frequently.  Since no NS responds from the 127/8 address, the query
times out.  Causing the user's email to be delayed by the query timeout,
not 100% blacklisted.  The user's admins eventually notice the delay,
and remove the entry.

It's been suggested that setting the DNSBL's NS record to "." would do
the same, but there seems to be indications that some resolvers don't
handle that well.

One of the things we have to consider is that once a DNSBL becomes
popular, its name becomes somewhaet of a deadzone for a very long time.
 If you let the registered domain expire as a way of killing the DNSBL,
wildcarding (perhaps by a domain squatter acquiring the domain, or
Verisign deploying whatever that was again) will have catastrophic
results.  In some cases, you might have to keep the domain registered
forever to avoid something nasty.

[Try doing DNSBL queries against letter transpositions of "spamhaus.org"
some day.  You should find several typosquatters wildcarding to their
web sites which means 100% blacklisting to some DNSBL query clients].

[blars.org appears to have simply been allowed to expire recently.  But
it's way too much a marginally used DNSBL to draw conclusions on what
would happen if, say, spamhaus.org went away.]

You did mention that the TXT record should include contact and/or
explanatory info (as in a link).  We obviously forgot that, and it
should be added as a "SHOULD" or at least "RECOMMENDED".

I'm not sure what the discussion about zone transfers is all about.  I
don't think many DNSBLS support real DNS zone transfers anymore.  An
AXFR transfer of a DNSBL like the XBL is hideously expensive.  Most
DNSBLs have settled on rsync, and other forms (various DNS protocol
methods, wget, ftp etc) have been disappearing over time.  It might be
worth mentioning rsync as the "defacto standard DNSBL bulk transfer
mechanism", but leave it at that.

[+] Putting the NS on 127.0.0.1, say, could be extremely dangerous - the
MTA using the DNSBL may be coresident with a DNS resolver that returns
wierd results that we can't predict the MTA can handles properly.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Frank Ellermann]

Douglas Otis wrote:

> Why not mention the use of TXT records as a means of
> noting contact information?

IIRC the name of that record is RP or similar, not TXT.

> Why must this be done via a web site?

Because http is quite popular for transporting more
than 400 bytes.  Nothing against gopher or whois, but...

> I posted slides presented to the ISOI II at:
> http://www.sonic.net/~dougotis/isoi/

Comparing the size of the message with the size of the
final queries is bogus.  The attacker has to sustain
those queries from his own name server, and with that
it's a factor near 9 (11 or 12 queries to the attacker,
100 queries to the victim).

The a * b * c * d stuff ignores caches, it's nonsense.

As an attacker with 102,400 bots I wouldn't bother to
figure out who checks SPF and how their DNS caches work,
and bet on ordinary "call back verification".  Or let
the bots flood the victim directly with bogus queries.

And it won't surprise me if some SPF implementations
already have a "NXDOMAIN processing limit" to catch
your convoluted attempts based on malicious MX records.

Terminate policies with "+all" is also bullshit, the
fastest way to get a PASS for any IP is to use only
"v=spf1 +all".  Of course that's a really bad idea
for somebody planning to stay on a white list, but
some spammers might like the cheap PASS.

Frank



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[John Levine-2]

>I'm not sure what the discussion about zone transfers is all about.  I
>don't think many DNSBLS support real DNS zone transfers anymore.

Until recently, MAPS distributed its DNSBLs by AXFR and IXFR.  If you
happen to have a DNS server that does IXFR, it's not a bad way to do
DNS updates.  If you don't (like me), AXFR is dreadful.

MAPS recently changed their setup and now tell me just to query their
servers via a long name that includes a hash of my account number,
which I do via a funky local cache that reformats the data on the fly
into something easier for my mail servers to use.  I don't know of
anyone who distributes DNSBLs other than by rsync or FTP of files of
CIDR ranges.

R's,
John



_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 9, 2007, at 1:17 PM, Chris Lewis wrote:

> [FYI: I'm mostly just observing, letting the discussion run...  But  
> this
> deserved comment in terms of the intent behind the BCP]
>
> Douglas Otis wrote:
>>
>> On Feb 9, 2007, at 6:31 AM, Bill Cole wrote:
>>> I think not. DNSBL operators seem to be very fond of rbldnsd,  
>>> which does not implement zone transfers. I can't speak for how  
>>> Spamhaus moves zones to its authoritative servers or in from  
>>> primary sources like the CBL, but their data feeds to big users  
>>> are via rsync of rbldnsd data.
>
>> When a DNSBL is successful at blocking bad actors controlling  
>> perhaps thousands of systems, defending against a DDoS becomes a  
>> major concern.
>
> Yes, but I don't think anything in the BCP predisposes compliant  
> operators putting themselves at risk of DDOS or any other hazard  
> more than is minimally necessary to provide the service in the  
> first place. As a general principle, we tried to avoid anything  
> that would do that.

Few seem to consider this aspect of providing BL services.

>> It would seem that this DNSBL draft might be more concerned about  
>> seeing DNSBLs go away.  This might be sooner than anyone may have  
>> wanted.  Having them go away "gracefully" still means someone is  
>> paying for bandwidth without any benefit.
>
> DNSBLs going away ungracefully has been a source of considerable  
> adverse press about them.  The suggested process appears to be the  
> best way to reduce bandwidth (both for the DNSBL and third parties)  
> without listing the world.  You seem to prefer the blacklist the  
> world concept (wildcarding results).  That's a VERY VERY bad idea  
> because reality causes everyone shutting down that way to be  
> perceived as irresponsible idiots, and damages the reputation of  
> DNSBLs in general.  The ripples of the OSIRUS and Monkeys shutdowns  
> are still reverberating and smear all subsequent DNSBLs.

Those offering a free service are not likely concerned about earning  
DNSBLs a bad reputation, especially they are bombarded by an ill  
considered scheme designed to keep the SMTP client nameless.

There is a similar conversation on nanog about maps.vix.com.

Here is a link to a possible solution.  The point is not to be  
"graceful" but to get the transactions to stop.  This requires some  
level of pain, but block all messages would be rather extreme.  
Suggesting that BL should forever return some type of safe response  
for time immemorial is not a good solution either.

http://www.merit.edu/mail.archives/nanog/msg04555.html

> The intent of the described process is this:
>
> 1) The registered domain remains useful and unflooded with DNS queries
> (whether regular queries or wild resolvers).  (This was an issue with
> both Osirus and Monkeys)
> 2) The TLD servers aren't flooded (for each query or wild resolvers)
> 3) the world isn't blacklisted
> 4) The user of the DNSBL eventually notices, without suffering a
> complete loss of email.
>
> By doing the DNSBL's base zone below the registered domain, you can  
> have a NS server separate from the registered domain.  You can shut  
> down such a DNSBL by setting the DNSBL's NS to point somewhere in  
> 127/8 (other than 127.0.0.0/24, say[+]).  Since the NS TTL has been  
> set high, a DNSBL query won't requery it (off the registered  
> domain's NS) very frequently.  Since no NS responds from the 127/8  
> address, the query times out.  Causing the user's email to be  
> delayed by the query timeout, not 100% blacklisted.  The user's  
> admins eventually notice the delay, and remove the entry.

Perhaps.  This delay would be 35 seconds or so.  Many that query list  
of lists quit after some timeout hoping some information has been  
obtained.  Even this might not be noticed.  Perhaps a list of NS  
would attract greater attention.  As been mentioned, this requires a  
different structure.

> It's been suggested that setting the DNSBL's NS record to "." would  
> do the same, but there seems to be indications that some resolvers  
> don't handle that well.

And not nice.

> One of the things we have to consider is that once a DNSBL becomes  
> popular, its name becomes somewhaet of a deadzone for a very long  
> time.  If you let the registered domain expire as a way of killing  
> the DNSBL, wildcarding (perhaps by a domain squatter acquiring the  
> domain, or Verisign deploying whatever that was again) will have  
> catastrophic results.  In some cases, you might have to keep the  
> domain registered forever to avoid something nasty.

Review the referenced nanog message.  There might be a better solution.

> You did mention that the TXT record should include contact and/or  
> explanatory info (as in a link).  We obviously forgot that, and it  
> should be added as a "SHOULD" or at least "RECOMMENDED".
>
> I'm not sure what the discussion about zone transfers is all  
> about.  I don't think many DNSBLS support real DNS zone transfers  
> anymore.  An AXFR transfer of a DNSBL like the XBL is hideously  
> expensive.  Most DNSBLs have settled on rsync, and other forms  
> (various DNS protocol methods, wget, ftp etc) have been  
> disappearing over time.  It might be worth mentioning rsync as the  
> "defacto standard DNSBL bulk transfer mechanism", but leave it at  
> that.

The concern was about where the zone is located within the domain.  
This section is not needed.

> [+] Putting the NS on 127.0.0.1, say, could be extremely dangerous  
> - the MTA using the DNSBL may be coresident with a DNS resolver  
> that returns wierd results that we can't predict the MTA can  
> handles properly.

Agreed.

-Doug


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Steve Atkins]

On Feb 9, 2007, at 3:10 PM, John Levine wrote:

>> I'm not sure what the discussion about zone transfers is all  
>> about.  I
>> don't think many DNSBLS support real DNS zone transfers anymore.
>
> Until recently, MAPS distributed its DNSBLs by AXFR and IXFR.  If you
> happen to have a DNS server that does IXFR, it's not a bad way to do
> DNS updates.  If you don't (like me), AXFR is dreadful.
>
> MAPS recently changed their setup and now tell me just to query their
> servers via a long name that includes a hash of my account number,
> which I do via a funky local cache that reformats the data on the fly
> into something easier for my mail servers to use.  I don't know of
> anyone who distributes DNSBLs other than by rsync or FTP of files of
> CIDR ranges.

... which is a shame, as they're both really bad ways of doing it, but
they work, they're easy to kludge together from existing tools and
scale way better than AXFR.

I have seen a couple of blacklists fairly recently that do still use  
AXFR, but
they were way, way out in the long tail - probably entirely unused
by anyone other than their operators. If they ever became popular
their operators would switch to rsync pretty quickly, I suspect.

Cheers,
   Steve


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg