为什么在云中使用 DNS ALIAS 记录而不是 CNAME？

为什么在云中使用 DNS ALIAS 记录而不是 CNAME？

在云环境中，DNS记录的正确配置对于确保服务的稳定性和安全性至关重要。本文将探讨为什么在云中使用DNS ALIAS记录比CNAME记录更为优越，通过一个实际案例揭示CNAME记录可能带来的安全隐患，并展示ALIAS记录如何提供更安全、更便捷的解决方案。

为什么在云中使用 DNS ALIAS 记录而不是 CNAME？

在云资源之上建立自定义域至关重要。云提供商创建一个资源（如负载平衡器），并为您提供一个域，如 some-production-loadbalancer-123456.eu-west-1.elb.amazonaws.com。将此域名作为CNAME记录添加到app.yourcompany.com。

如果删除云上的资源会发生什么情况？

如果删除该资源，但在自定义域（app.yourcompany.com）上保留CNAME记录，就会遇到悬空CNAME问题。

什么是悬空 CNAME 问题？

让我们来看一个实际的例子：

我创建了一个域：blog.example.adililhan.com。我在AWS上创建了一个负载平衡器：adil-blog-test-1393565408.eu-west-1.elb.amazonaws.com。我将负载平衡器的域名作为CNAME添加到我的域名中：

只是为了测试，我会发送一个请求：

我收到了AWS资源（EC2实例）的回复。我将删除负载平衡器，看看会发生什么：

DNS结果：

自从负载平衡器域被删除后，AWS已不再返回该域的任何信息。我将创建一个新的负载平衡器，名称相同：adil-blog-test。这是新负载平衡器的域名：adil-blog-test-1109044799.eu-west-1.elb.amazonaws.com，它与前一个非常相似。只是数字不同。

这就是问题所在：随机数

AWS使用以下命名约定为其负载平衡器建立域：$YourLoadBalancerName-$RandomNumber.$RegionName.elb.amazonaws.com，攻击者可能会在你的DNS输出中识别出3个变量：

$YourLoadBalancerName -> adil-blog-test
$RandomNumber -> 1109044799
$RegionNumber -> eu-west-1

因此，攻击者不能只控制一个变量：$RandomNumber。我移除了负载平衡器，但在自定义域中保留了其域名。因此，如果攻击者删除/创建了足够数量的负载平衡器，那么最终也会获得同样数量的被删除负载平衡器。

解决方案：使用 DNS 别名记录

DNS有许多不同的记录类型：A、AAAA、CNAME、MX等。ALIAS记录类型不属于标准记录类型。只有AWS、CloudFlare和Azure等少数服务提供商支持DNS ALIAS记录类型。

ALIAS记录类型与CNAME类似。您可以在服务提供商配置中提供负载平衡器的域名。服务提供商将从负载平衡器的域名地址中检查返回的IP地址，并相应更新您域名的A记录。如果负载平衡器的IP地址发生变化，您的自定义域的A记录也会立即更新。

让我们将负载平衡器的域名添加为ALIAS记录：

检查DNS：

因此，攻击者无法确定负载平衡器的域名。出于测试目的，我将发送一个请求：

我删除了负载平衡器：

在检测到负载平衡器被删除后，AWS继续从我的自定义域中删除与负载平衡器相关的IP地址：

有了ALIAS记录，就无需监控域上的CNAME条目。这种技术也被称为DNS扁平化。

总结

• 自定义域名在云资源上的重要性：在云服务之上使用自定义域名能够提供更具品牌性和易于记忆的访问入口。
• CNAME记录在云资源删除后的悬垂问题：当云资源被删除时，如果不更新自定义域名上的CNAME记录，会导致DNS解析问题，影响服务的可用性。
• 安全风险：由于云服务提供商的资源域名包含随机数，攻击者可能通过猜测这些随机数来控制被删除资源的域名。
• ALIAS记录的优势：ALIAS记录能够自动解析到云服务资源的正确IP地址，即使资源的IP地址发生变化，也能保持自定义域名的正确解析。
• 提高安全性和减少监控负担：使用ALIAS记录可以避免悬垂CNAME带来的安全风险，并且由于DNS扁平化，减少了对DNS记录的频繁监控。