Comment by tptacek
8 hours ago
Which is exactly what happened to Slack, and took them offline for most of a business day for a huge fraction of their customers. This is such a big problem that there's actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that addresses it: tactically disabling DNSSEC at major resolvers for the inevitable cases where something breaks.
As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
The difference is DNS provides a fairly obvious up side
Actually, does it? Yes, the obvious upside when I type in slack.com instead of 123.45.56.67 is very good. Does this same upside apply to addresses I don't type in? What's actually the advantage of addressing one of foobarcorp's infinitude of servers uasing the string "123-45-57-78.slp05.mus.foobar.com" instead of "123.45.57.78"? It seems to just waste bytes. And most communication is of the latter sort - an app talking to its own servers managed by the same company.
> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
The benefits are huge: there are lots of attacks that DNSSEC trivially prevents and it would help secure more than just web browsers.
11 replies →