DNSSEC adoption

[Peter]

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