* 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 <fwei...@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
