<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 02-Aug-22 13:51, Brown, William
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BL3PR19MB651655875CD0A737E6C60C74899D9@BL3PR19MB6516.namprd19.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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 class="moz-quote-pre" wrap="">No one wants to be this guy:
<a class="moz-txt-link-freetext" href="http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201">http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201</a>
18_FINAL.pdf
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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 class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">randy
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 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.<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 class="moz-signature" 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 class="moz-quote-pre" wrap="">
</pre>
</body>
</html>