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

From: Brian Wellington <[email-masked]>
Date: Thu, 26 Jul 2001 10:19:16 -0700

On Thu, 26 Jul 2001, Ted Lindgreen wrote:

> Note: It would have been different, if BIND in the "recursive view"
> would actually check the data it is authorative for query-time,
> but as far as I know this is not in the code at the moment.

You missed the point again.  In the "recursive view", there is no
authoritative data.  There is only cached data.  If the cached data is
obtained from the "authoritative view", it's treated just like data
obtained from any other source, meaning it is validated at the time it's
received and the TTL is properly clamped.

Brian

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked] (Ted Lindgreen)
Date: Thu, 26 Jul 2001 04:19:53 -0700

[Quoting Andreas Gustafsson, on Jul 26,  4:58, in "Re: I-D ACTION:draft ..."]

> To use a separate view for DNSSEC validation, you simply make the view
> match the clients that are currently authorized to perform recursion.

OK, thanks for explaining this to me, I was heavily wondering how
views were supposed to clean up the definition of the AD-bit.  I now
understand what Roy meant, but this is an answer to another problem:
  "who is authorized to query for what?"
(See Note below).

So, let us go back to the topic.

Like Lewis said: it is the interpretation of the description of
the meaning of the AD-bit. Yes, a wording problems, and because
many of us aren't native English speakers a difficult problem.

A number of people interprete, or would like to interprete, the
AD-bit as something that would state that:

 The server tells us, by setting the AD-bit, that the answer is
 valid and secured by cryptographic authentication at the time
 that the query is answered by this server.

Some other people, however, interprete it as:

 A set AD-bit means that once in the past the data was valid
 and secured by cryptographic authentication.

Making an implementation sidestep (which is on-topic now, I hope,
because it helps understanding the protocol issue):

 With the second interpretation (in the BIND-9 implementation),
 we have the strange phenominum that the same server treats data for
 which it is authorative differently from recursively acquired data:
 - for the former it depends on local policy whether the answer is
   valid at query time.
 - for the latter, the software takes care, by active checking at
   acquiring-time and reducing TTL, if needed, for sig-expire, that
   at query time the answer is still valid.

 Now, in this specific implementation, one can go and try to distinguish
 between authorative and non-authorative servers and/or data  to
 make the AD-bit meaningful again at query-time. However, I am affraid
 we need not to wait long before we'll see alternative implementations
 which stretches the interpretation of the AD-bit further.

I think, and I guess everyone agrees, that we need to resolve
this issue NOW and to settle for one unambiguous interpretation.
And I think there are two choices:
1. If AD is set, the answer is valid at query time.
2. The AD bit has no meaning for the validity of the
   answer at query time.

This is so important, because it means a day and night difference
for both ISPs and people who are developing resolver software:

- if the AD-bit is meaningful at query-time, we can concentrate on
  securing communication between simple stub-resolvers and trusted
  secure aware nameservers. ISPs can prepare to install and maintain
  secure aware caching forwarders.
- if the AD-bit has no meaning at query-time, we better forget
  the former approach and go for "full-service" resolvers,
  which do the recursing and the checking internally. ISPs can
  skip the effort to install secure aware nameservers.

Regards,
-- ted