<div dir="ltr"><div dir="ltr">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.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br>-- <br>Bob Harold</div><div>University of Michigan</div></div></div></div></div></div><br><input name="virtru-metadata" type="hidden" value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"72","compose-window":{"secure":false}}"></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Tue, Aug 2, 2022 at 2:21 PM Timothe Litt <<a href="mailto:litt@acm.org">litt@acm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<div>On 02-Aug-22 13:51, Brown, William
wrote:<br>
</div>
<blockquote type="cite">
<pre></pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>No one wants to be this guy:
<a href="http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201" target="_blank">http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201</a>
18_FINAL.pdf
</pre>
</blockquote>
</blockquote>
<pre></pre>
<blockquote type="cite">
<pre>so, to me, a crucial question is whether dnssec ccould be made to fail more softly and/or with a smaller blast radius?
</pre>
</blockquote>
<pre></pre>
<blockquote type="cite">
<pre>randy
</pre>
</blockquote>
<pre>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.</pre>
</blockquote>
<p>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.<br>
</p>
<p>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.</p>
<p>The <a href="http://nasa.gov" target="_blank">nasa.gov</a> 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.<br>
</p>
<p>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...)</p>
<p>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.</p>
<p>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. <br>
</p>
<p>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.<br>
</p>
<pre cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<br>
<pre></pre>
</div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div>