Subject: [dns-dir] DNS BL/WL Discussion

From: Mark Townsley <[email-masked]>
Date: Sun, 16 Nov 2008 01:03:33 +0100

Would someone please give me a backgrounder and summary of the enormous 
list discussion that has erupted over this?

Thanks,

- Mark

_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Nov 2008 07:55:34 -0600

On 15 nov 2008, at 18.03, Mark Townsley wrote:

> Would someone please give me a backgrounder and summary of the  
> enormous list discussion that has erupted over this?

I can help. I have sort of followed the discussion. I think the 30.000  
feet level discussion is about whether one should use BL/WL at all,  
why the ones running lists are good/bad guys etc.

But, there is some meat in there, and I promise to have a summary to  
you later today (Sunday)

    Patrik

---

From: Peter Koch <[email-masked]>
Date: Sun, 16 Nov 2008 23:00:14 +0100

Mark,

> list discussion that has erupted over this?

here's my summary:

There are two drafts in the IRTF ASRG:

     - "DNS Blacklists and Whitelists"
	<draft-irtf-asrg-dnsbl-07.txt> 
     - "Guidelines for Management of DNSBLs for Email"
        <draft-irtf-asrg-bcp-blacklists-04.txt> 

We've had them on our radar screen in Dublin. Unfortunately the efforts
to get a DNS Dir review organized before Lisa Last Called the first document
got stalled.  This is something we need to work on.

The discussion, except for the unavoidable religious anti-spam debates,
has these issues in my perception:

o Whether DNS blacklists should be used, are well maintained etc.
  Nothing of this is actually covered in the draft in question, part of
  it is in the "BCP" companion document.

o Whether IRTF RGs should develop Standards Track and/or BCP documents
  This is an interesting meta issue that we already noted; makes little
  difference since the draft was Last Called as an individual submission,
  but the "group consensus" behind the draft now makes an interesting
  argument.  We've seen a similar failure mode and bad precedent with the
  RFC2821/22 update.

o Should the DNSBL document be PS vs Informational under the process argument
  or content wise?

o Issues with the specification or the draft itself.  Andrew and Olafur
  have written the most concise contribution, although I quite frankly
  don't really agree.  The DNSBL spec clearly sets the "resolution context"
  and I doubt there's a danger of confusion between the overlay semantics
  of the A RR and a host address.  That said, this overlay issue sould IMHO
  suggest to document RBLs in an Informational draft rather than standardizing
  the current practice.
  The arguments of A having different meaning in the same zone are bogus
  again, sicne a zone is an artificial and indeed invisible to the application
  boundary.  The spec makes pretty clear when which sematics should be
  applied. Again, I'd not endorse this, but demanding DNSBLs change their
  use of A RRs to a new RR type, doesn't sound promising to me.
  This issue, however, needs to be discussed in the draft.

Apart from the serious meta issues, the draft could go as Informational
after having reveived serious DNS review and maybe another edit, IMHO.

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Nov 2008 22:53:56 -0500

>   suggest to document RBLs in an Informational draft rather than standardizing

We actually suggested that it be informational.  We did suggest an
addition (which is apparently being considered).  What is important to
me is that this not go on the standards track.

>   This issue, however, needs to be discussed in the draft.

The application is a nifty hack, and I think only a fool would imagine
that the installed base is going to change anyway.  But IMO it's
really important not to start standardizing overloading of RRTYPEs.
As Ted Hardie pointed out on-list, people will use selected RFCs as
their jurisprudential base on which to construct new (ab)uses of the
DNS.  Overloading RRTYPEs seems to me to be an incredibly bad idea,
especially when we're not at any risk of running out of the datatypes
any time soon.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Nov 2008 08:25:31 -0500

> Overloading RRTYPEs seems to me to be an incredibly bad idea,

Yes, it's a bad idea. What else is new?

How many times over the last ten years have we moaned and whined about
this, with the end result pretty much always the same ("txt rules"!)?

If we are going to do realistically push back on this sort of abuse,
perhaps we should revisit the real (and perceived) obstacles to doing
the Right Thing (e.g., defining a new RR) and show folk a better
path. Isn't this lack of (or perceived lack of) a better path the real
uderlying problem?

Thomas

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Nov 2008 00:41:20 -0600

> path. Isn't this lack of (or perceived lack of) a better path the real

Three responses:

1.  I'm already doing whatever I can to make defining a new RR as
painless as possible.  It's not perfect, but the "2929bis" approach is
already being used.

2.  I don't think that's the issue here anyway.  What we're really
dealing with is a legacy problem.  It's the way the world is now, and
it needs to be documented.  But we need at the same time to say,
"Don't do this any more, please, for the love of all that is holy."

3.  There remains a persistent problem with certain parts of one
widely-deployed operating system, its APIs, and how they work with
unknown RRTYPEs.  I haven't the foggiest idea what to do about this.

A