Subject: [Asrg] I-D Action: draft-irtf-asrg-dnsbl-08.txt (fwd)

From: John L <[email-masked]>
Date: Mon, 17 Nov 2008 15:25:55 +0000 (GMT)

I've done another draft of the infamous DNSBL draft, to turn it back into 
a draft for an IRTF informational RFC rather than standards track, and 
to update a few other details that either people pointed out or I noticed.

Take a look, particularly at the expanded section 7 on security 
considerations, let me know if there's anything that would make this not 
the consensus of the ASRG.

R's,
John
---------- Forwarded message ----------
Date: Mon, 17 Nov 2008 14:18:01 +0000 (UTC)
From: [email-masked]
To: [email-masked]
Newsgroups: iecc.lists.ietf
Subject: I-D Action: draft-irtf-asrg-dnsbl-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 	Title           : DNS Blacklists and Whitelists
 	Author(s)       : J. Levine
 	Filename        : draft-irtf-asrg-dnsbl-08.txt
 	Pages           : 13
 	Date            : 2008-11-17

The rise of spam and other anti-social behavior on the Internet has
led to the creation of shared blacklists and whitelists of IP
addresses or domains.  The DNS has become the de-facto standard
method of distributing these blacklists and whitelists.  This memo
documents the structure and usage of DNS based blacklists and
whitelists, and the protocol used to query them.

IRTF Notice

This document is a product of the Anti-Spam Research Group (ASRG) of
the Internet Research Task Force.  It represents the consensus of the
ASRG with respect to practices to improve interoperability of DNS
based blacklists and whitelists, but does not constitute an IETF or
Internet standard.

[NOTE TO RFC EDITOR: Please remove this paragraph in publication.]
Comments and discussion may be directed to the ASRG mailing list,
[email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-asrg-dnsbl-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 17 Nov 2008 14:55:31 -0600

John L wrote:
> I've done another draft of the infamous DNSBL draft, to turn it back 
> into a draft for an IRTF informational RFC rather than standards track, 

I don't recall seeing a group consensus process for determining whether to shift 
out of seeking standards track.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Peter Koch <[email-masked]>
Date: Mon, 17 Nov 2008 22:39:28 +0100

On Mon, Nov 17, 2008 at 02:55:31PM -0600, Dave CROCKER wrote:

> I don't recall seeing a group consensus process for determining whether to 
> shift out of seeking standards track.

the group as such doesn't have the option of Standards Track ...

-Peter

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 22:43:41 -0000

>I don't recall seeing a group consensus process for determining
>whether to shift out of seeking standards track.

There wasn't any group consensus to move it onto the standards
track, either.

R's,
John

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 22:43:41 -0000

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Nov 2008 01:26:05 -0500

> the consensus of the ASRG.

Two things (I'm still reading it, may be more to come):

1) It has no reference to the DNSBL BCP.  It should - it's important to
ensure readers have access to as full a picture of DNSBLs as possible.
While the lack (or not submitting the BCP and spec in parallel) probably
won't cause political problems with IRTF deliberations (like it did with
the IETF), it should be there anyway.  We shouldn't have to stand on as
much formalism as standards track last-call, we should consider them in
parallel here, and make sure they cross reference each other.

2) The main sticking point with IETF standards track (once you got thru
the religious wars and talked specifically about technical objections)
is apparently the use of A records for DNSBL returns, instead of a new
RRTYPE.  I at least partially disagree with the level of importance they
place on that issue, point out that it doesn't cause problems in
practise, and I also don't think a new RRTYPE would _ever_ fly - I'll
elaborate if someone wishes.

Still, some sort of parenthetical remark like this:

> It should have been a new RRTYPE, should not be considered
> precedent for something else overloading DNS like this, but it is
> far too late to consider adopting a new RRTYPE for the huge installed
> base of DNSBL usage.

Would go a long way to make the less religious IETF people be happy with
the document, regardless of how it's adopted.  One even offered to help
word it... ;-)

---

From: John Levine <[email-masked]>
Date: 18 Nov 2008 11:21:28 -0000

>the document, regardless of how it's adopted.  One even offered to help

I had some offline e-mail and it turns out to be just another
religious war.  In the IETF DNS community, the orthodox belief is that
there are no important barriers to adding new RR types.  In
particular, all those crummy web management systems that can barely
handle the existing RRTYPEs don't exist or don't matter.

