[编辑后补充：这个问题已经自行消失。我认为 Cloudflare 的名称解析可能是罪魁祸首。请参阅下面我自己的回答]
这是我的区域文件的片段
*.example.com. 300 IN CNAME proxy.herokuapp.com.
foo.example.com. 300 IN A 111.111.111.111
如果我dig @8.8.8.8 foo.example.com得到了我期望的答案：
;; ANSWER SECTION:
foo.example.com. 30 IN A 111.111.111.111
我尝试过的所有其他公共 DNS 服务器也是同样的情况。
然而，当我尝试设置检查时平多姆到其上的 URL foo.example.com，而是将流量发送到*.example.comRR 引用的我的 Heroku 应用程序。
同样适用于设立在新遗物，飞机以及由Heroku应用程序本身。
因此，一方面，所有公共 DNS 服务器都以一种方式解释区域文件。然而，四家服务提供商却以不同的方式解释区域文件，这种方式与 RFC 4592 建议的标准不同。
我的问题是：这些信誉良好、成熟的服务提供商都错了吗？还是只是我错了？
答案1
从协议角度来看，权威域名服务器合成对通配符范围内的查询的响应，而不是查询该通配符的服务器的响应。如果您收到不同的响应，则必须出现以下情况之一：
- 它们不是与同一台服务器通信。要么您有多个身份验证名称服务器，它们发送不同的响应，要么正在咨询完全不同的一组身份验证服务器。（您的公司是否运行拆分 DNS 配置？）
- 一些缓存服务器在缓存中有一个较旧的记录。
- DNS 被完全绕过，即 hosts 文件中的条目。
答案2
大约 10 天后，问题自行消失。我猜测 Cloudflare（负责运行该域名的名称服务器）更改了其 DNS 解析代码。
更多信息：
Andrew B 的答案 (2) 是一个候选答案：该名称由缓存服务器解析，自从我添加 A 记录以来，缓存服务器一直没有刷新。该问题持续了一周多，所以我认为这不太可能。
我向 Cloudflare 提出了这个问题，并已上报给工程团队。他们最近发布了一些更新的名称解析代码（https://twitter.com/eastdakota/status/351733117003902976）
我认为我比提问时更了解名称解析的工作原理。似乎更有可能是单一原因（Cloudflare 错误），而不是多个原因（Heroku、NewRelic、Pingdom 和 Errplane 上的单独错误）。