Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt

Brian Wellington <Brian.Wellington@nominum.com> Fri, 20 July 2001 18:45 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27229 for <dnsext-archive@lists.ietf.org>; Fri, 20 Jul 2001 14:45:57 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nf5R-000GSW-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:33:17 -0700
Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Nf5R-000GSQ-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:33:17 -0700
Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nf54-0000p4-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:32:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Brian Wellington <Brian.Wellington@nominum.com>
To: Roy Arends <Roy.Arends@nominum.com>
cc: namedroppers@ops.ietf.org, ogud@ogud.com
Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt
In-Reply-To: <Pine.BSF.4.33.0107201521190.6025-100000@node10c4d.a2000.nl>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15Nf5R-000GSW-00@psg.com>
Date: Fri, 20 Jul 2001 11:33:17 -0700
Content-Transfer-Encoding: 7bit

On Fri, 20 Jul 2001, Roy Arends wrote:

> Hello, I would like to see some clarifications on the ***** marked
> sections.

> *****
> OK bit as in DNSSEC OK bit, specified in draft-ietf-dnsext-dnssec-okbit-02.txt
> ? If this is the case, please refer to it as DO (DNSSEC OK) bit.
> *****

Sure.  Olafur, want to fix this, since you have the source?

>                A DNS server following this modified specification will
>    only set the AD bit when it has cryptographically verified the data
>    in the answer. In the case of a primary server for a secure zone,
>    the data MAY be considered Authenticated, depending on local policy.
>
> *****
> I don't know how to read this.
>
> In the case of a primary server for a secure zone, the data MAY be
> considered Authenticated, depending on local policy, when what ?
> When the AD bit is set ? May it set the AD bit if it is the primary server
> for a secure zone, though the zone is actually not authenticated by the
> server ? The last sentence of the above section is a bit confusing.
> *****

"Authenticated" is a term defined in RFC 2535, section 6.  It is normally
used when referring to the security status of data on a recursive server.
This particular text says that the server may consider locally configured
data to be in the "Authenticated" state.


>    Secondary servers SHOULD NOT consider data Authenticated unless the
>    zone was transfered securely or the data was verified.
>
> *****
> or ? So if the zone was transferred securely, the secondary can consider
> the data Authenticated (and thus, set the AD bit) when it actually did not
> verify the contents of the zone ? I don't like it.
> *****

If the zone is transferred securely, then the secondary is guaranteed to
have the same data as the primary.  The primary is allowed to set AD
without verifying the data also.

>    This document redefines a bit in the DNS header.  If a resolver
>    trusts the value of the AD bit, it must be sure that the server is
>    using the updated definition, which is any server supporting the OK
>    bit.
>
> *****
> What are the implictions for the AD bit when the CD bit is set in a query.
> MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and
> optionally DO) bit is set ? The resolver is probably not interested in AD
> bit when CD bit is set, but a clarification would be good.
> *****

There are no implications.  Whether the AD bit is on in a response
reflects the security status of data, not whether CD was set in the query.
Even if CD is set, the response can have AD set if the data had already
been verified.

Brian



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.