-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-07-11 11:51, Marc Lampo wrote: > Dear all, > > http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt > > There does not seem to be a lot of feedback on this draft ? > (some comments on version 01 only)
I have read the draft, and I have given it some thought. Though I advocate a child-parent signalling method for key roll-overs, I think this is not the correct way forward, and I'll explain why. As a registry for .nl we have decided not to accept DS records from childs, but DNSKEY instead, and calculate the DS ourselves. The reason for this is multiple, but the major considerations are that since the DS is on the parent side of the zone cut, we want to be able to control the supported hashing algorithm for the DS in our zone, and be able to change to a new algorithm without child interaction. The major reason however is that when supporting a secure DNSSEC dns-operator change, the registry will act as a relay for the DNSKEY from the losing dns-operator to the new one, so in this process we need to request the DNSKEY anyway. We don't want to request the DS and only in the dns-operator change case request the DNSKEY as well or instead. So since we don't accept DS, we will not support the CDS signalling. What we think is a way forward is a way for the child to signal that a new DNSKEY has appeared in the child zone that needs a DS at the parent, or a way to signal a DNSKEY set that should have a corresponding DS at the parent. Some thoughts: The SEP bit could be used for this but then not all keys with the SEP bit may need a DS at the parent. Perhaps we need another bit for this ? I realise the SEP bit does not have this meaning right now, but I see no hindrance in changing that definition. A NOTIFY from child to parent may then be sufficient for the parent to determine which keys need a DS. But how does the child identify which parent server to send the NOTIFY to ? And how does the receiving server at the parent know what to do with the NOTIFY ? And does a child always want to publish a DNSKEY in the zone before a DS should be present at the parent, or should it be able to request a DS for a DNSKEY before the DNSKEY is present in the zone ? In the dns-operator change case, the DNSKEY's with this bit set should therefore also be present in both zones, so not only both ZSK's (in a KSK/ZSK case). This may change 4641bis again... hope to have discussions next week - -- 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:[email protected] xmpp:[email protected] http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOKA/nAAoJEDqHrM883AgndQ4H/3GcJstvRElwkOKPv2ctEPBe OeU6pb0Jfbr8pxfy72u21834pBZGs0ucH6/cdpXxS4wpPXxqJ8Mb5yMWlFIxU1kL SbpWJLHDVge64f3Hy4pf67tCLCcCkFgTaTwIxMNaphbRuIoPE5AKYsfTlscP8Ii5 FUYV3tUBuWirygcSD/jQyxQWAtv2lOe0zFNSmAWK59pDr3HlF4tOrzpiZCZNZzUO pQdmV8BySy9fY5l9VMOPHXoNpoFelHm8bA+Yh8WShyWYKQOcpCY5kh778bLOmU31 OPdi6Nb9/bovki2+UiKGuDwROKcBBVfLojHkTZCqt2/q4daHHxxbH2b84vo23Ig= =7zLv -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