You could add a new RRTYPE in parallel with the A records, but of
course that would just mean that people would continue to use the A
records and the new type would never replace it.  (Think of the
temporary hack in the 1980s to fall back to A records if there's no
MX.)

If there were a son-of-DNSBL that published more complex information,
e.g., if we figure out reputation well enough to understand what a
generally useful reputation record containing more than one bit would
contain, I'd be less opposed to a new RRTYPE since both producers and
consumers would need new code anyway to support it.  But inventing a
new record that is just like an A record only different is silly.

I also have some concern about how well the defenders of DNS purity
understand what they're asking for. One of the stronger advocates of a
separate RRTYPE went on to propose a complex kludge to tell whether a
DNSBL offers the new type, evidently not understanding DNS well enough
to realize that you just look up the normal test address and see if
you get the RRTYPE you want.

Re your other point, if it seems likely that the BCP-ish doc can come
out at the same time as the spec, I would of course adjust the reference
to it from the current vague language to be more specific.

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 18 Nov 2008 07:54:34 -0500

> new record that is just like an A record only different is silly.

I'd like to express my strong concurrence with this approach.  My crystal
ball is too murky this morning for me to predict if/when we'll get to
this point, but I think if/when we do that we'll figure out if compelling
reasons exist to refactor the structure of DNSBLs and the code that
uses them.

---Rsk

---

From: der Mouse <[email-masked]>
Date: Tue, 18 Nov 2008 10:40:10 -0500 (EST)

>>> It should have been a new RRTYPE, [...]
>> [...]
> religious war.  In the IETF DNS community, the orthodox belief is
> that there are no important barriers to adding new RR types.  In

Perhaps it's heretical of me, but _for DNSBLs_, I don't see why they
would matter.  You don't use "those crummy web management systems" for
DNSBLs, after all.

Well, unless you're trying to run a DNSBL and you're outsourcing your
DNS service to someone who makes you use one of them, I suppose, but I
have trouble seeing that as being close enough to practical to be worth
caring about.  Am I wrong?  Are there known to be DNSBLs being run that
way?

> contain,

Aren't there already DNSBLs that provide either a bitmask with no more
than a few dozen bits, or a small integer - ie, "more than one bit" -
transmitted as an A record?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 18 Nov 2008 09:56:02 -0600

> There wasn't any group consensus to move it onto the standards

which means that it really was an individual submission and should not have been 
cast as coming from the ASRG...

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 18 Nov 2008 09:56:02 -0600

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 18 Nov 2008 17:19:49 -0000

>which means that it really was an individual submission and should
>not have been cast as coming from the ASRG...

The IESG certainly understood that.

R's,
John

---

From: "David Nicol" <[email-masked]>
Date: Tue, 18 Nov 2008 16:25:47 -0600

>> But inventing a

imagining reworking RRTYPE to be more data-driven rather than
use-driven.  With some theory behind keeping the number of RRTYPEs
small, like the kinds of basic types in high level languages, that
would be ammunition in debates to add or not.  Anyone keeping floating
point data in A records instead of bitmasks?  There are enough bits to
have an IEEE 754 single precision float in there for a reputation
score.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Nov 2008 17:36:53 -0500

> new record that is just like an A record only different is silly.

Yeah, I think I said that in that argument ;-)

Furthermore, if we were to do something more featureful than DNSBLs,
it'd probably not be DNS anyway, so a new RRTYPE is moot.

> to it from the current vague language to be more specific.

What's preventing the BCP-ish document coming out at the same time as
the spec?

I've been handed a few more typographical nitpicks, still nothing
substantive.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Franck Martin <[email-masked]>
Date: Wed, 19 Nov 2008 10:41:30 +1200 (ANAT)

Did not fully read but not sure if there is something that access to DNSBL should not be restricted. I'd like to query often the DNSBL to see if my IPs are not appearing in it. It is easier that way that to scan postmaster emails. And I can create alerts with tools like nagios, etc...

---

From: John Levine <[email-masked]>
Date: 18 Nov 2008 23:31:04 -0000

>What's preventing the BCP-ish document coming out at the same time as

