[dnssec-deployment] How does it work?

[Mark Andrews]

In message <list-17767736 at execdsl.com>, Andrew Sullivan writes:
> On Wed, Jun 24, 2009 at 05:07:36PM -0400, Matt Larson wrote:
> > On Wed, 24 Jun 2009, Andrew Sullivan wrote:
> > > Sure, having the extra DS in the parent is not a risk.  But keeping
> > > that extra DS at the parent does not ensure that there will not be
> > > validation failures.
> > 
> > I disagree.  I think we are making this situation too complicated.  If
> > a registrant adds a DS in the parent for its new key at the new DNS
> > hosting provider far enough in advance of the transfer, and keeps the
> > old DS record in place long enough after the transfer, then both
> > signed versions of the zone (pre- and post-transfer) are covered.
> 
> No, this is exactly the claim I dispute.  I'd like to be wrong, so
> perhaps someone can explain what I've missed.   (See also Olafur's
> message down-thread).
> 
> If no caches were involved, then obviously if the parent has both
> DS(new) and DS(old), there'd be no problem.  For any validation, the
> validator would get the RRSIG covering the target record, the DNSKEY
> from the same name server set, and the DS set from the parent.  Either
> the validator would get RRSIG(new) or RRSIG(old) and DNSKEY(new) and
> DNSKEY(old), because the validator would be talking to the one name
> server set (new) or (old).  Since DS records for both (new) and (old)
> would be in the parent, the DS would cover no matter what.
> 
> With caches in place, however, the game changes.  Suppose a cache has
> DNSKEY(old) and then (old) stops responding.  The cache will try other
> NS in the NS RRSET, and might go to (new) as a result.  Now the
> DNSKEY(old) will be used trying to validate RRSIG(new), and you'll get
> a validation failure.  Zone goes dark.
> 
> Therefore, it is necessary that each side's ZSK be signed by the other
> sides KSK, or else this mixture of records from the different name
> servers will cause validation failures.

	Agreed.

	The new owners generates KSK and ZSKs for each algorithm
	in use these are added to the existing DNSKEYs. Both the
	old and the new owners sign the DNSKEY RRset.  The resulting
	RRSIGs are published the is published the max ttl of any
	record in the zone prior to transfer.  DS for the new KSKs
	are also added to the parent.  The new operator then generates
	the new zone as it will be at using only their keys generated
	above.  At transfer time all the old servers transfer in
	the new content.  After all the old NS RRsets have expired
	from caches taking into account both the parent and child
	ttls the zone can be decommision on the old servers. After
	the old DNSKEY ttl has expired the old DS records can be
	removed.
 
> I realise that I've still oversimplified here, because there's the
> issue of cache stickiness and such like as well.

	Which is solved by the old servers serving the new content.

> But that's a
> complication on an already complicated scenario, so I've left it out
> to focus on just the above issue first.
> 
> A
> 
> -- 
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> 
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnss
> ec-deployment/>
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org