I see a two-fold issue with DNSSEC: 1. The wide-spread tutorials seem to explain a key rollover as an exceptional activity, a *change* that is infrequently done. And changes, specifically the infrequent ones, bring along the possibility of failure, mostly due to human error.
I don't see reason why this is so. DNSSEC can be fully automated (mine is), and then it can be done frequently, and the human factor is out of the loop. It is then no longer a change, but a regular operation that happens every <week/month/quarter> without anybody even need noticing it. (Let'sEncrypt did the same for certificates, and that also works well.) 2. TCP seems still to be considered a second-class-citizen in the DNS world. (If I got the details right, TCP is only "optional", and must only be tried as a second choice after receiving TC.) So people may be induced to try and squeeze replies into whatever 512 or 1280 or 1500 bytes. Which means, they probably cannot use more than one key, and so take possible redundancy out of the game. I do not currently know about how or where this issue could be tackled appropriately; I for my part have decided to happily ignore it, and am using *four* KSK, thereby supporting RFC 5011 and RFC 7344, all with one simple script - and anyway now I have the longest; here you can see it in action: https://dnsviz.net/d/daemon.contact/dnssec/ Let's see where this leads into problems; for now it appears not to. -- PMc -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users