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

Andrew Sullivan <ajs@shinkuro.com> Wed, 12 November 2008 02:59 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A6F3A6AB0; Tue, 11 Nov 2008 18:59:34 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3073A6AB0 for <ietf@core3.amsl.com>; Tue, 11 Nov 2008 18:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, 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 sE6Chc1XRB-r for <ietf@core3.amsl.com>; Tue, 11 Nov 2008 18:59:31 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D7AF83A6AAF for <ietf@ietf.org>; Tue, 11 Nov 2008 18:59:31 -0800 (PST)
Received: from crankycanuck.ca (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EF62D2FE9555 for <ietf@ietf.org>; Wed, 12 Nov 2008 02:59:29 +0000 (UTC)
Date: Tue, 11 Nov 2008 21:59:28 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: ietf@ietf.org
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Message-ID: <20081112025927.GA36537@shinkuro.com>
References: <20081104185946.4879C3A6C20@core3.amsl.com> <20081107111744.GA31018@nic.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20081107111744.GA31018@nic.fr>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear colleagues,

We have read draft-irtf-asrg-dnsbl-07.  We have some comments on the
draft in response to the last call.  We wish to emphasise that, while we
currently serve as the co-chairs of the DNS Extensions working group,
these comments are merely our own, and are not representative of the
views of the working group.

We believe we understand the purpose of DNSxLs, and we think they can, in
some circumstances, provide a useful service (even though they
sometimes cause difficulty for users of Internet mail).  We also think
that describing current behaviour of DNSxLs is a good thing.  

That said, we are uncomfortable with the draft in its current form,
and are strongly opposed to adopting it as a Proposed Standard.  We
believe that most, but not all, of the draft would be an excellent
candidate for adoption as an Informational document.

One problem with the document is its outline of the way that DNSxLs
use A records to indicate reasons to accept or reject traffic from a
given site.  The trouble is that these A records are not host
addresses, even though that's the definition of an A record.  The A
records merely _look_ like host addresses.  In order to understand
that they are not host addresses, you have to know what DNS server you
are querying and interpret the owner name at the record.

What this really does is use the context of the query, plus the
content of the query and answer, as meta-data in order to add new
semantics to A records: if you happen to query server
dnsbl.example.org with just the right owner name, you get an A record
that is not a host address.  Note that merely knowing the DNS server
name is not enough: the document points out that if you query the same
server with a different owner name, you might get an A record that
_is_ a host address.  In addition, the context of the answer
determines its use: the same server can use the same zone data to
provide whitelist and blacklist services to two different groups of
querying agents.

Now, it is surely a service to the Internet community to document that
there are DNS servers where the content of the answer determines the
semantics of the record, but we don't really think this is something
that we should plan to advance on the standards track.  It seems plain
to us that the reason DNS has RRTYPEs is so that the client doesn't
need to guess what kind of record it has when it gets a resource
record.

In our view, the document really needs to make clear that DNSxLs are
violating the semantics of A records when they make this use of them.
One way to do that would be to modify the first paragraph in section
2 along the following lines:

   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
   transformation of their IP addresses, but now host names are
   sometimes encoded as well.  Most DNSxLs still use IP addresses.
   The zone accepts and responds to DNS queries in apparently standard
   ways.  The zone data, however, is not DNS data, and has special
   semantics that can be understood only in the context of the DNSxL
   service.  In particular, A records returned by the server usually
   do not contain a host address.  Instead, they usually contain a 32 bit
   value to be interpreted as bitfields.  For historical reasons,
   implementations used the DNS A RRTYPE to represent these values,
   rather than a distinct RRTYPE.

   As noted in section 5, some A records in a DNSxL zone MAY contain
   host records.  How clients interpret different A records in the
   same DNSxL zone is implementation- and context-dependent.


In addition, the document proposes to continue using the existing
mechanism in order to support IPv6 hosts.  There is little evidence of
a widespread deployment of such use, and there is therefore still time
to come up with a better solution that does not overload the meaning
of RRTYPEs before we have widespread use of IPv6 mail
infrastructure.  Therefore, in our opinion, extending the current
practice to IPv6 hosts is not a good idea.  The current draft makes
the best of a bad principle, but it should recommend an alternative
approach as preferable.  

One simple solution would be to introduce one or, better, two new
RRTYPE(s) that work(s) exactly the same way as the A RRTYPE, so that
deployed software would need to be modified only to query for the new
RRTYPE instead of an A record.  We appreciate that a long, or maybe
indefinite, transition period would be needed.  Presumably, however,
the widespread introduction of IPv6 in the mail infrastructure of
organisations will occasion the installation of new software as well.

Best regards,

Olafur Gudmundsson 
ogud@ogud.com

Andrew Sullivan
ajs@shinkuro.com
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf