5 ms·
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 ment
by bauruine 5y ago
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.
- tptacek 5y agoSince 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).
- Hello71 5y agoI 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.
- jtl999 5y agoTo quote from the Slack engineering report > 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
- teddyh 5y agoI, 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.
- jtl999 5y agoI wasn't implying that wildcard records are something entirely incompatible with DNSSEC, more that certain nameserver implementations could potentially have trouble with them.
- teddyh 5y agoYour 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.
- jtl999 5y agoFair enough
- teddyh 5y agoAs I wrote a month ago (https://news.ycombinator.com/item?id=29378633#29385866 https://news.ycombinator.com/item?id=29378633#29385866): 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.)
- idlewords 5y agoI take issue with your characterization of Slack going offline as a downside.
- SamuelAdams 5y agoThere are some fairly good arguments against using DNSSEC. I think the author of this post is on HN. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/