Another point I would add is DNSSEC. With your own authoritative server you actually own the keys and don't have to trust another company.
What's also not mentioned is the possibility to run your own hidden master and use a DNS provider (or multiple!) as slaves. This way you have full control over your zone but you don't have to run your own network of nameservers.
Since almost nobody runs DNSSEC (try a list of popular domains, like the Moz 500, and `dig ds $domain +short`), this is unlikely to be a big issue for most people. There's also practically no upside to running DNSSEC, and a lot of downside (see: Slack disappearing from the Internet for a whole day).
The problem for Slack was not caused by DNSSEC directly. It was caused by:
1. A bug in Route 53 which caused wildcard record not to work with DNSSEC signing. Anyone not using Route 53 would not have had any problems with DNSSEC.
2. Slack decided to revert the DNSSEC rollout, but botched the process badly, effectively locking themselves in the trunk and throwing away the key. If they hadn’t tried to revert the DNSSEC rollout, or if they had been a bit more deliberate and careful while doing it, this would not have happened.
(Also, except for DNSSEC solving the obvious problem of not having any way to authenticate DNS responses, you also can’t use newer e-mail security standards like DANE without DNSSEC. MTA-STS is an obvious ugly hack, requiring a web server to run an e-mail server.)
I don't run DNSSEC either, but as you know, the Slack issue was caused by haphazard implementation, followed by apparent panicked incorrect rollback. They would have had basically the same issue if they had added incorrect AAAA records with long expiry. There may well be reasons not to deploy IPv6, but I don't think this is a good one. Similarly, while I agree that DNSSEC offers few upsides, I don't think this particular example is a good one against DNSSEC itself.
> This indicated there was likely a problem with the ‘*.slack.com’ wildcard record since we didn’t have a wildcard record in any of the other domains where we had rolled out DNSSEC on
I'm not going to stick my hand in either camp for the sake of this discussion,
but dynamic/wildcard DNS records are exactly the type of thing I'd suspect DNSSEC to have trouble with
I, on the other hand, can speak from experience, and I say that where I work we currently have over 100 domains with DNSSEC and a wildcard record, and they all work just fine.
I wasn't implying that wildcard records are something entirely incompatible with DNSSEC, more that certain nameserver implementations could potentially have trouble with them.
Your guess was proven correct, as it was indeed a bug in Route 53 which broke Slack. But you did not write “certain DNSSEC implementations”, you wrote “DNSSEC”, which I interpreted as implying that DNSSEC itself, inherently, had problems with wildcard records. But my experience told me otherwise, hence my comment.
What's also not mentioned is the possibility to run your own hidden master and use a DNS provider (or multiple!) as slaves. This way you have full control over your zone but you don't have to run your own network of nameservers.