Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

[Michael StJohns <[e-mail]>]

Hi Ed -

I agree that you can determine the security state of X and the security state of Y by examining trust anchors, dlv etc.  But that's not the question.  The question is "What is the security state of the compound answer XY?"

 From Marc Andrew's and somewhat from Wouter's email, it could be a new state "unauthenticated" - because the response out of an intermediate resolver is to return the data but not set the AD bit.  I say new, because it's different than unknown, secure,  and bogus and wouldn't be returned for the same reasons that you would return it for unsecure data under a single trust anchor.  But even that begs the question of what an application should do with it.

Later, Mike





At 09:45 AM 10/13/2008, Edward Lewis wrote:
>At 7:38 -0400 10/13/08, Michael StJohns wrote:
>
>>...CNAME and DNAME do not have any way of indicating the expected security
>>state of the zone to which they point.  ...
>
>Yes they do.  For X CNAME Y, you can determine the security state of X by flowing down from the root and you can tell the security state of Y by flowing down from the root.  Just as X is not "delegating" to Y in the sense of NS's, X is not transferring any security state to Y.  X is simply referring to Y. Ditto if this is a DNAME situation.
>
>
>                                     .               (assume a "signed" root)
>                             ------/ | \------
>                            /        |        \
>                            S        S        S      (S=secure zone)
>                            |        |        |
>                            S        S        S
>                            |        |        |
>                            S        U        S      (U=insecure zone)
>                            |        |        |
>                            X CNAME  Y DNAME  Z
>                                              |
>                                              W
>
>In this case, X has a secured reference to Y.  Y isn't protected and has a rewrite rule to Z.  Z is secured.  You see from inspection from a (signed) root down that there is no break in the chain to X and Z, but there is the break to Y.
>
>DNSSEC is protecting the querier in that you get to validate what you can (where there is data).  But does that help the application?  Not really.  This is why I think DNSSEC is there just to benefit the DNS, not the application.
>-- 
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                [phone]
>NeuStar
>
>Never confuse activity with progress.  Activity pays more.



--
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/>