DNSSEC adoption
Peter
pmc at citylink.dinoex.sub.org
Wed Aug 3 15:56:41 UTC 2022
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
More information about the bind-users
mailing list