Hello everyone, I'm reaching out from the traffic team over at Slack <https://slack.com/>. As many of you might be aware, we had a series of unfortunate attempts to enable DNSSEC on slack.com <https://slack.engineering/what-happened-during-slacks-dnssec-rollout/> last year. We are planning to publish the slack.com DS record at the '.com' zone on Feb 12th at 7AM PST (15:00 UTC). Our authoritative zone and delegated zones are already signed and have their link of the chain of trust all set. If you see any issues with slack.com in your networks after or on Feb 12th we'd be very grateful if you can contact us. Thank you! Rafael Elvira, Slack.
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
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 <bjorn@mork.no> 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 beckman@angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
It appears that Peter Beckman <beckman@angryox.com> 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 <bjorn@mork.no> 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, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
How many active ISPs are most of the people on this list dealing with? 1-2 - I'm an end user just trying to load balance 3-5 - I'm aggressively looking for the best paths for my "customer" traffic 6-20 - I have a meet-me POP room or a specific business need for so many connections 21+ - I'm an ISP Thank you!
------- Original Message ------- On Monday, February 7th, 2022 at 12:18, Josh Saul <josh@netris.ai> wrote:
How many active ISPs are most of the people on this list dealing with?
1-2 - I'm an end user just trying to load balance3-5 - I'm aggressively looking for the best paths for my "customer" traffic6-20 - I have a meet-me POP room or a specific business need for so many connections21+ - I'm an ISP
Not sure I understand the point you're getting at here ? Surely for any ISP it will be a mixture of the above ? And if any ISP complains about such diversity of customers, surely they are in the wrong business ? If you can't stand the heat, get out of the kitchen (as the old saying goes) ....
I think you need a bit more definition. ISPs as in full-route providers? Any external BGP peer? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Josh Saul" <josh@netris.ai> To: nanog@nanog.org Sent: Friday, February 4, 2022 8:02:12 PM Subject: Simplified BGP peering solution How many active ISPs are most of the people on this list dealing with? 1-2 - I'm an end user just trying to load balance 3-5 - I'm aggressively looking for the best paths for my "customer" traffic 6-20 - I have a meet-me POP room or a specific business need for so many connections 21+ - I'm an ISP Thank you!
On Fri, 4 Feb 2022, Josh Saul wrote:
How many active ISPs are most of the people on this list dealing with?
1-2 - I'm an end user just trying to load balance 3-5 - I'm aggressively looking for the best paths for my "customer" traffic 6-20 - I have a meet-me POP room or a specific business need for so many connections 21+ - I'm an ISP
You should probably rephrase the question in a way that makes more sense to the audience. I suspect you'll find most participants on this list are ISPs (depending on your definition of ISP). Many (most) of us also peer with lots of other networks that may or may not be ISPs in a non-ISP relationship. What's this "simplified BGP peering solution" you're [not] talking about? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
4 upstream ISP connections (2 commercial, 1 NREN, 1 partial feed from HE) 1 local IX (MBIX), so 5 more ASNs there (including HE, above) plus all the open-peering ASes accessible through the IX route servers 3 downstream customers with their own ASNs The two commercial ISPs are because end-user internet access here is the usual telco/cableco near-total-duopoly, and those two %$#@!!s only peer ~30ms away from me. (Interestingly, I have one ILEC but two cablecos, geographically separated, within my service area.) The NREN should be self-evident… that’s usually over 1/3 of my bandwidth, in fact, thanks to CANARIE’s CDN network. MBIX is to cover all the non-duopoly ISPs in the province. (Guess who doesn’t show up at the IX… first infinity guesses don’t count.) So… I actually am an end-user trying to load balance. But I’m also looking for the best paths. And I have three POPs now where I meet other carriers delivering L2 circuits. Finally, I’m an ISP but not for the general public. I don’t think you can categorize the customer type effectively based on either the peering counts OR the number of “ISPs” they deal with. (Not to mention, you need to define “ISP” in order for this question to make sense in the first place.) Adam Thompson Consultant, Infrastructure Services [MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Josh Saul Sent: Friday, February 4, 2022 8:02 PM To: nanog@nanog.org Subject: Simplified BGP peering solution How many active ISPs are most of the people on this list dealing with? 1-2 - I'm an end user just trying to load balance 3-5 - I'm aggressively looking for the best paths for my "customer" traffic 6-20 - I have a meet-me POP room or a specific business need for so many connections 21+ - I'm an ISP Thank you!
On Fri, Feb 4, 2022 at 7:55 AM Bjørn Mork <bjorn@mork.no> 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 bill@herrin.us https://bill.herrin.us/
On Fri, Feb 4, 2022 at 11:18 AM William Herrin <bill@herrin.us> wrote:
On Fri, Feb 4, 2022 at 7:55 AM Bjørn Mork <bjorn@mork.no> 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
participants (12)
-
Adam Thompson -
Bjørn Mork -
Christopher Morrow -
John Levine -
Jon Lewis -
Josh Saul -
Laura Smith -
Mike Hammett -
Peter Beckman -
Rafael Elvira -
Shumon Huque -
William Herrin