它们应该仍然容易受到攻击，因为通配符记录的签名是字面上的“*”。RFC 2535 (DNSSEC)、RFC 3845（NSEC RDATA 格式）和RFC 5155（NSEC3 散列响应）中介绍了如何处理通配符结果的详细信息。

这个简单的描述有助于我理解如何证明通配符响应：“接收名称服务器可以从中得出记录 'www.example.com' 是从 '*.example.com' 合成的，并检查签名因此。”

在通配符响应的情况下，一些设计用于执行 NSEC-walking 的工具和脚本可能会失败，但这并不能证明攻击仍然不可能。

如果您担心攻击者会在您的区域中行走，您应该将其配置为使用 NSEC3 而不是 NSEC 进行拒绝。这适用于通配符记录，在任何一种情况下都与区域行走无关。

NSEC3 使用名称的散列来断言记录不存在。攻击者无法从哈希中获取原始名称，因此他不会收到指向区域中相邻名称的提示。

与 NSEC 的情况一样，攻击者仍然可以判断出响应是由于存在通配符记录。但是，无论区域是否包含通配符记录，NSEC 都可以进行区域遍历（而 NSEC3 则不可能）。

Server 2012（及更高版本）和 BIND 9+ 中的 Windows DNS 支持 NSEC3。旧版本仅支持带有 NSEC 的 DNSSEC。