TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The case of the recursive resolvers: What happened during Slack’s DNSSEC rollout

132 点作者 usrme超过 3 年前

7 条评论

daper超过 3 年前
From the described mistakes two come from lack of understanding how exactly DNS works. But I agree it&#x27;s in fact hard, see [1]).<p>1. &quot;This strict DNS spec enforcement will reject a CNAME record at the apex of a zone (as per RFC-2181), including the APEX of a sub-delegated subdomain. This was the reason that customers using VPN providers were disproportionately&quot; - This is non intuitive and maay people are surprised by that. You cannot create any subdomain (even www.domain.tld) if you created &quot;domain.tld CNAME something...&quot;. Looks like not every server&#x2F;resolver enforces that restriction.<p>2. &quot;based on expert advice, our understanding at the time was that DS records at the .com zone were never cached, so pulling it from the registrar would cause resolvers to immediately stop performing DNSSEC validation.&quot; - like any other record, they can be cached. DNS has also negative caching (caching of &quot;not found responses&quot;. Moreover there are resolvers that allow configuring minimum TTL that can be higher that what your NS servers returns (like unbound - &quot;cache-min-ttl&quot; option) or can be configured to serve stale responses in case of resolution failures after the cached data expires [2]. That means returning TTL of &quot;1s&quot; will not work as you expect.<p>[1] <a href="https:&#x2F;&#x2F;blog.powerdns.com&#x2F;2020&#x2F;11&#x2F;27&#x2F;goodbye-dns-goodbye-powerdns&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.powerdns.com&#x2F;2020&#x2F;11&#x2F;27&#x2F;goodbye-dns-goodbye-pow...</a> [2] <a href="https:&#x2F;&#x2F;www.isc.org&#x2F;blogs&#x2F;2020-serve-stale&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.isc.org&#x2F;blogs&#x2F;2020-serve-stale&#x2F;</a>
评论 #29386165 未加载
teddyh超过 3 年前
From what I can tell, the problem was not caused by DNSSEC directly. It was caused by:<p>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.<p>2. Slack decided to revert the DNSSEC rollout, but botched the process <i>badly</i>, 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.
评论 #29390215 未加载
tptacek超过 3 年前
Additional discussion, indirectly and spurred from this, is here:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29381778" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29381778</a><p>That thread, which is big, is probably the right place to take general discussion of DNSSEC itself, though I&#x27;ll snipe DNSSEC here too. :)
jeffbee超过 3 年前
Seems like an organizational failure, as they got conned by their 3PAO into believing that DNSSEC was a requirement for FedRAMP moderate when it&#x27;s not. The disproof of this belief is that Google has FedRAMP High (for Google Cloud and Workspace) but does not use DNSSEC for google.com.
评论 #29386155 未加载
评论 #29385569 未加载
dogecoinbase超过 3 年前
In addition to the other note that DNSSEC is _not_ required for FedRAMP certification (it&#x27;s even discouraged by cloud.gov! <a href="https:&#x2F;&#x2F;cloud.gov&#x2F;docs&#x2F;compliance&#x2F;domain-standards&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloud.gov&#x2F;docs&#x2F;compliance&#x2F;domain-standards&#x2F;</a> ), this is some weirdly intellectually dishonest phrasing (linking to tptacek&#x27;s article Against DNSSEC: <a href="https:&#x2F;&#x2F;sockpuppet.org&#x2F;blog&#x2F;2015&#x2F;01&#x2F;15&#x2F;against-dnssec&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sockpuppet.org&#x2F;blog&#x2F;2015&#x2F;01&#x2F;15&#x2F;against-dnssec&#x2F;</a> ):<p>&gt; While we are aware of the debate around the utility of DNSSEC among the DNS community, we are still committed to securing Slack for our customers.<p>The argument is specifically that it doesn&#x27;t provide that security. At least it&#x27;s neat to see actual begging the question in the wild, I guess.
评论 #29386081 未加载
评论 #29385598 未加载
Joe8Bit超过 3 年前
I know we’ve all collectively accepted that DNSSEC is a terrible, complicated blight on the world but I still find it incredible that that an organisation with Slacks resources and access to expertise can’t make it work.
评论 #29385620 未加载
评论 #29385610 未加载
评论 #29385976 未加载
评论 #29386420 未加载
dsXLII超过 3 年前
It&#x27;s always DNS.
评论 #29385790 未加载
评论 #29387657 未加载