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
- [dnsext] Design team report on dnssec-bis-updates… Andrew Sullivan
- Re: [dnsext] Design team report on dnssec-bis-upd… bmanning
- Re: [dnsext] Design team report on dnssec-bis-upd… Olafur Gudmundsson
- Re: [dnsext] Design team report on dnssec-bis-upd… Masataka Ohta
- Re: [dnsext] Design team report on dnssec-bis-upd… bmanning
- Re: [dnsext] Design team report on dnssec-bis-upd… Andrew Sullivan
- Re: [dnsext] Design team report on dnssec-bis-upd… Jiankang YAO
- Re: [dnsext] Design team report on dnssec-bis-upd… Michael Graff
- Re: [dnsext] Design team report on dnssec-bis-upd… W.C.A. Wijngaards
- Re: [dnsext] Design team report on dnssec-bis-upd… Anthony Iliopoulos
- Re: [dnsext] Design team report on dnssec-bis-upd… Samuel Weiler
- Re: [dnsext] Design team report on dnssec-bis-upd… Mark Andrews
- Re: [dnsext] Design team report on dnssec-bis-upd… Edward Lewis
- Re: [dnsext] Design team report on dnssec-bis-upd… Olafur Gudmundsson