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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why ALIAS-type DNS Records Break The Internet

38 点作者 alexbilbie超过 11 年前

11 条评论

colmmacc超过 11 年前
Amazon Route 53&#x27;s ALIAS implementation takes a different approach. We only allow ALIASes to data that we know about authoritatively; so with Route 53 you can ALIAS to an S3 website Bucket (which also lets you do HTTP redirects), a CloudFront distribution (which can serve as a bridge to any arbitrary domain you may care), an ELB or to other records in your zone (which lets you combine routing policies in a compositional way).<p>The main benefits are;<p><pre><code> No dependency on a third party DNS service, we stand behind our 100% SLA DNS-based routing policies still work correctly No delay in responding to health check failures </code></pre> but there&#x27;s another (future, for us) ancillary benefit too;<p><pre><code> Compatibility with offline-signed DNSSEC </code></pre> The big downside of course is that the record has to be in our system in order to ALIAS to it. For HTTP services, using CloudFront is a pretty good workaround, it can handle dynamic and static sites. If you merely want to redirect from your apex to your www. domain, then S3 with a redirect works great too.<p>We&#x27;re also open to enabling ALIASing to other zones hosted in Route 53 on a case by case basis. If you have a multi-tenant service and you&#x27;re managing (or willing to manage) a zone on Route 53 with something like [customer-or-resource-identifier].yourservicename.com we can enable ALIASing to those names. If you&#x27;re interested, get in touch via the limit increase process; <a href="http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html" rel="nofollow">http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;general&#x2F;latest&#x2F;gr&#x2F;aws_service_lim...</a> .<p>Obvious question: Why don&#x27;t we enable ALIASing across zones by default? Firstly, zones which can be aliased to have to be replicated and available in all shards of our partitioned datastore (some day we may use some kind of cross-shard query protocol to resolve that, but even then we&#x27;d prefer to minimize the traffic) and secondly we want to ensure some stability for ALIAS targets and avoid situations where targets may be discontinued or deleted by their owners leaving our mutual customers stranded.
评论 #7025104 未加载
评论 #7025290 未加载
shawabawa3超过 11 年前
I don&#x27;t see how the caching thing is a problem specific to alias records. If you were using an A record instead, you would have to manually update the IP address, and then it would still be cached for however long.<p>The geoIP thing is pretty minor, ideally you should be able to tell the dns server the IP you are proxying for.<p>Who cares that there&#x27;s no standard? Complete non-issue.<p>Even if I agreed that alias records were bad, whats the alternative? Manually updating A-records?
评论 #7022899 未加载
评论 #7022930 未加载
donavanm超过 11 年前
Im missing quite a lot in this article. Personally i have my reservations about ALIAS. Recursion backed implementations in particular are full of Dragons and sharp corner cases. It&#x27;s a shame that its missing any substantial critisicm or examples of poor implementations of ALIAS records.<p><pre><code> An authoritative nameserver ... can deliver records in a predictable speed</code></pre> Thats a nice to have. And totally unrelated to the AA bit. Query latency is usually implemented via caching then querying multiple&#x2F;fastest available authoritative NS.<p><pre><code> An ALIAS record resolves on request the IP address of the</code></pre> destination record and serves it as if it would be the IP address for the apex domain requested First, backing with dns resolution is just one implementation of the idea. Secondly <i>it is the ip address of the domain requested</i>. An authoritative ns setting AA makes it so. There&#x27;s nothing that specifies what the backing data store or resolution method is for AA answers. Implementation detail.<p><pre><code> you will send traffic for your mapped apex domain to the wrong address until the record expires in all caching</code></pre> resolvers. Now weve discovered, but not actually mentioned, TTLs. How is this any different than the ttl &amp; expiry on a traditional CNAME + A record chain thats proposed at the end?<p><pre><code> you request the IP address from the nameserver of your DNS provider, not from your actual location.</code></pre> Assuming implementation is backed by dns recursion, sure. Good thing theres a standard like EDNS client-subnet that provides a method to propagate and vary based on the network of the original requester. But point taken, DNS is a complicated protocol and you should probably understand it before developin new features and implementations.
评论 #7023412 未加载
mslot超过 11 年前
In general, implementing ALIAS records through recursive resolution is a bad idea.<p>Geo routing and other resolver IP-based policies will probably break, since the authoritative name server has no way of knowing the resolver IP. Edns-client-subnet does not suffice in this case, since the authoritative name server may still base part of its decision on the resolver IP.<p>A much bigger problem is that the forwarding name server can be used for DDoS amplification attacks and that its own resources can easily be exhausted by an attacker if the authoritative name server is slow to respond. If the forwarding name server opens a new socket for every query it makes, the set of available port numbers can easily be exhausted. If the forwarding name server reuses port numbers, then spoofing attacks become straight-forward.<p>This does not mean ALIAS records are a bad idea in general. The Amazon Route 53 implementation resolves aliases internally. It is therefore limited it to AWS services, but you could, for example, point an ALIAS to CloudFront and point CloudFront to your website. CloudFlare offers a similar service.
rhengles超过 11 年前
Only I found it funny that the article is on a site without a subdomain?
评论 #7023209 未加载
kalleboo超过 11 年前
Can someone explain the rational in the standard disallowing CNAMEs on apex domains?<p>Before I learned about this restriction I actually had my site configured like that (my DNS provider had poor validation...) and it seemed like it worked for at least 2&#x2F;3 users (who apparently had lenient DNS servers)
评论 #7025052 未加载
dmourati超过 11 年前
First had to read the initial link in OP. From there, understand that this so-called ALIAS record is specific to one (or more?) DNS provider called dnsimple.com.<p>Broken? Maybe. I&#x27;ve never used one. The problem with the apex record not being able to be a CNAME is easily avoidable. I&#x27;d prefer to stay RFC compliant rather than use some one-off.
zx2c4超过 11 年前
What&#x27;s the consensus here? <a href="http://zx2c4.com" rel="nofollow">http:&#x2F;&#x2F;zx2c4.com</a> or <a href="http://www.zx2c4.com" rel="nofollow">http:&#x2F;&#x2F;www.zx2c4.com</a> ? For a while I did the latter, then I switched to the former, and now I can&#x27;t make up my mind and am tempted to go back to the latter.<p>Opinions? Thoughts?
评论 #7024582 未加载
snake_plissken超过 11 年前
Why don&#x27;t admins just set a smaller TTL for anything that is aliased?
acconrad超过 11 年前
This seems kind of funny given that Github&#x27;s most recent advice was to use ALIAS DNS records for apex domain types.
MatthewWilkes超过 11 年前
Can anyone explain the difference between an ALIAS and a DNAME record?
评论 #7025126 未加载
评论 #7027420 未加载
评论 #7025206 未加载