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

From: Florian Weimer <[email-masked]>
Date: Fri, 03 Jul 2009 09:44:34 +0000

* Patrik Fältström:

> We have a problem when "a domain changes hands" and the private DS key
> in some way is changed, should be changed, and sometimes is not
> changed as it should. We all agree that could lead to a blackout, but
> in many cases the blackout is not more serious than a normal blackout
> when NS is changed.

Just as a general point, not really addressing any specific concern:
DNSSEC has *more* data to work with, so it is *easier* for a resolver
to detect a zone transition and properly handle it.  If you write a
resolver in a way which *extends* downtime, instead of reducing it,
you really aren't doing your job well.

Now there's the slight architectural complication that validation is
typically tacked onto the cache, without properly integrating it.
Obviously, it's a real pain to get the right bad data out of the cache
once you detect the problem in the validator.  If your resolver
suffers from this, it points out a major design issue.  Resolver
operators and implementors should deal with this, and not everyone
else.

I've been arguing for a while that this setup can't work reliable, is
undesirable for various reasons (including reliance on channel
security, which we want to get rid of by introducing DNSSEC!), and
should be deprecated.  This also applies to configurations were a
resolver forwards to another one which has fewer trust anchors.

Zone operators and domain owners can't predict resolver behavior
because the RFCs do not tightly specify it.  There is very likely no
way to make zone changes in a way that pleases all resolvers.  So most
operators don't even try to do it.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99