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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Nov 7, 2008, at 3:17 AM, Stephane Bortzmeyer wrote:

On Tue, Nov 04, 2008 at 10:59:46AM -0800,
The IESG <iesg-secretary@xxxxxxxx> wrote a message of 26 lines which said:

- 'DNS Blacklists and Whitelists '
  <draft-irtf-asrg-dnsbl-07.txt> as a Proposed Standard

Well, it is certainly very important that the DNSxL are documented, given their widespread use. And the I-D is a good document.

On the other hand, I have a few questions: the first one, why "Proposed standard"? Is it really a good idea to standardize these lists (most being badly managed)? Why not just "Informational" if we just want to document what people are doing?

Agreed.

Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a AAAA? I am not aware of existing IPv6 lists so this cannot be the current usage?

In putting together planning for IPv6 block-lists, one soon confronts the enormity of its potential data-set and the incredible complexity related to carrier grade NATs, tunneling protocols, and third-party translation services. :^(

On the other hand, the DKIM signature "domain" and an accurate "on- behalf-of" value as a tuple offers a safer and simpler basis for acceptance with perhaps only a two order increase in the data-set. In today's budget cutting and tight schedules, even establishing a DKIM list is not easy where ADSP needs to be modified before this can happen. :^(

Perhaps years from now, part of the overhead for sourcing from IPv6 will be to include DKIM signatures with accurate "on-behalf-of" values. The "on-behalf-of" values should be opaque in most cases. Today it would seem email wants to pretend to authenticate, rather than indicate what is actually authenticated, even when using opaque values. :^(

It is seldom that a person's email-address represents the source of abuse. Instead, it is often the result of compromised systems somewhere in the message stream.

-Doug
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]