Subject: Re: Fw: DNSSECbis Q-16 suggested text CORRECTION

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 2 Sep 2003 14:28:25 -0700 (PDT)

Scott Rose writes:
> The last sentence should read:  "However, if the DO bit is not set, the name
> server side MUST strip all DNSSEC related RRsets from the final response."

That is not what the DO bit does.  DO=0 does not cause the server to
"strip all DNSSEC related RRsets from the response" - it just causes
it to not add DNSSEC related RRs authenticating the response.  RFC3225
section 3 says:

   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
   or NXT RRs to authenticate a response as specified in [RFC2535]
   unless the DO bit was set on the request.  Security records that
   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
   zone data for an AXFR or IXFR query, are included whether or not the
   DO bit was set.

Therefore, to correctly reflect the semantics of DO, the last sentence
would have to say something like "However, if the DO bit is not set,
the name server side MUST strip any DNSSEC RRs that the resolver side
may have added to authenticate the response", and perhaps even add
"but MUST NOT strip any DNSSEC RRs explicitly requested".
-- 
Andreas Gustafsson, [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 3 Sep 2003 08:52:38 -0400

Agreed, the suggestion is much clearer that way.  A recursive nameserver
must not send any DNSSEC RRs added for authentication back to the
originating client (unless explicitly queried by the client resolver).

My main goal with the text I suggested was to allow a recursive, caching
server the option of following its own local policy if it can mesh it with a
client's specific request options.

Scott

---

From: Rob Austein <[email-masked]>
Date: Wed, 03 Sep 2003 14:10:30 -0400

At Tue, 2 Sep 2003 14:28:25 -0700 (PDT), Andreas Gustafsson wrote:
> may have added to authenticate the response",

I have a minor issue with "that the resolver side may have added",
because if one believes in the "blob caching" theory, the resolver
doesn't add anything, it just spits out everything it received in
response to a particular <QNAME,QTYPE,QCLASS> triple verbatim (other
than adjusting TTLs and so forth) rather than attempting to piece
together answers from individual cached RRsets.

(Yes, I know that piecing answers together from individual RRsets is
traditional, and indeed, all the resolver code I've ever written does
it that way, but over the last year or so I've become convinced that
the blob caching approach is more robust, particularly as we add more
and more baroque stuff to the DNS in an attempt to add new features
while maintaining backwards compatability.)

But I think this is getting past the point of diminishing returns for
wordsmithing at this stage, and I think we agree on the interaction
between CD and DO, which was the point of this thread.

> and perhaps even add "but MUST NOT strip any DNSSEC RRs explicitly
> requested".

Agreed.