DNSSEC adoption
Timothe Litt
litt at acm.org
Wed Aug 3 13:48:16 UTC 2022
On 03-Aug-22 09:27, Bob Harold wrote:
> I think the best way to soften the effect, and make DNSSEC much less
> brittle, without losing any of the security, is to reduce the TTL of
> the DS record in the parent zone (usually TLD's) drastically - from 2
> days to like 30 minutes. That allows quick recovery from a failure.
> I realize that will cause an increase in DNS traffic, and I don't know
> how much of an increase, but the 24-48 hour TTL of the DS record is
> the real down-side of DNSSEC, and why it is taking me so long to try
> to develop a bullet-proof process before signing my zones.
>
> --
> Bob Harold
> University of Michigan
>
Yes, in planning for DNSSEC changes it's a good idea to include reducing
TTLs, verifying the change, then increasing the TTLs.
That means keeping track of important (I'd say non-automated) events,
and reducing TTL a few days in advance.
If you do that, you get the benefit of long TTLs most of the time. KSK
rollover - probably the most common cause of errors - is not a frequent
event.
Then again, with proper planning, you don't make nearly as many mistakes.
Also, while I haven't gotten around to migrating, for a new setup I'd
look at the dnssec-policy in 9.16+, which appears to do most of the
automation for you. All of it if you have a registrar who supports
CDS/CDNSKEY, in which the parent zone pulls the new DS into itself.
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Some issues have been reported on this mailing list, but from a distance
it seems to be a great improvement and doing well.
At this point, creating a new process doesn't seem like a great use of
time...at least unless you've identified issues with the tools that you
can't get fixed... The ISC folks working on dnssec-policy seem to have
been responsive.
FWIW
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/db760403/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/db760403/attachment.sig>
More information about the bind-users
mailing list