我们有一个使用 Route 53 作为 DNS 提供商的域。我们有许多查询记录不再存在。我认为设置一个具有高 TTL 的捕获所有记录是个好主意，例如：*.example.com -> 1.1.1.1。这意味着所有没有现有记录的 DNS 查询都将具有较长的 TTL。问题是，现在当我创建新记录并使用https://www.whatsmydns.net/一些服务器返回真实1.1.1.1IP 地址，一些服务器返回真实 IP 地址。这是好的做法吗？
谢谢
答案1
在没有与这些地址的所有者达成某种协议的情况下将您的 DNS 记录指向其他人的 IP 地址绝不是一个好的做法。
此外，拥有*记录通常不是一个好主意。有一天，您可能会遇到确实需要 NXDOMAIN 响应某些名称的情况，如果*存在记录，情况就会变得有点棘手。此外，*区域中存在记录意味着您很容易忘记您一直依赖该记录的实际名称*。这最终意味着很难用*单个名称记录替换记录，因此您可能会陷入次优配置。
另外，正如您所注意到的，较高的 TTL 意味着您所做的更改需要很长时间才能生效。这就是为什么 NXDOMAIN 响应的 TTL（通过 SOA 记录指定）通常相当低的原因。
此外，*记录可能不会像您想象的那样减少查询。没有记录的区域*有天文数字般的不存在的名称。没有递归器会为每个可能的 63 个字符子域缓存单独的条目。因此，对不存在的名称的查询可能会产生无穷无尽的查询流，而缓存单个名称永远无法减少查询流。
另一个选择是使用 DNSSEC 对您的区域进行签名。随着RFC 8198DNSSEC 允许递归器根据涵盖整个名称范围的缓存条目（而不是每个缓存记录仅涵盖一个名称）使用 NXDOMAIN 进行响应。
如果你从支持RFC 8198，那么您可以通过签署您的区域来减少这些查询。
具体来说，RFC 是这样说的：
如果验证解析器的反向缓存具有足够的信息来验证查询，则解析器应使用 NSEC、NSEC3 和通配符记录来合成答案，如本文档所述。否则，它必须回退以将查询发送到权威 DNS 服务器。
答案2
现在当我创建一个新记录并检查传播时
DNS 的工作方式并非如此。整个互联网上运行的每个递归系统都必须了解各个记录（除非 DNSSEC 签名区域提供不存在的证据 - 请参阅 kasperd 的回答），其中许多系统都定义了它们愿意遵守的最大 TTL 限制。服务器在重新启动时也会忘记这些缓存信息。这是一场无法取胜的战争，因为互联网上的递归系统数量很可能超过请求 DNS 记录的实际设备数量。
这是一个好的做法吗？
即使我们假设可以使用缓存数据来显著减少互联网上远程系统所请求的数据，答案仍然是否定的。许多人没有意识到，大多数递归 DNS 实现都会缓存不存在除了记录的存在之外，还必须记录的记录。您不应该向 DNS 服务器提供虚假数据，因为这些数据只会占用 DNS 缓存中的更多空间，并使试图请求资源的人感到困惑（因为您告诉他们与 IP 对话，而不是告诉他们 IP 不存在），而应该简单地告诉这些服务器记住您不存在的记录更长时间。正如 kasperd 正确指出的那样，干扰 NXDOMAIN 实际上防止递归系统无需提交额外查询即可确定不存在。
负TTL由控制消极的TTL 字段和 SOA 记录本身的 TTL。取两个值中最小的那个。感谢 Håkan 的提醒！
example.com. IN SOA ns.example.com. hostmaster.example.com. (
2003080800 ; sn = serial number
172800 ; ref = refresh = 2d
900 ; ret = update retry = 15m
1209600 ; ex = expiry = 2w
3600 ; nx = nxdomain ttl = 1h
)
（样本 SOA 记录借自火箭科学家的 DNS）
您的有效负 TTL 会告诉远程递归服务器，如果记录不存在，它们应该等待多少秒才能再次询问。缺点是（不出所料）如果您的公司在 DNS 记录实际生效之前过早开始将客户引导至该记录，那么您将自食其果。幸运的是，您不会太自食其果，因为大多数 DNS 服务器软件会忽略非常高的 TTL 值（包括负值），这些值高于它们在本地配置中定义的最大值。
简而言之，诚实地对待记录的不存在几乎总是最好的。如果您希望远程服务器更长时间地记住数据的不存在，或者识别为什么您会收到很多过时的数据请求，并从源头上解决问题。（过期的链接等）