[dnsext] Design team report on dnssec-bis-updates and CD bit
Andrew Sullivan <ajs@shinkuro.com> Fri, 09 July 2010 14:28 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 6068A3A6A2F; Fri, 9 Jul 2010 07:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.548
X-Spam-Level: *
X-Spam-Status: No, score=1.548 tagged_above=-999 required=5 tests=[AWL=-1.266, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1]
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 hQlkm1QknFhD; Fri, 9 Jul 2010 07:28:46 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D553B3A68C8; Fri, 9 Jul 2010 07:28:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OXESE-000KKF-2l for namedroppers-data0@psg.com; Fri, 09 Jul 2010 14:21:26 +0000
Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <ajs@shinkuro.com>) id 1OXESA-000KIy-MW for namedroppers@ops.ietf.org; Fri, 09 Jul 2010 14:21:23 +0000
Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 02CA11ECB408 for <namedroppers@ops.ietf.org>; Fri, 9 Jul 2010 14:21:18 +0000 (UTC)
Date: Fri, 09 Jul 2010 10:21:08 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: namedroppers@ops.ietf.org
Subject: [dnsext] Design team report on dnssec-bis-updates and CD bit
Message-ID: <20100709142108.GA68527@shinkuro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
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/>
Dear colleagues, On 2010-07-06, there was a design team meeting in Bethesda, MD, to address the issue of setting the CD bit in the dnssec-bis-updates draft. David Blacka, Olafur Gudmundsson, Mike StJohns, and Andrew Sullivan attended. We convened the meeting because there had been a lot of discussion on the mailing list about the handling of the CD bit, and we didn't seem to be reaching a resolution. The meeting was very helpful to the chairs, and we thank David and Mike for taking the time. In the meeting, we concluded by describing three different models for how the CD bit is to be treated and used by a validating resolver (i.e. one that has at least one trust anchor), and what interaction this has with a local cache. We based these models on RFC 4035, on the discussion we saw on the list on this topic, and on what we think people have implemented. We want one, and only one, of these models to be described in the draft as the standard model. These models are outlined below. The design team noted that the generic model of stub resolver talking to recursive resolver talking to authoritative server, while the most common for any given query, is not the only possible model. In particular, it is possible (by configuration or proxy interception) for there to be more than one recursive (and possibly validating) resolver between the client and the authoritative server. The design team reaffirmed that 4035 does not adequately address the setting of the CD bit on queries originated, forwarded or recursed from an intermediate validating resolver. The team relied on the assumption that an intermediate validating resolver is required to set CD=1 for any upstream query where the original query also had the CD bit set. That restriction has been explicit in the dnssec-bis-updates draft since version -09, and participants thought it uncontroversial. The following tables reflect that consensus. The tables that describe the model have five columns. The first column indicates the value of the CD bit that the resolver receives (for instance, on the name server side in an iterative resolver, or as local policy or from the API in the case of a stub). The next column indicates whether the query needs to be forwarded for resolution (F) or can be satisfied from a local cache (C). The next column is a line number, so that it can be referred to later in the table and later in our discussion. The next column indicates any relevant conditions at the resolver: whether the resolver has a covering trust anchor, and so on (if there are no parameters here, the column is empty). The final column indicates what the resolver does. The tables differentiate between "cached data" and "cached RCODE=2". This is supposed to be shorthand; the point is that one has to treat RCODE=2 as special, because it might indicate a validation failure somewhere upstream. The distinction is really between "cached RCODE=2" and "cached everything else". If you have a better way to capture this in short language, your suggestion would be appreciated The tables are probably easiest to think of in terms of describing what happens when a stub resolver sends a query to an intermediate resolver, but they are perfectly general and can be applied to any validating resolver (e.g. a resolver of any sort forwarding to another resolver). Model 1: "always set" This model is so named because the validating resolver sets the CD bit on queries it makes regardless of whether it has a covering trust anchor for the query. The general philosophy represented by this table is that only one resolver should be responsible for validation irrespective of the possibility that an upstream resolver may be present and with TAs that cover different or additional QNAMEs. CD F/C line conditions action ======================================================================= 1 F A1 Set CD=1 on upstream query 0 F A2 Set CD=1 on upstream query 1 C A3 Return the cache contents (data or RCODE=2) 0 C A4 no covering TA Return cache contents (data or RCODE=2) 0 C A5 covering TA Validate cached result and return it. Model 2: "never set" This model is so named because it sets CD=0 on upstream queries for all received CD=0 queries even if it has a covering trust anchor. ("Never" is really too strong: obviously, if the query arrives at the resolver with CD=1, it must set CD when it performs the query as well.) The general philosophy represented by this table is that more than one resolver may take responsibility for validating a QNAME and that a validation failure for a QNAME by any resolver in the chain is a validation failure for the query. CD F/C line conditions action ======================================================================= 1 F N1 Set CD=1 on upstream query 0 F N2 Set CD=0 on upstream query 1 C N3 cached data Return cached data 1 C N4 cached RCODE=2 Treat as line N1 0 C N5 no covering TA Return cache contents (data or RCODE=2) 0 C N6 covering TA & Treat as line N2 cached data was generated with CD=1 0 C N7 covering TA & Validate and return cached data was generated with CD=0 Model 3: "sometimes set" This model is so named because it sets the CD bit on upstream queries triggered by received CD=0 queries based on whether the validator has a TA configured that covers the query. If there is no covering TA, the resolver clears the CD bit in the upstream query. If there is a covering TA, it sets CD=1 and performs validation itself. The general philosophy represented by this table is that a resolver should try and validate QNAMEs for which is has trust anchors and should not preclude validation by other resolvers for QNAMEs for which it does not have covering trust anchors. CD F/C line conditions action ======================================================================= 1 F S1 Set CD=1 on upstream query 0 F S2 covering TA Set CD=1 on upstream query 0 F S3 no covering TA Set CD=0 on upstream query 1 C S4 cached data Return cached data 1 C S5 cached RCODE=2 Treat as line S1 0 C S6 cached data was Return cache contents generated with CD=0 0 C S7 cached data was Validate & return cache generated with contents CD=1 & covering TA 0 C S8 cached RCODE=2 Return cache contents 0 C S9 cached data Treat as line S3 was generated with CD=1 & no covering TA 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. Best regards, Andrew (as design team stenographer) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc.
- [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