Confused: the AD bit according to RFC2535. (fwd)

Roy Arends roy at nlnetlabs.nl
Tue Apr 4 20:54:53 UTC 2000


A Response to my question, earlier this week.
---------- Forwarded message ----------
Date: Tue, 04 Apr 2000 12:16:20 -0400
From: Donald E. Eastlake 3rd <dee3 at torque.pothole.com>
To: Roy Arends <roy at nlnetlabs.nl>
Cc: DNSEXT WG Mailing list <namedroppers at ops.ietf.org>
Subject: Re: Question regarding the AD bit according to RFC2535. 

Hi,

From:  Roy Arends <roy at nlnetlabs.nl>
Date:  Mon, 3 Apr 2000 20:32:16 +0200 (CEST)
To:  DNSEXT WG Mailing list <namedroppers at ops.ietf.org>
Message-ID:  <Pine.BSF.4.21.0004032028440.1675-100000 at open.nlnetlabs.nl>

>Hello,
>
>I've a little trouble understanding the value of the AD bit in a response.
>
>According to RFC2535:
>
>1. In section 6.1 it states: 
>   "The AD (authentic data) bit indicates in a response that all the data
>    included in the answer and authority portion of the response has been
>    authenticated by the server according to the policies of that server."

The intent was to mean that the data had passed all the checks the
server was going to impose.  This includes data that can not be
cryptographically verified because it is in an unsigned zone or a zone
such that the server does not have a key for that zone, or an
ancestor, staticly configured etc...  Note that it specifies the
answer and authority portions so, by impliation, the AD bit was
intended to say nothing about the additional information section.

>The definition of authenticated data:
>
>2. In section 6. it states:
>   "Authenticated means that the data has a valid SIG under a KEY 
>    traceable via a chain of zero or more SIG and KEY RRs allowed by the
>    resolvers policies to a KEY staticly configured at the resolver."

The use of the word "Authenenticated" in the above qutoed sentence was
in reference to the data statuses of Authenticated, Pending, Insecure,
and Bad defined in Section 6.  This usage is confusing.  Perhpas it
would have been better if this special usage of Authenticated were
replaced by "Cryptographically Verified".

>But is seems to contradict with the following statement in:
>
>3. In section 6.1 last paragraph:
>   "For non-security aware resolvers or security aware resolvers
>    requesting service by having the CD bit clear, security aware servers
>    MUST return only Authenticated or Insecure data in the answer and
>    authority sections with the AD bit set in the response."

The above quoted sentence correctly describes the intent.

>And also with the statement in:
>
>4. Appendix B: part 9:
>   "The AD bit only indicates that the answer and authority sections of
>    the response are authoritative."

Appendix B is the list of changes from the previous version.  The use
of the word "authoritative" in the above quoted sentence is confusing
because of the special meaning of "authoritative" in the DNS.  This
sentence is just pointing out that the additional information section
isn't covered by the AD bit, something which RFC 2535 tries to
clarify.  The full section is:

   9. It was clarified that the presence of the AD bit in a response
      does not apply to the additional information section or to glue
      address or delegation point NS RRs.  The AD bit only indicates
      that the answer and authority sections of the response are
      authoritative.

>In short:
>
>1 and 2 looks like the AD bit is indicating that the returned data is
>cryptographically checked.

The intent was to indicate that the data has passed whatever checks
the server cares to impose, which should be cryptographic where
possible, but can not in zones that are insecure from that server's
point of view.

>3 and 4 looks like the AD bit is indicating that the returned data is
>either cryptographically secure or is data from an insecure zone.

That was the intent, where "insecure" is defined from the point of
view of that server and depends on what keys it has staticly
configured, what algorithms it implements, etc.

>Can anyone clearify this matter ?
>
>TIA, regards,
>
>Roy Arends
>-- 
>roy at nlnetlabs.nl                NLnet Labs
>tel +31208884551                Kruislaan 419
>|\ ||   _  _|_  |   _ |_  _     1098 VA  Amsterdam
>| \||__| )(-|_  |__(_||_)_)     The Netherlands

Hope this is helpful,
Donald
===================================================================
 Donald E. Eastlake 3rd                    dee3 at torque.pothole.com
 65 Shindegan Hill Rd, RR#1                 lde008 at dma.isg.mot.com
 Carmel, NY 10512 USA     +1 914-276-2668(h)    +1 508-261-5434(w)






More information about the bind-users mailing list