通配符CNAME记录并发症？

所以我们使用Route53，我想设置一个通配符CNAME记录，将任何不匹配的子域重定向到我们的主域。我试了一下，一切看起来都运行正常，但当我告诉同事时，他非常反对通配符CNAME记录，说明存在问题/安全问题，但不会详细说明。除了与特定DNS服务器实现隔离的问题之外，网络搜索并未真正找到对此问题的任何解释。

话虽如此，通配符CNAME记录存在安全问题？如果您的顶级域名只有证书，那么SSL证书是否存在问题？即CNAME重定向是否意味着服务器看到的引荐来源将是子域或顶级域？那么跨源问题呢？

他特别喜欢在执行301永久重定向的子域中设置服务器的麻烦。当DNS RFC 1034和2672描述了这种机制并且Route53似乎支持这一点时，这似乎过于复杂。

如果有任何明确建议不设置通配符CNAME记录，你能解释为什么以及在什么情况下你建议反对它？

没有这样的安全问题。

但是，我必须指出，DNS没有提供任何机制来“重定向”本身任何请求; CNAME定义了另一个DNS名称的别名，但实际上“重定向”浏览器需要HTTP服务器 - 否则访问的用户whatever.example.com仍会whatever.example.com在其浏览器地址栏中看到，而不是example.com“重定向”本身就会行动。Web服务器也会whatever.example.com在请求中看到，如果您使用虚拟主机，这可能会导致问题。

这个警告，实际上只有两种情况，通配符DNS记录可能会导致问题：

1. 您无法提供NXDOMAIN响应，因为每个子域都存在; 这只是一个问题，如果使用DNSSEC，即使这样，它通常无关紧要。
2. SSL只能保护它所发布的域 - 但是，如您所述，通配符SSL证书可以消除此问题。

在你的情况下（根据我从你的问题中收集的内容），我很可能会使用通配符记录以及提供301重定向到我的“正确”地址的Web服务器; 一些DNS提供商使用“web转发器”使这方便，只需要注意，从技术上讲，这是一个不受您控制的Web服务器，它通过301重定向响应这些请求。（这可能听起来很可怕，但如果它是一个值得信赖的公司，那就没什么好担心的了，如果它不是一个值得信赖的公司，你首先就不应该让你的DNS托管它们！）

我现在使用通配符多年了，从来没有遇到任何问题。到目前为止，我发现2003年的Windows手机是唯一没能正确处理通配符的设备。

使用通配符的恕我直言今天很常见，问题很少出现。从安全角度来看，您可以获得一些额外的攻击媒介。例如，您可以参考“someevilXSScode.yourdomain.com”并仍然可以访问原始网站。只有一个小问题恕我直言。