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

[Michael StJohns <[e-mail]>]

After thinking about this topic for a while, I'm still bothered by the inconsistency of treatment here.

But I think I have a possible mechanism - at least for DNAME.

DNAME is the pretty much the equivalent of a delegation - only sideways.    Why not treat it like any other delegation?  In other words, in addition to the records currently permitted at a DNAME node, add DS to the list.  This would require slightly overloading the meaning of DS, but in a way that doesn't break the model too much.

If a DNAME node does not have at least one corresponding DS record (proven by NSEC/NSEC3), the validation rules are exactly the same as if you'd not included a DS for a subordinate delegation. E.g. no DNSSEC is expected in the target zone.

Since one of either DNAMEs or NS records can be present at a node (I think that's correct), the interpretation of the DS record is dependent on which of these two is present.  If the type is DNAME, the DS record points to a DNSKEY record at the target name and the chain has to continue from there.

This gets away from the problem where a resolver has one trust anchor, but doesn't have a trust anchor for the target zone at the cost of requiring some administration of the DS at the DNAME.

Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. DNAME without DS), you *stop* doing DNSSEC validation.  It doesn't matter if you have trust anchors for any further targets - the validation answer is UNSECURE.  This is required for consistency - different resolvers have different sets of trust anchors.  It's not all that coherent to get BOGUS from one, UNSECURE from another and UNKNOWN from a third if you can avoid it.  Chaining security back to the original trust anchor and evaluating security in terms of data that chains back ONLY to that trust anchor seems to be the most consistent approach.

In any event, I think this is at least somewhat backwards compatible. 

Let the mud slinging begin... :-)

Mike


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