Re: New Version Notification for draft-gieben-epp-keyrelay-00.txt
Antoin Verschuren <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 25-01-13 15:22, Patrik Fältström schreef: > > If you look at the epp commands, in reality the change of NS (and > dnssec data, i.e. DS) in parent zone is made by one and only one > registrar. Either it is made by the gaining or donating registrar. Agreed > I think you should explain in what order various things happens. This is described in draft-koch-dnsop-dnssec-operator-change-04. This EPP draft only describes the missing EPP command that does not exist today and is needed as one of the steps in draft-koch-dnsop-dnssec-operator-change-04. We need to get a key from the gaining to the losing DNS operator. > If you have two DS in the parent zone, and only one of them can > validate the KSK, ZSK and signature, is that a failure? Not to me. > Ok, I now understand where the disagreement is. I do not think it > has to move. You are wrong. > The trouble is to have a gaining registrar add a DS while keeping > the old DS, and then only removing the old DS when one is pretty > darn sure the zone data for the old zone has expired in all > caches. We should discuss this on the dnsops mailinglist. > But I promise to talk with Peter Koch next time I meet him so that > I get told that I am wrong :-) Peter has writen down the text for the draft, but the issue originates with me, so I can answer as well. The problem is that a cache may have cached the DNSKEY RRset from the old zone, and while that is still valid the NS RRset changes at the parent and the resolver recieves a new NS (or other) RRset from the new child zone with a new signature from the new ZSK that is not present in the cached DNSKEY RRset thus failing validation. This can only be solved if both DNSKEY RRsets contain both ZSK's from the new and old child zone. Same as you would do with a pre-publish ZSK rollover. Transferring and keeping the old zone data on the new nameserver does not help, because at some point in time, at least the NS RRset needs to change and a new signature needs to be generated over it by a new ZSK that is not present in the DNSKEY RRset. A signature with the old ZSK over this new NS RRset cannot be generated because the old private ZSK is not available for signing by the new operator. Further discussion on this please on the dnsops mailinglist. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: [email protected] XMPP: [email protected] HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRAqT4AAoJEDqHrM883Agnum8H/0FYNE40Xa6t0q0euWWZYW/0 onhPlIrE+BRNpHfxtneIeiPIYOqzjbiAhJAu08ueBuwz0rxBGRHe+MSjpUKbe4vw Y9e4CM4PqlZuRzwwIFcLhipWqaaDCsFslurJirfJ+PL1C1vxTfLcUpXa3aDOEPfI IJ5ejHXktX2skmnTlaD/kyTnB9EWuDVAoAvzyl0cC9DG4U2/ac6c9cRsG8BIYCMI twCurvy2SK1K4SGjhNwDoMEZGIQfHSJqpI0uUHyL//GzrX5s4/aT3ybwa5q1QpIo BG7kdCJV6jmeFO5UP+q9g25lrly/EveZe3iI2rQTgbDloOfh487P5DFU4U6to4U= =aHCZ -----END PGP SIGNATURE----- _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg