这归结为子域枚举：

假设您有一个通配符 DNS 条目，并且攻击者尝试以下子域：

admin
cms
email
ssh
rdp
secure

如果您有通配符 DNS 条目，则将返回以下结果。

admin.example.com - Exists
cms.example.com - Exists
email.example.com - Exists
ssh.example.com - Exists
rdp.example.com - Exists
secure.example.com - Exists

如果您不这样做，那么攻击者可以确定可能存在哪些私有站点和服务：

admin.example.com - No entry
cms.example.com - No entry
email.example.com - No entry
ssh.example.com - No entry
rdp.example.com - No entry
secure.example.com - Exists

也就是说，攻击者已经设法确定您拥有一个secure.example.com可能托管某种敏感服务的 FQDN。但是，即使使用第一个示例，攻击也可以找出每个条目是否解析为相同的 IP。只有在其协议中包含主机名的服务才是真正的问题，例如带有host标头的 http 和带有服务器名称指示 (SNI) 的 https。这意味着攻击者必须发现这样的服务，然后向域发出有效请求以确定您是否在那里有任何服务（例如cms.example.com在第一个示例中请求并设置正确的主机头或 SNI 字段）。

根据您提供的上下文，我没有看到重大威胁。

我假设您正在运行一个非常典型的面向互联网的 Web 服务，从这个角度来看，您的安全研究人员提供的解释似乎有点混乱。

我能想到的最常见的是网络钓鱼。通配符 DNS 是一个方便的功能，网络钓鱼者显然正在使用它来绕过过滤。

我看不出这对您有何直接威胁，因为可能攻击者无法修改您的 DNS 记录。我可以看到它可能对您的用户（通常是互联网用户的一部分）构成威胁，这些用户通常容易受到 DNS 中毒或网络钓鱼的攻击，但这远远超出了您的控制范围。

使用通配符 DNS 网络钓鱼者可以动态生成任意数量的不同 URL，并且经常规避过滤技术

同样，这是真的……但仅限于他们控制的任意域，而不是您的域。

并且没有通配符条目，因此攻击者可以轻松枚举您的秘密和公共子域。

我想如果攻击者发现很难区分合法服务和假/蜜罐服务，那么这里可能有一些有效性。在实践中，您将需要大量运行虚假服务的虚假服务器，以使攻击者识别合法服务变得更加困难。

此外，除了简单地使面向公众的服务更加模糊之外，还有更有效的方法来保护面向公众的服务。

如果您的情况与我的假设不同，则可能需要考虑其他攻击向量。例如，如果您使用私有 DNS 运行内部网络，该网络为其他人可能控制的可公开解析的域提供记录。不过，这听起来不像。