Re: Slack.com DNSSEC on Feb 12th 15: 00 UTC
It appears that Peter Beckman said: >Agreed! Slack should probably move away from the custom domain model, and >go with slack.com/w/bjornbjorn moving forward. Their problem was poorly debugged software. I don't see any reason that web software is necessarily any better debugged than DNS software. I use DNSSEC signed wildcards and it works fine, although it has blown up the occasional buggy web spider which is not my problem. Check out https://www.web.sp.am. R's, John > >On Fri, 4 Feb 2022, Christopher Morrow wrote: > >> On Fri, Feb 4, 2022 at 10:54 AM Bj�rn Mork wrote: >> >>> >>> I assume you know which names you are going to serve? >>> >>> >> how would they be able to serve: >> footgun.slack.com >> bjornbjorn.slack.com >> ilovecorn.slack.com >> >> so immediately without that wildcard though? -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Re: Slack.com DNSSEC on Feb 12th 15:00 UTC
On Fri, Feb 4, 2022 at 11:18 AM William Herrin wrote: > On Fri, Feb 4, 2022 at 7:55 AM Bjørn Mork wrote: > > So why the heck do you insist on keeping that wildcard? Nobody else use > > wildcard A records. There is no reason. It's a loaded footgun. > > Okay... I know some of the bad things that can happen with CNAMEs. > What exactly is the problem with wildcard A records and DNSSEC? > There is no problem with wildcards and DNSSEC. It was a subtle bug in a particular DNS server implementation (Route53), where wildcard NODATA responses were being returned with an incorrect type bitmap in the NSEC record. This caused some DNS resolver implementations that do aggressive negative caching (with RR type inference) to fail to lookup some subsequent record types. (That bug is now fixed). Shumon Huque
Re: Slack.com DNSSEC on Feb 12th 15:00 UTC
Agreed! Slack should probably move away from the custom domain model, and go with slack.com/w/bjornbjorn moving forward. On Fri, 4 Feb 2022, Christopher Morrow wrote: On Fri, Feb 4, 2022 at 10:54 AM Bjørn Mork wrote: I assume you know which names you are going to serve? how would they be able to serve: footgun.slack.com bjornbjorn.slack.com ilovecorn.slack.com so immediately without that wildcard though? :) --- Peter Beckman Internet Guy beck...@angryox.comhttps://www.angryox.com/ ---
Re: Slack.com DNSSEC on Feb 12th 15:00 UTC
On Fri, Feb 4, 2022 at 7:55 AM Bjørn Mork wrote: > So why the heck do you insist on keeping that wildcard? Nobody else use > wildcard A records. There is no reason. It's a loaded footgun. Okay... I know some of the bad things that can happen with CNAMEs. What exactly is the problem with wildcard A records and DNSSEC? Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Slack.com DNSSEC on Feb 12th 15:00 UTC
On Fri, Feb 4, 2022 at 10:54 AM Bjørn Mork wrote: > > I assume you know which names you are going to serve? > > how would they be able to serve: footgun.slack.com bjornbjorn.slack.com ilovecorn.slack.com so immediately without that wildcard though? :)
Re: Slack.com DNSSEC on Feb 12th 15:00 UTC
RFC1912 says Wildcard As and CNAMEs are possible too, and are really confusing to users, and a potential nightmare if used without thinking first. You know the nightmare is real. You've been there. So why the heck do you insist on keeping that wildcard? Nobody else use wildcard A records. There is no reason. It's a loaded footgun. I assume you know which names you are going to serve? Bjørn
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.
