Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?

[bmanning@vacation.karoshi.com]

On Sat, Jul 26, 2008 at 12:21:47PM -0400, Brian Dickson wrote:
> Stephane Bortzmeyer wrote:
> >On Sat, Jul 26, 2008 at 01:14:08AM +0200,
> > Roy Arends <roy@nominet.org.uk> wrote 
> > a message of 28 lines which said:
> >
> >  
> >>When a validator has a trust anchor configured for root, it _expects_ 
> >>signatures for root. 
> >>    
> >
> >Which means there is no way back? If we sign ".fr", and people start
> >to configure the trust anchor for ".fr" in their validating resolvers,
> >we can no longer revert to the original, non-signed, system, should
> >problems occur?
> >
> >Am I correct? AFAIK, DNSSEC has no way to express policies (in a
> >RFC5016-like way) such as "should be signed".
> >  
> 
> You are correct.
> 
> However, if the root was signed, there would be no need for having 
> separate trust anchors configured
> for a signed .fr.

	presuming facts not in evidence.
	how are you to -know- that the root has the "right" DS for .FR?
	most operational keystores will have at least four keys and likely 
	operational practice will be, roughly 3 per relevant org; the current,
	the immediate past, and the next future key.

	as a grad student, I will likely have keys from (at least) these places:

	my school, the parent org (.EDU), the root, the LIR, the RIR.

	that looks like 15 keys... :)

	
> And, this would mean that turning on or off the status of "is .fr 
> signed?" could be handed from the root
> zone, allowing *relative* ease in backing out the signing of any TLD. No 
> configuration changes would
> be needed by the operators of validating resolvers.
> 
> (IMHO, in addition to signing the root zone, there need to be changes to 
> the speed with which changes
> of a technical nature can be made, once the technical administration of 
> a TLD has been authoritatively
> and contractually delegated to an entity. Those include changes to A and 
> AAAA glue records, and
> addition/removal of DNSSEC signatures (and thus the 
> "signed"/"not-signed" status).)
> 
> Brian
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

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