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

Re: Amazon peering revisited

Hi all, We (Amazon) have made improvements over the last few years to significantly improve our NOC and Peering response times, as well as the time it takes to set up a peering session, whether over IX or direct PNI/SFI. If you don't get a response from the respective Peering mailing address

Re: Amazon peering revisited

There are also three different ASNs and different policy decision trees; they all report selective criteria such as minimum of 10GE, multiple locations, specific locations, etc. Not sure it's as simple as 'getting the right person' more than it is about meeting the right conditions. Easier for

Re: Amazon peering revisited

"For a company like Amazon..." True, but also, they're at a size where staffing and operating peering operations generously has a negligible impact on the fiscal situation of the company (or even department). - Mike Hammett Intelligent Computing Solutions Midwest Internet

RE: Amazon peering revisited

Have gotten into the habit of making annual peering requests to Amazon asking turn up a session on a shared IXP peering. Once was able to get a peering session turned up, no traffic was ever shifted onto it before we moved out of that carrier hotel a year or so later. The amazon peering email

Weekly Global IPv4 Routing Table Report

This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to

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

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

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

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

Slack.com DNSSEC on Feb 12th 15:00 UTC

Hello everyone, I'm reaching out from the traffic team over at Slack . As many of you might be aware, we had a series of unfortunate attempts to enable DNSSEC on slack.com last year. We are planning to