Re: [dnsext] Design team report on dnssec-bis-updates and CD bit

Michael Graff <mgraff@isc.org> Mon, 12 July 2010 05:06 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E073A6816; Sun, 11 Jul 2010 22:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 h-cTE+hKINKg; Sun, 11 Jul 2010 22:06:31 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE7243A68A0; Sun, 11 Jul 2010 22:06:30 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OYB7V-000GBr-42 for namedroppers-data0@psg.com; Mon, 12 Jul 2010 04:59:57 +0000
Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <mgraff@isc.org>) id 1OYB7R-000GBT-U5 for namedroppers@ops.ietf.org; Mon, 12 Jul 2010 04:59:54 +0000
Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 4117417D1EB; Mon, 12 Jul 2010 04:59:53 +0000 (UTC)
Received: from whitedragon.local (unknown [209.236.250.213]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 4339817D1E8; Mon, 12 Jul 2010 04:59:50 +0000 (UTC)
Message-ID: <4C3AA142.1030304@isc.org>
Date: Sun, 11 Jul 2010 23:59:46 -0500
From: Michael Graff <mgraff@isc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Andrew Sullivan <ajs@shinkuro.com>
CC: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Design team report on dnssec-bis-updates and CD bit
References: <20100709142108.GA68527@shinkuro.com>
In-Reply-To: <20100709142108.GA68527@shinkuro.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On 7/9/10 9:21 AM, Andrew Su
> Please offer your thoughts on these models and state which of them you
> think should be in the draft as the way to handle the CD bit.  We will
> devote some time in the Monday Maastricht session to this issue.  We
> want to bring it to a close at that meeting.

I may make some sense to list the behaviors of the common resolvers, and
define what problems we're trying to fix by selectively setting the CD=1
flag.  There was mention that there was lack of agreement, but no
reasons (pros, cons) for the various choices really.

Please also note that you might not know that you have a covering TA for
the name in question in all cases, specifically DLV or when learning
about the existence of DNSSEC does not start from the parent and move
into the child, but moves the other way.  Which some resolvers implement.

Also, just because a query did not have CD set, it does not mean the
next one won't, and I believe it's against the RFCs to query for RRSIG
or NXT records.  This would mean more queries, and to be safe, probably
two caches in the resolver, one for CD=1 and one for CD=0.


--Michael