【问题标题】:Dynamic Route53 sub-domain forwarding动态Route53子域转发
【发布时间】:2016-01-14 03:07:37
【问题描述】:

我正在尝试将 Route53 域重定向到另一个 Route53 域,同时维护子域。

我有一个用于 example.com 的 Route 53 托管区域,其中包含我的主要网站。

我有另一个 Route 53 托管区域,例如 example.co.uk,我使用 S3 静态网站重定向规则将其重定向到 example.com(如 https://stackoverflow.com/a/14289082/918030 中所述)

这对根域非常有用,但我想像以下示例那样映射子域:

sub1.example.co.uk   -->    sub1.example.com

sub2.example.co.uk   -->    sub2.example.com

...

sub999.example.co.uk -->    sub999.example.com

我知道这可以通过为每个子域创建一个新的 S3 存储桶并配置适当的 S3 静态网站重定向规则来完成,但我想知道是否有办法动态地做到这一点,所以 *.example.co.uk转发到 *.example.com。 最好不必运行单独的 EC2 实例(运行 nginx)

谢谢!

风格

【问题讨论】:

    标签: amazon-web-services amazon-s3 dns amazon-route53 forwarding


    【解决方案1】:

    除了为您要重定向的每个子域创建一个唯一的存储桶之外,没有一种简单的方法可以使用现成的 AWS 服务(当然不包括 EC2)的任何组合来做到这一点。每个账户 100 个存储桶的限制现在是软限制而不是硬限制,因此您现在可以(通过提供合理的用例)请求 AWS 支持增加您的存储桶限制。

    当然,这并不能解决必须配置它们的问题,尽管 Route 53 中的单个通配符 CNAME 将允许您使用根区域网站端点作为目标,然后集体路由到 S3,至少S3 目前的工作方式,这意味着依赖于一些似乎不太可能改变但可能会改变的未记录的 S3 行为。

    对与已创建的存储桶不匹配的主机名的请求仍会转到 S3 并返回“NoSuchBucket”错误,这本身就是一个问题……事实上,在您追求通配符时,它值得深思。

    在前两段,我提到了利用指向 S3 的通配符 CNAME 来利用一些未记录的行为。想象一下被那些阅读过文档但还没有尝试过 S3 实际行为的潜在评论者点名,我在我的 Route 53 托管区域之一中设置了一个通配符 CNAME,将 *.mysterystring.example.com 指向 s3-website-us-west-2.amazonaws.com。这不是文档说您应该这样做的方式,但可以肯定的是,这完全符合我的预期......无论您放置*,如果您有一个以我们的完整域名命名的存储桶 - west-2,S3 应要求提供服务。如果不是,则为“NoSuchBucket”错误,包含 S3 尝试查找但找不到的存储桶名称。那么,为什么我没有提到实际的测试设置域来证明我的观点呢?嗯... 任何人 嗅探都可以使用与该通配符匹配的未使用主机名之一创建一个存储桶,并在我的域中有一个网站,托管在 S3 中,使用该设置,我没有配置,也没有我的知识。 (!?)当然,他们会为存储桶付费,但是,嘿,免费域名抢注!接下来你知道的,他们在冒充我,抢客户,谁知道呢?

    所以,危险信号:请注意通配符重定向未配置资源的影响。

    另一方面,如果您想重定向所有内容(并且您采取措施确保目的地确实是一个死胡同,不能为未使用的主机名秘密声明),EC2 实例不会是不好的交易。 t2.micro 每天可以轻松地服务数十万个轻量级请求,例如重定向(我有一个每天处理超过 300k 并且总是有空闲 CPU 积分的请求),价格低于 10 美元/月。

    【讨论】:

      猜你喜欢
      • 2020-01-06
      • 1970-01-01
      • 2017-07-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-12-06
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多