The IRTF process requires that a couple of the other RG chairs review
the docs for quality and wholesomeness, not to mention whether it
makes sense to someone from the outside.  If they have suggestions,
which they probably will, you respond to them.  (The RG suggestions
for my draft were entirely constructive.)

If we can get the necessary reviews, you should be OK.  There's an
IESG review, but that's supposed to be limited to seeing if it's an
attempted end run around a WG or other procedural shenanigans, not
whether they like what it says or not.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Nov 2008 18:48:57 -0500

Franck Martin wrote:
> Did not fully read but not sure if there is something that access to
> DNSBL should not be restricted. I'd like to query often the DNSBL to see
> if my IPs are not appearing in it. It is easier that way that to scan
> postmaster emails. And I can create alerts with tools like nagios, etc...

I'm not sure what you're referring to here.  The DNSBLs that are the
subject of the BCP are open - more or less by definition.

There's also a consideration of scaling.  Having a few dozen
organizations continually rescanning their, say, /16s could get rather
old quick.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Nov 2008 18:54:58 -0500

> whether they like what it says or not.

What do I need to do to have that process underway, or is it already?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 18 Nov 2008 18:59:15 -0500

On Wed, Nov 19, 2008 at 10:41:30AM +1200, Franck Martin wrote:
> Did not fully read but not sure if there is something that access to DNSBL should not be restricted. I'd like to query often the DNSBL to see if my IPs are not appearing in it. It is easier that way that to scan postmaster emails. 

By the time reports have found their way back to (at your "abuse" address,
I'd hope, not "postmaster") and by the time you've been listed on a DNSBL,
it's too late.  The damage has already been done.  A much better approach
is to be proactive, to actively block or at least detect common forms
of abuse before they escape your network.

So instead of putting engineering time into wiring DNSBL checks into
Nagios (referenced in the part of your message I elided) it would be
better to apply that same time to understanding your network, thinking
about how it could be abused, and putting in place measures designed
to forestall that.

---Rsk

---

From: Matthias Leisi <[email-masked]>
Date: Wed, 19 Nov 2008 07:04:06 +0100

> organizations continually rescanning their, say, /16s could get rather

An old wish: Have some protocol to enable queries like "return all
listings for IP addresses in a.b.c.d/N" (for some reasonably max value
of N, possibly 24?).

Yes, that's easily done if you have a local copy of the data, but that
is not always feasible (or has considerable cost).

-- Matthias

---

From: Franck Martin <[email-masked]>
Date: Wed, 19 Nov 2008 18:07:57 +1200 (ANAT)

I would suspect that such service would be by authorisation to avoid abuse, etc... (kind of a feedback loop). 

----- Original Message ----- 
From: "Matthias Leisi" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Wednesday, 19 November, 2008 6:04:06 PM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] I-D Action: draft-irtf-asrg-dnsbl-08.txt (fwd) 

-- Matthias

---

From: SM <[email-masked]>
Date: Wed, 19 Nov 2008 00:53:53 -0800

>not have been cast as coming from the ASRG...

There is a mention in this draft about it being a product of the 
Anti-Spam Research Group (ASRG), a group that falls under the IRTF ( 
www.irtf.org ).  The guidelines and procedures for IRTF Research 
Groups are described in RFC 2014.

Version 5 of this draft mentions that it represents the consensus of 
the ASRG and the intended status was "Informational".  The intended 
status of Version 6 of this draft was "Standards Track".  As such, it 
would require IETF consensus and be published as an "Individual 
Submission" which has gone through the IETF process.  Version 8 of 
this draft which was submitted after the Last Call has an intended 
status of "Informational".

Dave has a point.  If the drafts from the ASRG are said to be a 
product of the group and represented as the consensus of the group, 
it would be good to seek the group consensus for any changes.  That 
would avoid unneeded "issues".

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Nov 2008 08:12:00 -0500

> listings for IP addresses in a.b.c.d/N" (for some reasonably max value

We'd only have to issue more than 65536 of those to check our space ;-)

Yes, something like that would be nice and I don't think too many DNSBL
operators would object (at least in theory).  Some DNSBLs offer by-email
notification.  Others might want to, but don't for whatever reason.

However:

1) The BCP is a wrong place to describe a protocol for that.
2) Most DNSBL operators would probably prefer that there was some sort
of authorization layered on top.

