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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael StJohns writes:
> Hi Andrew -
> 
> At Scott's request I took a look at the dname document.  Keep in mind that I'm 
> looking at it pretty much for the first time.  Unfortunately, I don't think its
>  ready for prime-time.  Most of the document is fine - but the section on DNSSE
> C is woefully lacking.
> 
> DNSSEC unfortunately makes things more difficult.  Having DNAMEs plus DNSSEC st
> retches the complications almost to the breaking.

	How?
 
> The section needs more than a 1 page description of why DNSSEC servers need to 
> understand DNAME, it needs a discussion of the various combinations of modes in
> which a resolver can find itself when following a DNAME chain.

	Why?  DNAME is a method to synthesis a CNAME.  Once you have the
	CNAME you give it the *same* trust level that you gave the DNAME
	and proceed as if there was just a CNAME there.
 
> For example - what happens if the DNAME is signed, but the referenced target is
> n't?

	What happens if a CNAME validates and the name it points to doesn't?

> What happens if both are signed, but the resolver doesn't have a trust an
> chor for the target but has one for the DNAME?  For the DNAME but not the target

	What happens if a CNAME is signed an it's target is signed but you
	don't have a trust anchor for the target?

> ?  What happens if the DNAME is directly reachable (e.g. querier is a validatin
> g recursive resolver) but the target is available only through a forwarder?

	What happens is the CNAME is directly reachable but the target is
	available only through a forwarder?

> What happens if the DNAME and the target are signed with different algorithm
> and the querier only understands one of they.

	What happens if the CNAME and the target are signed with different
	algorithm and the  querier only understands one of they?

> I can see about a number of  different ways to have different resolvers behave 
> given different combinations.  I think they need to be called out and a specifi
> c behavior proposed for each prior to sending this forward.

	Why.  The answers to DNAME are really no different to how you handle
	the CNAME.

	The only thing really different about DNAME is to handle YXDOMAIN.

	Mark
 
> One proposal, once the "must be signed bit" is set (e.g. DNAME or target subord
> inate to a trust anchor without a delegation to unsecure), then ALL data must b
> e signed to be considered valid.  (Not sure this is the right way of doing thin
> gs, but its a conversation starter).
> 
> Sorry - Mike
-- 
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/>