On 2022-11-25 12:26 -05, Daniel Migault <mglt.i...@gmail.com> wrote: > On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát <vladimir.cunat+i...@nic.cz> > wrote: >> I am surprised you would not recommend RFC 5011 >> >> 5011 needs persistent state, a thing that resolvers/validators often don't >> need at all otherwise (cache is safe to delete). 5011 doesn't always work, >> so you need to combine with some fallback mechanism(s) anyway - for new >> installations and for stale ones (missed rotation). Root rollover has >> happened only once in history, non-root TAs aren't that common, and 5011 >> algorithm isn't very simple, so the code can easily get some bugs without >> anyone noticing until it's too late. >> >> Lots of down-sides, so I rather put the TAs into SW updates, for the root >> TA case at least. I'd recommend trying to avoid non-root TAs, but if I had >> to choose, I'd put them into configuration. Again a thing that I have to >> provision *anyway*, so I get the occasional TA updates basically for free, >> without needing to worry about those 5011 disadvantages. (occasional = >> 5011 defaults to requiring 30 days of overlap) >> >> > Oh! sure for the TA. My understanding of the text is that it recommends > 5011 for running instances, but that new instances are configured with > up-to-date TA that in most cases are updated by software update. So yes I > agree and will check this appears clearly.
Another issue with 5011 is that it needs cooperation from the entity signing the zone during a KSK rollover. 7583 spells this out in section 2.2. I think Vladimír is hinting at this already, I'd say it should be spelled out. Especially since this is aimed at non-DNSSEC-Experts as you were saying earlier in the thread. If a DRO unilaterally decides to put in a TA for example.com as suggested in section 7.1.1 and using 5011 this will not end well if they don't tell the people operating the signer. They will probably not follow the correct timing during a KSK roll. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