For reasons of scaling and overhead, I think it'd probably be better
that these are third party offerings.

There have been efforts to implement third party services to do that.
Habeus had/has(?) one.  I believe Karmasphere can do it.

Most of these services only query small numbers of IPs, and the costs
would be prohibitive if you had a largish range.  But with the
appropriate arrangements, it should be possible to do much better.

---

From: Matthias Leisi <[email-masked]>
Date: Wed, 19 Nov 2008 14:34:02 +0100

> We'd only have to issue more than 65536 of those to check our space ;-)

Maybe you should donate some of that space ;-)

> notification.  Others might want to, but don't for whatever reason.

Thinking a bit further, such a "range query" is not only a nice to have, 
but pure necessity in IPv6-land, where you will hardly ever will want to 
deal with individual IP addresses, but with - what is the current 
smallest customer allocation? /64? - /64s.

> 1) The BCP is a wrong place to describe a protocol for that.

ACK.

Maybe it's time to start experimenting with some kind of an "IPv6 
reputation protocol". The more I think about it, the less I'm convinced 
that we can (or should) simply continue using the IPv4 approach.

-- Matthias

---

From: "David Nicol" <[email-masked]>
Date: Wed, 19 Nov 2008 13:06:20 -0600

> is not always feasible (or has considerable cost).

I believe we have two dots under discussion at this time which may be
properly connected:
Have RBL operators allow opting in for them, then send ARF reports on listing.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Nov 2008 14:57:33 -0500

> Have RBL operators allow opting in for them, then send ARF reports on listing.

We had this conversation a little over a week ago in terms of
instrumenting MTAs to send off ARF reports automatically.

That might work on some smaller DNSBLs that work on a strict "spam in
hand" basis.  Eg: SBL.

But, ARF reports are poorly suited for some DNSBLs.  telekom.gov.tr, for
example, would need to handle 258684 ARF reports per week or so[+] (see
http://cbl.abuseat.org/domain.html) from the CBL.  There's no samples
for the PBL.  Etc.

[+] Ooh, shiny, telekom's CBL count is down from 440,000 as I reported
on November 12.  Everything seems down.  McColo disconnection...
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Wed, 19 Nov 2008 14:26:43 -0600

> instrumenting MTAs to send off ARF reports automatically.

not MTAs, but DNSBLs

> That might work on some smaller DNSBLs that work on a strict "spam in

for which it would make sense, of course.

I believe in an implied "where it would make sense" and an implied
dismissal of specific situations where something that makes sense in
some situations doesn't make sense doesn't make sense.  ASRG is the
only forum I am aware of where this belief may put me in the minority
(laugh)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Nov 2008 16:31:12 -0500

>> instrumenting MTAs to send off ARF reports automatically.

the email I replied to on the 12th was _definately_ to do with MTAs
generating ARF.

> only forum I am aware of where this belief may put me in the minority

How about the IETF? ;-)

Something like "Where practical, a DNSBL MAY consider offering
notification of listing" might do it.  I'm not sure you can get more
detailed than that.  Eg: "how", "format", "authorization" etc.

Can't be ARF very often.

Wordsmithing?

---

From: John Levine <[email-masked]>
Date: 23 Nov 2008 23:00:38 -0000

>What do I need to do to have that process underway, or is it already?

First we check to be sure that the RG is happy with both drafts, so we
can say they represent the consensus of the RG.

Then I'll work with Aaron to get the necessary reviews.

Hey, RG, other than the procedural issues, how do you like the -08 draft
of the description of DNSBLs?

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 23 Nov 2008 19:37:12 -0500

> of the description of DNSBLs?

Ditto (after a few more typographical nits are corrected) on the BCP?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Mon, 24 Nov 2008 10:24:45 -0600

> Ditto (after a few more typographical nits are corrected) on the BCP?

You are looking for public responses indicating we're happy with the
current (or soon to be current) versions? Yes to both, from me.

Best,
Al

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 24 Nov 2008 11:40:13 -0500

> current (or soon to be current) versions? Yes to both, from me.

Yes please.  Thanks.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 24 Nov 2008 14:29:33 -0700

>> current (or soon to be current) versions? Yes to both, from me.

+1 for both.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 24 Nov 2008 16:11:29 -0800

Some tidbits.

d/

