Subject: [dns-dir] draft-irtf-asrg-dnsbl-07.txt

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Nov 2008 14:35:46 -0600

There was a last call issued on an IRTF document:

> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'DNS Blacklists and Whitelists '
>   <draft-irtf-asrg-dnsbl-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2008-12-02. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.

And the discussion started...

The largest part still seems to be whether it is correct to ask  
questions at this stage in the process. Dave Crocker writes  
specifically:

> Last Call gives the community a chance to actively put forward  
> concerns, not to passively wait and require a detailed exposition by  
> the working group. You note that you were not a participant. Yet  
> that is exactly how someone who is concerned about the detailed  
> history is supposed to obtain information about the detailed process  
> (and affect its outcome.)

The derail is due to views like these (Keith Moore this time):

> Under no circumstances should any kind of Blacklists or Whitelists be
> accepted by IETF as standards-track documents.  These lists are
> responsible for huge numbers of illegitimate delivery failures.  We
> should no more be standardizing such lists than to be standardizing  
> spam.

Ned Freed says:

> Such a criticism might be a sensible response to a document that  
> defines an
> actual whitelisting or blacklisting service. But that's not what  
> this document
> does. Rather, this document defines vaarious formats for storing such
> information in the DNS and procedures for querying that data.  
> Specification of
> actual services based on these formats and procedures is left for  
> later
> specifications.
>
> Standardizing these formats and procedures is important for at least  
> two
> reasons: (1) Without a specification nailing down these details  
> there can be
> (and in practice have been) interoperability problems between various
> implementations and (2) Without something describing how to  
> structure and
> operate these systems they can, independent of the actual list  
> content, create
> serious operational problems.

The discussion then seems to have diverged again into a few different  
tracks:

- Whether PS is the right track?
- Whether IETF should/can discuss repudiation systems in general?
- Whether repudiation systems for email is a good thing or not?

And then of course:

- Does this document technically make sense technically?
- Can anyone in a last call of an IRTF document object?

Now, if I read the draft myself, the draft describe the very simple  
ways they use the DNS to store information about white/black lists for  
IP addresses (ipv4 and ipv6) and domain names. They use A and TXT  
records, and the root in the DNS namespace under which the domain  
names are located is decided by the host of the black/white list.

Example, if 192.0.2.99 is blacklisted at example.com, and the root of  
the blacklist is bad.example.com, the following entries exists in DNS:

99.2.0.192.bad.example.com. A   127.0.0.2
99.2.0.192.bad.example.com  TXT "Dynamic address, see http://bad.example.com?192.0.2.99 
"

The IP address in the A record is not really an IP address but a 32  
bit field that is to be interpreted in a certain way so that  
"chaining" of such records are possible. The TXT record include  
information to a user that can be used for example in the message in  
the SMTP conversation.

The use of an A record that way is, well, not nice. Think of what  
happens when you have services like Sitefinder and similar that does  
not result in NXDOMAIN and similar. Phew...overloading stuff in the  
DNS on the DNS datatypes is not fun. I do not like that, but you know  
that.

The document should imho definitely not be PS. Informational, but not  
PS. The solution is not fun.

Why can not people do the right thing? Which in this case would be to  
define a new RRType.

    Patrik

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