[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] I-D Action: draft-irtf-asrg-dnsbl-08.txt (fwd)
>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... ;-)
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
cFrom asrg-bounces at irtf.org Tue Nov 18 03:37:17 2008
Return-Path: <asrg-bounces at irtf.org>
X-Original-To: asrg-archive at optimus.ietf.org
Delivered-To: ietfarch-asrg-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 753773A6AB1;
Tue, 18 Nov 2008 03:37:17 -0800 (PST)
X-Original-To: asrg at core3.amsl.com
Delivered-To: asrg at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8A4A43A688E
for <asrg at core3.amsl.com>; Tue, 18 Nov 2008 03:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.48
X-Spam-Level:
X-Spam-Status: No, score=-14.48 tagged_above=-999 required=5
tests=[AWL=-0.380, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3,
RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fjESaO0bfuyC for <asrg at core3.amsl.com>;
Tue, 18 Nov 2008 03:21:30 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [208.31.42.53])
by core3.amsl.com (Postfix) with ESMTP id 39D973A6889
for <asrg at irtf.org>; Tue, 18 Nov 2008 03:21:30 -0800 (PST)
Received: (qmail 83500 invoked from network); 18 Nov 2008 11:21:28 -0000
Received: from mail1.iecc.com (208.31.42.56)
by mail1.iecc.com with QMQP; 18 Nov 2008 11:21:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com;
h=date:message-id:from:subject:in-reply-to:to:mime-version:content-type:content-transfer-encoding;
s=t1108; i=johnl at user.iecc.com;
bh=FJ8LWz/g+2iXZyw0E96uLi7oOLB5Ae+hxPyEC76NoKA=;
b=yeMImSNIlEuCirzpDm1zo0xg4VMHfiSjc09IhehYGbkmC9ccwmvbxEBdmsFRj1OfwYaWZTDFgI5wB+KzRr0tSDrT+Chb4djoZU/1yM6vXSf9Daa6DanUXpi+jawefpWP
Date: 18 Nov 2008 11:21:28 -0000
Message-ID: <20081118112128.25179.qmail at simone.iecc.com>
From: John Levine <asrg at johnlevine.com>
In-Reply-To: <49225FFD.5060801 at nortel.com>
Organization:
To: asrg at irtf.org
X-Headerized: yes
Mime-Version: 1.0
Subject: Re: [Asrg] I-D Action: draft-irtf-asrg-dnsbl-08.txt (fwd)
X-BeenThere: asrg at irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg at irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/asrg>,
<mailto:asrg-request at irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/pipermail/asrg>
List-Post: <mailto:asrg at irtf.org>
List-Help: <mailto:asrg-request at irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/asrg>,
<mailto:asrg-request at irtf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: asrg-bounces at irtf.org
Errors-To: asrg-bounces at irtf.org
>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... ;-)
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
_______________________________________________
Asrg mailing list
Asrg at irtf.org
https://www.irtf.org/mailman/listinfo/asrg
onsumers 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
_______________________________________________
Asrg mailing list
Asrg at irtf.org
https://www.irtf.org/mailman/listinfo/asrg