DNSSEC adoption

[Timothe Litt]

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>