[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.