一些DNS主机提供了一种方法来获得Alogging，该logging提供通过在幕后parsing一些其他主机名而实时（或经常通过计划作业）确定的IP地址。 当example.com（而不是像www.example.com这样的子域名）必须指向IP地址不时变化的主机时，这种情况会被使用，而且每次更改都不需要人为干预。 结果是，parsingexample.com产生一个Alogging，其中Alogging的IP地址由名称服务器dynamic地通过查找另一个.example.com的IP地址来确定，其本身可以是CNAME。

DNS Made Easy和easyDNS将其称为“ANAMElogging”，Route 53将其称为“别名资源logging”，CloudFlare将其称为“CNAME Flattening”，DNSimple将其称为“ALIASlogging”。 不pipe他们叫什么，parsing主机名时都会返回一个标准的Alogging。

我还没有遇到一个关于如何实现这一点的出版物，虽然这是一个相当明显的概念。 我打算在我的名称服务器（即Windows Server 2012 R2中的DNSpipe理器）中复制此行为。 是否存在用于DNSpipe理器的插件？

编辑：为了避免XY的问题，我要提供完整的背景，从症状的问题开始，并通过依赖遍历，因为它们是什么解决scheme，并没有被尝试的迹象。

• 无法加载包含“富文本”PTRlogging的反向查找区域
• 两个DNS区域：一个用于内部，另一个用于DMZ服务器，有可能吗？
• 如何以最less的configurationpipe理我的所有域名？
• BIND – 使用视图时SERVFAIL错误
• debian上的BIND 9.8.4，转发一个区域失败解决

症状

到apex域（example.com）的SSL / TLS连接会生成证书不匹配。 这种连接不是经常尝试，而是由于诸如电子邮件客户端的自动主机检测之类的事情而越来越多。 例如，我们只是将Exchange作为面向客户端的邮件服务器，而在Android或Mac Mail中将[email protected]作为Exchange帐户添加时，自动主机发现显然会派生出“典型”主机名，如example.com， mail.example.com，exchange.example.com等，并给用户一个大吓人的警告，在example.com证书上的CN不是example.com。 我们实际上使用了exchange.example.com，它有一个匹配的证书，但是自动检测必须首先尝试example.com。

当浏览器指向https://example.com时 ，也会出现不匹配的警告，但是由于大多数人在地址栏中键入example.com而没有用https：//作为前缀，在必要的时候使用redirect升级到https://www.example.com 。 由于www.example.com具有CNAME，因此可以指向没有CN不匹配的主机。

为什么在www.example.com只有一个匹配的证书而不是example.com？

具有我们的匹配证书的服务器（顺便说一下，可以轻松地使SAN条目与example.com和* .example.com相匹配，在那里没有问题）位于AWS的ELB（弹性负载平衡器）上，Amazon提醒IP地址可能随时更改。 由于dynamicIP地址，ELB只能通过其主机名来引用，这意味着一个CNAME / ANAME / Flattening /等。 这就是为什么我们能够将www.example.com指向ELB，而不是example.com。 亚马逊build议使用Route 53来克服任何限制。 如果这是不可能的，唯一的解决scheme是让example.com的Alogging点不是ELB，而是通常ELB反向代理的上游服务器。

为什么不把匹配的证书放在上游服务器上？

只有ELB本身专用于我，所以只有ELB可以安装我的通配证书。 上游服务器由主机提供商的客户共享。 我可以让托pipe公司在他们的证书上添加example.com到他们的SAN清单上，这样就不会有任何不匹配的问题，相反，我有兴趣充分利用ELB。

约束

我们固定在Win2012R2上运行内部DNS，而所有的WWW主机必须在AWS上进行恢复。