DNSSEC adoption

[Bob Harold]

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


On Tue, Aug 2, 2022 at 2:21 PM Timothe Litt <litt at acm.org> wrote:

>
> On 02-Aug-22 13:51, Brown, William wrote:
>
> my guess is that they see dnssec as fragile, have not seen _costly_
> dns subversion, and measure a dns outages in thousands of dollars a
> minute.
>
> No one wants to be this guy:http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201
> 18_FINAL.pdf
>
> so, to me, a crucial question is whether dnssec ccould be made to fail more softly and/or with a smaller blast radius?
>
> randy
>
> I'm more of a mail guy than DNS, so yes, like hard v. soft fail in SPF.  Or perhaps some way of the client side deciding how to handle hard v./ soft failure.
>
> As Mark has pointed out, validation is a client issue.  Setting up DNSSEC
> properly and keeping it running is for the server admin - which bind is
> incrementally automating.
>
> For bind, the work-around for bad servers (which is mentioned in the
> article) is to setup negative trust anchors in the client for zones that
> fail.  And notify the zone administrator to fix the problem.  I usually
> point them to a DNSVIZ report on their zone.
>
> The nasa.gov failure was avoidable.  nasawatch, which is an excellent
> resource for space news, jumped to an incorrect conclusion about the outage
> - and never got the story straight.  In fact, all validating resolvers
> (including mine) correctly rejected the signatures.  It wasn't comcast's
> fault - they were a victim.
>
> It is an unfortunate reality that admins will make mistakes.  And that
> there is no way to get all resolvers to fix them - you can't even find all
> the resolvers.  (Consider systemd-resolved, or simply finding all the
> recursive bind, powerdns, etc instances...)
>
> There is no global "soft" option - aside from unsigning the zone and
> waiting for the TTLs to expire.  And besides being a really bad idea, it's
> easier to fix the immediate problem and learn not to repeat it.
>
> Long term, automation of the (re-)signing and key roll-overs will reduce
> the likelihood of these outages.  It is truly unfortunate that it's so late
> in coming.
>
> It may take a flag day to get major resolver operators, dns servers, and
> client resolvers all on the same page.  I'm not holding my breath.
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
>
> --
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/0eadc524/attachment.htm>