> 2.  Structure of an IP address DNSBL or DNSWL
> 
>    A DNSxL is a zone in the DNS[RFC1034][RFC1035].  The zone containing
>    resource records identifies hosts present in a blacklist or
>    whitelist.  Hosts were originally encoded into DNSxL zones using a

A 'zone' is an administrative construct, rather than a queriable user-visible 
semantic construct, such as a sub-tree.  If 'zone' is in fact correct, why?  If 
not, then I suggest saying sub-tree.

> 2.1.  IP address DNSxL
> 
>    An IPv4 address DNSxL has a structure adapted from that of the rDNS.
>    (The rDNS, reverse DNS, is the IN-ADDR.ARPA[RFC1034] and
>    IP6.ARPA[RFC3596] domains used to map IP addresses to domain names.)
>    Each IPv4 address listed in the DNSxL has a corresponding DNS entry.
>    The entry's name is created by reversing the order of the octets of
>    the text representation of the IP address, and appending the domain
>    name of the DNSxL.
> 
>    If, for example, the DNSxL is called bad.example.com, and the IPv4
>    address to be listed is 192.0.2.99, the name of the DNS entry would
>    be 99.2.0.192.bad.example.com.  Each entry in the DNSxL MUST have an
>    A record.  DNSBLs SHOULD have a TXT record that describes the reason
>    for the entry.  DNSWLs MAY have a TXT record that describes the
>    reason for the entry.  The contents of the A record MUST NOT be used
>    as an IP address.  The A record contents conventionally has the value

record contents... has -> record contents... have

>    If a range of addresses is listed in the DNSxL, the DNSxL MUST
>    contain an A record (or a pair of A and TXT records) for every
>    address in the DNSxL.  Conversely, if an IP address is not listed in

Each address results in a different queriable domain name 
<reverse-addre>.<service domain>, so I think the requirement is deeper than just 
separate pseudo-A records:  each must have its own name (and, yes, each with its 
own A record underneath.)

> 7.  Security Considerations
> 
>    Any system manager that uses DNSxLs is entrusting part of his or her

his or her -> their

see: <http://dcrocker.net/#they>

>    server management to the parties that run the lists, and SHOULD
>    ensure that the management policies for the lists are consistent with
>    the policies the system manager intends to use.  Poorly chosen DNSBLs
-- 

   Dave Crocker

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 24 Nov 2008 21:14:10 -0500

One questions on irtf-asrg-dnsbl:

Is it worth discussing usage of other means to propagate DNSxLs,
e.g., rsync?

Regardless of the answer, I think this one is fine.

On irtf-asrg-bcp-blacklists, near the end of section 1.2, text reads:

	DNSBLs can, and have, ceased operation without notice.  DNSBL users
	SHOULD periodically check the correct operation of the DNSBL, and
	cease using DNSBLs that are working incorrectly

I suggest considering:

	DNSBLs can, and have, ceased operation without notice.  DNSBL users
	SHOULD periodically check the correct operation of the DNSBL, and
	SHOULD cease using DNSBLs that are working incorrectly

which adds a second "SHOULD" for clarity.  But I freely admit that this
may be a nit and not worth the bother.  So again, regardless of the
answer, I think this one is fine.

Thank you to the authors for their diligence and hard work.

---Rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 24 Nov 2008 23:39:28 -0500

> Is it worth discussing usage of other means to propagate DNSxLs,

Unfortunately, there doesn't seem to be enough commonality to suggest
one way or another as being reasonably standard.

> answer, I think this one is fine.

I can put that in the nit list, no biggie.

> Thank you to the authors for their diligence and hard work.

Thanks for helping!

---

From: John Levine <[email-masked]>
Date: 25 Nov 2008 13:29:44 -0000

>A 'zone' is an administrative construct, rather than a queriable
>user-visible semantic construct, such as a sub-tree.  If 'zone' is in
>fact correct, why?  If not, then I suggest saying sub-tree.

In practice they're always zones, but I suppose subtree would be more
accurate.

><reverse-addre>.<service domain>, so I think the requirement is
>deeper than just separate pseudo-A records: each must have its own
>name (and, yes, each with its own A record underneath.)

Hmmn.  I'll think about rewording it.

>>    Any system manager that uses DNSxLs is entrusting part of his or her

No.

R's,
John