>Note that RFC 8901 is an IETF consensus document that was produced in the >DNS Operations working group. So, we can't just dismiss it and propose >protocol changes without considering effects on that (and other documents). >As I also noted earlier, its status will likely be upgraded when we revise >it.
Under the assumption that adding a constraint for unique key tags for the DNSSEC standard protocols is relatively easy (from a protocol point of view, getting changes deployed is always a lot harder), we can take a look at RFC 8901. As you say it likely needs a revision anyhow. So, for example Section 6.1 of RFC 8901. For a KSK rollover, the zone owner would generate a new KSK. The zone owner also signs the DNSKEY RRset. So this is essentially the same as what any other signer would have to do. No real changes are required except making sure to select a new KSK with a key tag that does not conflict with keys already in the DNSKEY RRset. Then for a ZSK rollover. Each provider has independent signing keys, so a provider would have to select a new signing key that does not conflict with current keys in the DNSKEY RRset. Again, this is what any signer would do in the new model. Then the provider would submit the new key to the zone owner for inclusion in the DNSKEY RRset. At this point, if two providers would want to update their keys at the same time and happen to have new keys with conflicting key tags, we would have a problem. However, this can only happen if two ZSK rollovers would happen at the same time. Which is something that can be consideren bad operational practice and is certainly not suggested as something to do in Section 6.1. Furthermore, Section 6.1 is explicit about the coordination between providers and the zone owner when it comes to a ZSK rollover. So it is easy for a zone owner to prevent two ZSK rollovers at the same time. I have to admit, model 2 would be a bit more complex. But not fundamentally impossible. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
