RE: slack.com
Friday is always a good day to do such change. :D -Original Message- From: NANOG On Behalf Of Mark Tinka Sent: October 2, 2021 2:17 AM To: Bill Woodcock Cc: nanog@nanog.org Subject: Re: slack.com On 10/2/21 08:14, Bill Woodcock wrote: > 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. Tend to agree with this approach. But I can see how an issue like this could be potentially religious. DNSSEC deployment rate is bad enough, as it is. Mark.
Re: slack.com
On 10/2/21 08:14, Bill Woodcock wrote: 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. Tend to agree with this approach. But I can see how an issue like this could be potentially religious. DNSSEC deployment rate is bad enough, as it is. Mark.
Re: slack.com
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. -Bill > On Oct 2, 2021, at 7:30 AM, Mark Tinka wrote: > > So, that wasn't fun, yesterday: > > > https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021340.html > > We were also hit, given we run DNSSEC on our resolvers. > > 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. > > Mark.
