Subject: Re: [DNSOP] [dnssec-deployment] Problems with DS change in registry/registrar environment

From: Patrik Fältström <[email-masked]>
Date: Wed, 1 Jul 2009 16:01:33 +0200

On 30 jun 2009, at 16.43, Mark Andrews wrote:

> 	This is simultaneous roll of KSK and ZSK keys.  You introduce
> 	the keys the *same* way as you would with a single operator.
> 	The new operator generates new keys.  The are added to the
> 	existing DNSKEY RRset and the resulting RRset is signed by
> 	all the KSKs (old and new).  DS are added to the parent for
> 	then new KSKs.  Wait for the pre-change DS and DNSKEYs to
> 	expire from caches.  You use the new ZSK keys to sign the
> 	zone content.  If you are changing servers as well you make
> 	the the old servers serve the new zone content.  Once all
> 	the old zone content has timed out of caches you remove the
> 	old keys.  If you changed servers this is the time to
> 	decommision the zone on the old servers.

I do not think this will work, as I do not think the old zone  
maintainer have interest in cooperating. He is hopefully continuing to  
host the old version of the zone for a while, and the question is what  
happens in the overlap, whether the content of the parent zone helps  
etc.

I think we have the following states, but first background.

We have the registry, that is the zone maintainer of the parent zone.

We have a registrar that only do things "on behalf of the registrant".

The registrant changes zone maintainer, from A to B. There is no  
cooperation between them, and the change from A to B implies both NS,  
KSK and ZSK changes. We have NSA, NSB, KSKA, KSKB, ZSKA and ZSKB.

Once again, A is not cooperating.

Question is now, what should B do to make the change from A to B as  
smooth as possible?

On NSA we have the "old zone" that contain part from the records also  
ZSKA and KSKA, and the zone is signed with ZSKA.

On NSB we have the ability to place "the old zone", but we can only  
sign with ZSKB.

In the parent zone, we can add DS for KSKB without removing DS for KSKA.

We of course have TTLs and a mix of cached and non-cached records all  
over the place.

Now...

I was hoping that by adding the DS for KSKB to the parent, and having  
B signing the old zone with ZSKB, that would minimize the blackout.

NSA is removed from the parent zone, and from that point in time, only  
caches have the info that NSA exists, so only from caches you will  
find NSA.

After a while, the old NS records (NSA) will have timed out, and only  
actual content (including KSKA and ZSKA and SIG etc) will be cached  
here and there.

Queries that hit the parent in the meantime will see DS for both KSKA  
and KSKB, but only NS that refer to the nameservers that B run, and  
there you find a zone only signed with ZSKB. No signatures made with  
ZSKA.

Queries that hit NSA will find data only signed with ZSKA, while DS in  
parent exists for both KSKA and KSKB (if re-fetched).

After all data has timed out from the old zone (including old sig's  
made with ZSKA), one can remove KSKA and ZSKA from zone, and remove DS  
referring to KSKA from parent.

I.e. I thought that as long as one of the DS in the parent zone refer  
to a KSK that in turn sign a ZSK that sign the zone, things will be  
fine. So by having DS referring to both old and new KSK, we will be  
ok, although only one of the trust chains will exist at each point in  
time (for each validating client).

Now, there might be cases when partial data is fetched from NSA and  
NSB, but how bad can it get, as signatures comes with the record, and  
the signatures are related to either ZSKA or ZSKB? If ZSK-material is  
fetched from NSA, while KSK data is fetched form NSB? Then of course  
there is no chain of trust.

But what is the risk for that? And to be honest, I do not see any way  
out of this, without cooperation from both NSA and NSB.

     Patrik

---

From: "Antoin Verschuren" <[email-masked]>
Date: Wed, 1 Jul 2009 20:59:29 +0200

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Subject: Re: [dnssec-deployment] [DNSOP] Problems with DS change in
> registry/registrar environment
> 

Minimize here means a blackout of maximum A's DNSKEY TTL.
Sensible values would be 1 day, but in protocol theory it could be much longer.
And in the case of "sticky" resolvers that do TTL stretching, it could be much worse.
In theory as long as A keeps serving the authoritative data.

Perhaps ok for an academic zone that understands and has prepared and announced the change well, but intolerable for a web shop to lose a day's profit just because he changes supplier.

> out of this, without cooperation from both NSA and NSB.

It's not only the risk. It's also the impact.
If "some sites" stop working when turning on DNSSEC at a resolver, what do you think customer orientated ISP's will do.
And would the web shop owner have his zone signed if it would mean he's stuck to his supplier if he doesn't want outage ?

As far as I know, there are only 2 solutions.

While I agree with Mark most of the time that zone maintainers should do sensible things and do the job they were hired for, I do think the process is too complex for our current installed base of DNS-operators. It would mean cooperation of 2 competitors. Operator A has to receive B's DNSKEY, sign it and put it in A's zone. Even though his customer has already left him. That can only be mandated by policy from the parent, and we all know how hard that is.

The other option would be to handle this in resolvers.
What basically happens is a modification in the chain of trust, that the resolver is unaware of while trying to validate.
You could have the resolver verify the chain of trust once a validation fails.
Do a DS query at the parent. If there's a DS that doesn't match the cached DNSKEY, remove it from the cache and requery.
The only issue is indeed how often this should occur to prevent DOS.
Preferably only once per DNSKEY TTL, but how does a resolver keep track of that..

Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]  http://www.sidn.nl/