<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">We did not use an NTA, but we did flush our cache immediately once Slack had fixed their problem. I think that’s the right balance of carrot and stick. <br><div dir="ltr"> <div> -Bill</div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On Oct 2, 2021, at 7:30 AM, Mark Tinka <mark@tinka.africa> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<font face="Tahoma">So, that wasn't fun, yesterday:<br>
<br>
<a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021340.html">https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021340.html</a><br>
<br>
We were also hit, given we run DNSSEC on our resolvers.<br>
<br>
Interesting some large open resolver operators use Negative TA's
for this sort of thing. Not sure how this helps with the DNSSEC
objective, but given the kind of pain mistakes like these can
cause, I can see why they may lean on NTA's.<br>
<br>
Mark.<br>
</font>
</div></blockquote></body></html>