我正在 Azure 上构建一个应用程序，该应用程序需要为每个客户使用子域。子域将在注册过程中提供。由于 Azure需要使用 CNAME 进行 DNS 解析，因此我必须在通配符 CNAME 之间做出选择，还是应该使用 API（例如Amazon Route 53 ）手动添加每个条目
我担心通配符 CName，因为存在一些问题，即所有 DNS 系统是否完全支持它们。我看到它是 RFC 规范的一部分，但我担心所有 DNS 系统的最新情况。
或者，我担心为客户实时配置新的 CNAME DNS 条目。他们是否必须等待 TTL 过期，或者是否会立即获取新的子域 CNAME 条目？
谢谢，道格
DNS 通配符就像是您的 DNS 服务器的元信息。它永远不会离开名称服务器，只是指示您的服务器以某种方式处理 DNS 查询。
您的 DNS 客户端或其递归解析器不知道、不需要知道，也无法知道*您正在使用带有通配符的 CNAME。
您拥有的 Serverfault 链接意味着您将很难找到可以添加通配符的主机。
如果 Amazon Route 53 支持 CNAMES 的通配符，那么这对于生产来说很好，假设服务器的其余部分符合其他 DNS RFC。您应该关心通配符支持的唯一其他时间是您是否在不同的提供商处使用辅助 NS 记录。
关于 TTL，有两个 TTL 需要注意：通配符 CNAME 的 TTL 或你创建的静态 CNAME。然后是存储在 Microsoft 名称服务器上的 A 记录 TTL，您无法控制它。（您也无法在 SOA 记录中控制 MSFT 的 NXDOMAIN 到期，但这是一个切线）您需要考虑在 Prod 和 DEV 之间切换时，将有客户端缓存前者的 A 记录，直到 A 记录到期. 如果您使用的是移动应用程序，那么我已经看到蜂窝 ISP 缓存此条目的时间比预期的要长，并且有些手机缓存 A 记录的时间也更长。有时解决此问题的方法是重新启动手机。
底线是不要担心 CNAME TTL，重要的是 A 记录，MSFT 拥有它。执行 dig 或 NSlookup 以查看值。如果您找到支持通配符的 NameServer，请继续使用它，但我会担心与其他 RFC 的安全性和兼容性。我真的只信任我的 ISP (ATT)、UltraDNS 和 Dynect 的 DNS 提供商。亚马逊和 UltraDNS 的关系很好。除了 ATT 之外，所有的都有一个 SOAP API。
如果您想使用 ATT，您可以将它们（或其他 ISP）用作辅助 DNS 服务器并将其设为主要 NameServer。然后对隐藏的主 DNS 进行所有更改。
我对 DNS 很感兴趣，所以请随时提出后续问题。
*脚注：他们可以通过查询 RandomGUID.domain.com 来判断您是否使用 CNAME。如果他们得到相同的答案，那么他们可以假设您使用的是通配符 CNAME。
我不知道有多少 DNS 系统支持通配符，但我知道 DNS 会缓存故障。因此，如果用户在您配置之前请求新域（或者可能从基本域请求任何内容），那么他将需要等待 TTL 才能看到新条目。