-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > -----Original Message----- > From: Patrik Fältström [mailto:pat...@frobbit.se] > Subject: Re: [dnssec-deployment] [DNSOP] Problems with DS change in > registry/registrar environment > > 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.
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. > 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. 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:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSkuyETqHrM883AgnAQgBlAgA1W9LRlj4MpesUrKAtxdz+hgLGgh/6C1L Ni/103L3P0H1W6p0+alWlccs58pqmR+OLPvJ2LxSZYJyVRQ1OltdWx68/9hdg38r AvzBVDEFs5tXoQRB+edSOOSYB7f9rlb9GB2oAlIdcTvVB8j3T0bWsF4I9U2nIemH osZlapsSO6rvgjyfqV5HV8mCpNcZ6w7bgX6GyGVPk2Pcqxvgb8Y0HAaoFowvVRyg UdfIjCul5Me4Qs/50+zSQ3tmd+uZRqmzezOYToNz3pOxFUYiEb1e+5HSlCq4JLhy AdsHuobdy7OQ3mFuHb6qgPR08iMVqFopqtEHLcUZU0URN/kcICRa/A== =fiub -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
