Antoin Verschuren wrote: > 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. Agree, this draft is not covering such scenario. And .NL is not alone doing this. For example, .GOV is also asking for DNSKEYs instead of DS.
> 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 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. > 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. > 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 ? 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. /Stephan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
