DNSSEC adoption

[Timothe Litt]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220802/a0507026/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/20220802/a0507026/attachment.sig>