In message <[email protected]>, 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 protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
