一些 DNS 主机提供了一种方法来获取 A 记录，该记录服务于通过在后台解析其他主机名来即时确定（或通过计划作业频繁确定）的 IP 地址。当 example.com（而不是像 www.example.com 这样的子域）必须指向 IP 地址不时更改的主机时，可以使用这种方法，而无需每次更改时都进行人工干预。结果是解析 example.com 会产生一个 A 记录，其中该 A 记录的 IP 地址由名称服务器通过查找 another.example.com 的 IP 地址（本身可能是 CNAME）动态确定。
DNS Made Easy 和 easyDNS 将其称为“ANAME 记录”，Route 53 将其称为“别名资源记录”，CloudFlare 将其称为“CNAME Flattening”，DNSimple 将其称为“ALIAS 记录”。无论他们如何称呼它，解析主机名时都会返回标准 A 记录。
尽管这是一个相当明显的概念，但我还没有看到关于如何实现这一点的出版物。我打算在我的名称服务器（即 Windows Server 2012 R2 中的 DNS 管理器）中复制此行为。是否存在用于执行此操作的 DNS 管理器插件？
编辑：为了避免XY 问题我将提供完整的背景信息，从问题的症状开始，然后追溯依赖关系，因为它们表明了哪些解决方案已经尝试过，哪些解决方案尚未尝试过。
症状
与顶级域 (example.com) 的 SSL/TLS 连接会产生证书不匹配。此类连接尝试的次数并不多，但由于电子邮件客户端自动检测主机等原因，尝试次数越来越多。例如，我们只是将 Exchange 作为面向客户端的邮件服务器，在添加[电子邮件保护]作为 Android 或 Mac Mail 中的 Exchange 帐户，自动主机发现显然会派生出“典型”主机名，例如 example.com、mail.example.com、exchange.example.com 等，并向用户发出“大警告”，指出 example.com 证书上的 CN 不是 example.com。我们实际上使用具有匹配证书的 exchange.example.com，但自动检测必须首先尝试 example.com。
当 Web 浏览器指向https://example.com，但大多数人在地址栏中输入的是 example.com，而不是以 https:// 为前缀，因此他们最终升级为https://www.example.com必要时进行重定向。由于 www.example.com 有 CNAME，因此它能够指向没有 CN 不匹配的主机。
为什么只有 www.example.com 有匹配的证书，而在 example.com 上没有？
具有我们匹配证书的服务器（顺便说一下，可以轻松拥有 SAN 条目来匹配 example.com 和 *.example.com，这没有问题）位于 AWS ELB（弹性负载均衡器）上，Amazon 警告其 IP 地址可能随时更改。由于动态 IP 地址，ELB 只能通过其主机名引用，这意味着 CNAME/ANAME/Flattening/等。这就是为什么我们可以将 www.example.com 指向 ELB，但不能指向 example.com。Amazon 建议使用 Route 53 来克服任何限制。当这不可能时，唯一的解决方案是让 example.com 的 A 记录指向通常为 ELB 反向代理的上游服务器，而不是 ELB。
为什么不把匹配的证书放在上游服务器上？
只有 ELB 本身是专用于我的，因此只有 ELB 可以安装我的通配符证书。上游服务器在托管提供商的客户群之间共享。我可以让托管公司将 example.com 添加到其证书上的 SAN 清单中，这样就不会出现不匹配的情况，但出于各种原因，我更想充分利用 ELB。
约束
我们固定在 Win2012R2 上内部运行 DNS，而所有 WWW 主机都必须在 AWS 上以实现弹性。
答案1
考虑到问题的具体情况，我认为理想的解决方案是将顶点指向将 HTTP 请求重定向到 的 Web 服务器example.com。www.example.com反过来www.example.com，它可以是 AWS 管理的 DNS 记录的 CNAME。
- 虽然可能的在您的服务器上设置一个解决方案，自动更新顶点 A 记录以“追踪”AWS，这会带来大量不必要的复杂性，并会对您的内部基础设施产生额外的依赖，以使事情按预期进行。我会尽最大努力避免这种情况。
- 自己运行这个 Web 服务器显然会带来一系列挑战和依赖，因此将注意力转向外部也是很自然的。例子解决你的问题的商业服务（包括 https）将是閱讀網站。请注意，我不是链接到他们的免费、非 SSL 产品。
- 简单性和可用性之间的折衷方案是在云中设置一个由您自己运行的简单 Web 服务器来执行此重定向。您仍然需要运行 Web 服务器，但至少它不依赖于您公司的本地基础架构，并且您拥有可用性的 SLA。
归根结底，你必须问自己，你的 apex 记录始终正常运行有多重要。在你的情况下，它应该只是手动输入该记录的用户的保障。确保你的服务器和应用程序在配置时考虑到这一点，风险应该会大大降低。还应在你的设计文档中注明（如果适用），以确保事情保持这种状态。
答案2
安德鲁的答案绝对正确；一个以推动人们访问 WWW 为唯一目的的小型网络服务器很好地解决了网络浏览器方面的问题。
对于邮件自动发现，您是否调查过SRV记录？鉴于您运行的是 Windows，我大胆猜测您运行的是 Exchange。如果是这样，Outlook 将根据 SRV 自动配置，从而避免证书 CN 不匹配的情况。
继续讨论正交选项，使用更好的云可以让您完全放弃这种愚蠢的行为（因为他们知道如何处理任播固定 IP），而使用更高级别的 CDN 则内置了这种能力。[注：我在提供 HA 服务的云提供商工作。]
答案3
最好的解决方案是使用 Amazon Route 53 作为 DNS，然后为 cloudfront 地址添加别名 A 记录。它效果很好，我们每天都在使用它，而且您的 DNS 将比在本地网络上的盒子上运行它更具“弹性”。