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