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

Mailman List Mirror (Read Only)
1

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 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.

2

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

3

how would they be able to serve:
footgun.slack.com
bjornbjorn.slack.com
ilovecorn.slack.com

so immediately without that wildcard though?
:slight_smile:

4

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

5

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