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

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Jun 2009 11:15:52 -0400 (EDT)

On Wed, 1 Jul 2009, Mark Andrews wrote:

> 	Validators shouldn't have to refetch DS records to work
> 	around a broken key rollover.

[ process where everyone co-operates and lives happilly and forever after ]

This is just not going to happen, and any modifications to the validators
should take the real world into account.

>>> records have changed once validation fails. Search for a changed =20
>>> chain of trust.
>>
>> Agree is this good.
>
> Can you say DoS attack?

It needs to be implemented properly and safely, yes.

> Can we stop giving up before we have tried to make this work properly?

We can, but DNS operators in general won't, and so we have to accomodate
that scenario anyway. losing DNS operators can't even run secondary on
gaining DNS operators. And what you're proposing is at least a 4 message
exchange between two entities. It's not going to happen.

> Publish a BCP on how to do this.  Seller and buyers alike can
> offer/request BCP compliance.  Failure to follow BCP is not likely
> to a seller if they end up in court for deliberately damaging the
> property they are selling.

When domains move, there is usually already enough trouble between
Registrant and DNS operator. Not timely cooperating because of "business
priorities" will be impossible to attack in court. So yes, its fairly
easy for the losing DNS operator to give that last kick.

> It's like you trashing a house as you move out if you fail to follow the BCP.

It's more like trashing the house you lost in a forclosure. Either way,
you're not seeing the money. You might as well cause some damage.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Jul 2009 09:05:14 +1000

In message <[email-masked]>, Daniel Kalchev writes:
> 
> 
> 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.
> >   
> 
> This will probably one work when the registrant themselves manages their 
> DNS zone (possibly on someone else's hardware).
> It will probably fail to work, because the question "why is my domain 
> not yet transfered" cannot get reasonable answer.
> 
> The most common scenario today involves a third party, we chose to call 
> "DNS Operator". The specific DNSSEC problem, as I see it now, happens 
> when you change those outsourced DNS Operators when those operators also 
> perform DNSSEC maintenance.
> 
> Here is an example:
> 
> Today, DNSSEC is a new toy. We are sort of lucky so far, that not many 
> have attempted to commercialize on it -- which in my opinion happens, 
> because none of the gTLDs support DNSSEC yet. But sooner or later this 
> will happen.
> 
> Then, some of the DNS hosting companies will start offering "better" 
> service, including automatic DNSSEC signing of the domains they serve. 
> This is already happening, but in relatively small scale. Someone 
> registers a domain name, signs up for their service (or it so happens, 
> because they chose someone's hosting plan) and even without knowing gets 
> DNSSEC for their domain.
> 
> After a while, they get unhappy with their hosting provider and decide 
> to move. Upon moving, they also change (often, without being aware) 
> their DNS hosting provider. In most such scenarios, today, DNSSEC will 
> break. It may break bad. As already mentioned, the party that will be 
> hit by this situation is the ISP that chose to resolve DNSSEC.... and 
> this will decrease their incentive, because companinig customers means 
> less $$$ and managers cannot care less about DNSSEC.

	Plain DNS also breaks.   Resolvers get locked on the old
	servers and don't shift to the new servers.   If the old
	hoster notices and shuts down the zone then resolvers with
	the old NS records cached just stop receiving answers.
 
> To make matters worse, some of their hosting companies and/or DNS 
> hosting companies happen to be Registrars. Some even become Registrars 
> only because this eases their automation.
> 
> This is the issue we should focus on, in my opinion, because all other 
> cases, with more or less knowleable and controlled DNS transfer can be 
> handled with just publishing the proper "how-to".

	We know how to switch smoothly for both plain and secure
	DNS.  It really is a matter of making this happen for both
	types.  Registries should not process a update if it will
	result in a broken zone for plain or secure DNS without
	explict notification that the owner is aware that it will
	result in a service discontinuity.

	Make it expected behaviour and it will happen. The current
	problem is a result of registries not taking control to
	ensure that errors are not occuring.  It is time for such
	slack practices to cease.

	Mark

> Daniel Kalchev
> Register.BG
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]