> On 28 Feb 2024, at 05:50, Peter Thomassen <pe...@desec.io> wrote:
>
>
>
> On 2/15/24 22:53, Mark Andrews wrote:
>> But we can state that they should be avoided when generating new DNSKEYs.
>> BIND has been avoiding key tag collisions for 2 decades now when generating
>> new keys. Multi-signers all have to have the current published DNSKEY RRset
>> which includes *all* DNSKEYs as part of their publication process.
> Multi-signer peers do not need to publish each other's KSKs. A DNSKEY
> response only needs to contain the KSK suitable for validating the response
> RRset itself (i.e., the responding peer's KSK), and any ZSKs/CSKs that may be
> needed for validation of other responses.
>
> Multi-signers thus aren't necessarily aware of keytag collisions across KSKs.
Which is why I also suggested an automated keytag broker based on DNS UPDATE.
If you are doing completely offline keys you just need to write done the tag
and run the check manually using existing tooling like nsupdate. That handles
generation of keys months in advance of publication/use in the DNS.
> When using DS provisioning automation via CDS/CDNKSEY, they'll have to
> exchange each other's KSKs for publishing a joint C* RRset (as in
> draft-thomassen-dnsop-mske). The collision could be detected then, but using
> C* automation is not required.
>
> Best,
> Peter
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
