我发现Azure DNS服务不会在CNAMElogging查找中返回一个IP地址。 例如，Google或AWS Route 53 DNS服务器会在相同的查询中返回相应Alogging的IP地址。 为了testing目的，我创build了www1 CNAMElogging，指向www.myzone.com：
AWS Route 53testing
$ dig www.myzone.com @ns-560.awsdns-06.net ;; ANSWER SECTION: www.myzone.com. 7200 IN A MY.IP.ADD.RESS $ dig www1.myzone.com @ns-560.awsdns-06.net ;; ANSWER SECTION: www1.myzone.com. 3600 IN CNAME www.myzone.com. www.myzone.com. 7200 IN A MY.IP.ADD.RESS Google DNS服务器显示相同的结果：
$ dig www1.myzone.com @8.8.8.8 ;; ANSWER SECTION: www1.myzone.com. 3599 IN CNAME www.myzone.com. www.myzone.com. 7199 IN A MY.IP.ADD.RESS
MS Azuretesting
$ dig www.myzone.com @ns1-02.azure-dns.com ;; ANSWER SECTION: www.myzone.com. 7200 IN A MY.IP.ADD.RESS $ dig www1.myzone.com @ns1-02.azure-dns.com ;; ANSWER SECTION: www1.myzone.com. 3600 IN CNAME www.myzone.com.
请注意，Azure DNS在第二个查询中不返回IP地址。
我的问题：这是一个预期的行为，我可以configurationAzure DNS返回相应的Alogging在CNAME请求，如AWS或谷歌吗？
我在MS论坛上发现了一些类似但没有答案的主题（ 1,2 ）。
是的，名称服务器应该在特定情况下返回CNAME和A. RFC1034表示： “这两个RRs将在对typesA查询的响应中返回”。
您所观察到的是Azure DNS的当前devise行为。 Azure DNS目前不追踪CNAME（和类似loggingtypes）RDATA中的域名。 相反，它依赖于recursionDNS服务来重新查询 – 它所做的事情，所以这个场景工作到头了。 重新查询会造成稍微的额外延迟，但实际上由于DNScaching，这是微不足道的。
这种devise的原因是为了防止跨域名追逐。 例如，如果您在Azure DNS名称服务器上拥有foo.com，则可能会在属于其他人的同名服务器上与bar.com共享。 我们不会从foo.com追踪到bar.com，因为您可能更喜欢在不同的服务器上使用不同的bar.com。
我们正在跟踪积压项目，以便在将来追踪域名。
Azure DNS项目经理Jonathan Tuliani