-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Paul Wouters > Subject: [DNSOP] Comments/Additions on I-D Action:draft-ietf-dnsop- > rfc4641bis-01.txt > > 4.4.5 > > (remove use of "registrar A" and "registrar B" and only use "gaining > registrar" and "losing registrar")
I would actually like the Registrar be replaced by DNS-operator, to catch all scenarios of moving zones around. Gaining DNS-operator and Losing DNS-operator that would be. > "One could proceed with a pre-publish ZSK rollover whereby registrar > A pre-publishes the ZSK of registrar B [...]" > > I assume KSK, not ZSK is meant here? I don't think ZSK handovers should > ever > be needed (see below) > > The gaining registrar adds the losing's registrar's public KSK in their > zone. > (can be done without cooperation). They then add their own KSK and ZSK, Where do you add these ? In the gaining DNS-operator's yet unpublished and unvalidated zone, or the losing DNS-operator's currently published and validated zone (which means cooperation by the losing registrar). > and > then do the transfer. Remember: doing the transfer means changing the child zone (the NS set changes), and thus signing these new records with the currently published and cached ZSK. > Next, the DS has changed, but anything cached and > signed with the old (cached) KSK is still considered valid. So how would that work if the old key is still cached, and a new record pops up that is signed with the new key but not with the old one ? Or would that be handled by having 2 DS records at the parent ? Would a validator go back to the parent to get the new DS record ? I would be very interested in this scenario, but I think that while writing it down you'll see that with current caching behavior, there would always be a scenario that fails to validate. DNSKEY and other RR's of the same zone are not always cached with the same TTL. > Even if losing > registrar tried to be evil, eg give the losing KSK insane lifetimes, could > the gaining registry opt to keep that losing KSK valid for longer. > > "The only viable option for the registrant is to publish its zone > unsigned and ask the registry to remove the DS" > > The case of cached data by long evil TTL's of ZSK's that don't exist > anymore > (or for short ones that don't exist where no maliciousness is involved) > could > be handled by validators by simple removing any signed data from the cache > for > which no valid key (through dnssec validation) can be found and optionally > retry to obtain that data with exponential back off. So that would mean changing a validator's behaviour from what a resolver is currently doing... Is that a viable suggestion that needs to be written down somewhere ? Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E [email protected] W http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSfa68TqHrM883AgnAQjOzQf/TkgMJWPo95YaO46rto1oDfVVzTRHOYap T69gNABsxRwp6htgrxqkcVQ32VZ1uh6QBN9+DJwGbTZ9BwccvPHSBCpDJK4/wr+s mZy0sIDa+qcPfXcd/XwvxFZ1fkLnnp62jm/52X/IJACmZ9VoeUI5fRffGgT+QubQ OvwXDYxNTBbnOjjdNPGGNOnuu7bljKkE6bgVeZgUrD4i/LDgcmWW07ry4xMLcCtJ RN+WDuboxiEZ1pYLFheG/n/Uc/3nzv6AnWIhq7wb9A2Hko7S6Esl4aII6JoaOFJH vTuvRBb4QzgjpX0mPuHDYIqyDrFZTDsNQAVLbkL3FQBZLmLqpHO/bg== =oHQ1 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
