-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21-07-11 14:15, Stephan Lagerholm wrote: > > I suggested to use another flag for the DNSKEY a few months ago here. The > reaction from the list was that it was too complicated because the key-id > would change during the lifetime of the DNSKEY.
Why would you look at the key-id ? If as a parent I get a notify, I (securely) look up the DNSKEY set, select the keys with a SEP bit and hash them to DS. What does the key-id do in that ? If the key-id changes during the DNSKEY lifetime, doesn't it mean the DS at the parent should change too ? Or do you mean there's a point in time you set the flag, and that causes the key-id to change ? Yes, sure. But then I see that as a key change, and you have to signal the parent anyway. >> I realise the SEP bit does not have this meaning right now, but I see >> no hindrance in changing that definition. > Doesn't work. There are scenarios when you want to have the DS record > published prior to publish the DNSKEY. For example, algorithm rollovers or > double DS rollover. A new record or a new flag to the DNSKEY is required. I wonder if this is a practice that needs to be reconsidered. I can imagine you don't sign with a new key yet, but can publishing it in the zone do harm ? Even if it's a bogus key ? And perhaps the many roll-over scenario's we have now can be brought back to just the ones that work in such an automated fashion. > I Agree that the draft is missing the whole signaling piece. But it is still > a step in the right direction to try to define how the RR should look like. > The definition of the signaling can actually be defined later. Agree, that is a next step. - -- 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) iQEcBAEBAgAGBQJOKB0SAAoJEDqHrM883AgnA5MH/AuqVYyIr/fkA6uamMG2iOJe eNGZe4kA15wX6YC5gODP9mA2B+VCvITh1kQ4UItthxWoWQpGiDaYMFYsbnmZTh20 P8A66mJ8sZ3qYFTB2ZwrEQp26vHCTfhh+LZHJjRRRdKbT3zhvR5y+0mEdWAavbF4 j/u218/qoNKJcdI/QRNOP3l1NFDMRgVymy3ui6f7d5p1rwjJT6jRad5b4CVr6uQl RGHBXCbM9l32e+SfSUH6QR4EwlwncKZdEHUsgt27BFzaO/962Q88+j864cak6vxQ HCre5nIecc8shN3gpaquADK3ny2ePfxhxOhyux+XlRL2lvdm/qMt0oiySYHjoik= =KJXm -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
