Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston <[e-mail]>]

> On 3 Apr 2018, at 4:39 pm, Geoff Huston <[e-mail]> wrote:
> 
> 
> 
>> On 3 Apr 2018, at 1:10 pm, Mark Andrews <[e-mail]> wrote:
>> 
>> Do we really want to test for AD?  How many stub resolvers set DO or AD to elicit a AD response?
>> 
> 
> I’m not sure that we are on the same page here. The precondition is: "The AD bit is to be set in the response”  i.e. it is not a test on the query per se - it is a test on the response. Your comment appears to suggest that you believe that the text is asking for a test on the query. That is definitely not the intention of the text. i.e. it does not attempt to say what combination of flags in the query is used to signal that validation is to be applied (thats the role of RFC4035 and RFC6840), but the text is attempting to say “if the resolver has validated the response and is passing back a response that it is marking as being valid” then perform <actions>
> 
> I felt that saying that:
> 
>   o  The DNS response is DNSSEC validated
> 
>   o  the result of validation is "Secure"
> 
>   o  the AD bit is to be set in the response
> 
> would encompass this state. 
> 
> Is there a better way of saying this? Please suggest text if you believe that this could be stated more accurately.


heh - the more I read the DNSSEC RFCs the more confused I get!

After further reading I now suspect that Mark is right, and the 
AD bit test is _not_ what is wanted.

Section 3.2.3 of RFC4035  reads

3.2.3.  The AD Bit


   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic. 


So this text is saying that the AD bit is set if the resolver considers all
RRsets in the Answer section to be authentic. Fair enough.


But Section 5.8 of RFC 6840  reads:

5.8.  Setting the AD Bit on Replies

   Section 3.2.3 of [RFC4035] describes under which conditions a
   validating resolver should set or clear the AD bit in a response.  In
   order to interoperate with legacy stub resolvers and middleboxes that
   neither understand nor ignore the AD bit, validating resolvers SHOULD
   only set the AD bit when a response both meets the conditions listed
   in Section 3.2.3 of [RFC4035], and the request contained either a set
   DO bit or a set AD bit.

which appears to be saying that the AD bit is only set of the request contained
either a set DO ot a set AD bit.

What happens when neither DO nor AD is set in the request? 

Do you get a response that is authentic (but without any explicit signalling
in the response  that would indicate that authentication has occurred) or the
Servfail response in the case where authentication fails?

Or do you get a response that is not necessarily authenticated even though
the CD bit is not set?

If its the former then the AD bit may or may not be set on responses even though
they have been "DNSSEC validated”