Re: [dnsext] Reminder: two WGLC closing in one week

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael StJohns writes:
> OK - so if the last chain validates, but the intermediate chain was unsecure, t
> hen you return the answer, but don't set the AD bit.  If the last chain doesn't
>  validate, you return what?  The data without the AD bit, or  RCODE 2/SERVFAIL?

	SERVFAIL.  If they ask with cd=1 then they get the full answer.

>   (I.e.is it really possible to have data that's both bogus and unsecure?)

	A particulare RRset is falls into exactly one of secure, insecure or
	bogus post validation.

> Is t
> here any reason to do validation for the third chain in my example once you've 
> wandered over into unsecure land?  

	Yes as you may be asked the later question.

> Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for 
> that matter) is your last conclusion stated as a specific protocol element?  I 
> just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to sa
> y this.  The definition for "secure" in 4.3 only says to trace from the answer 
> to a trust anchor.  The definition for insecure *could* be read to say what you
> said, but then it would be in conflict with the definition for "secure".

   A security-aware 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.  A security-aware
   name server's local policy MAY consider data from an authoritative
   zone to be authentic without further validation.  However, the name
   server MUST NOT do so unless the name server obtained the
   authoritative zone via secure means (such as a secure zone transfer
   mechanism) and MUST NOT do so unless this behavior has been
   configured explicitly.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

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