瑞安提供了一个很好的答案来解释你的问题。 然而，既然我们的目标受众，以及人们最容易偶然发现的情况，我会回答一个不同的问题。
当一个坏的TTL出现在野外，公司做了什么？
你在这里有几个select。 首先，但最重要的是，您需要确定问题向量并将其消除。 当你无法控制重复出现的问题时，试图遏制这种伤害是毫无意义的。
- 等待。 如果这不是一个关键的logging，你可以等待它。 正如瑞安所说，“最大损害”不是68年，但实际上最可能是7天。 这是积极caching条目（BIND，JunOS等）的最长寿命的最常见默认值。 即使在这不正确的情况下，也会希望服务器正在接收强制进程重启的例行安全更新。 作为几个大型集群的运营商，我不觉得MSO可能会把这个目标设定为更大的价值：它只会产生更多的外部查询（我们讨厌）。 对于使用不太stream行的软件的公司，或者讨厌自己的运营商，您可能需要继续下一步。
- 恼人的DNScaching运营商。 如果您需要尽快从caching清除logging，那么您唯一真正的select是开始接触您可以想到的recursionDNS的最大提供商，然后继续工作。 其中一些公司可能会忽略你：他们认为你的公司太小，不能让顾客关心，或者他们build立自己的caching清除策略，以尽量减less他们必须处理的支持电话的数量。 在后一种情况下，他们可能会耸耸肩，让问题在预定的时间自行处理。 毕竟，你的公司确实造成了这个问题。
- 让ISP客户烦你的ISP。 如果过了几天，一个大的ISP忽略了caching的logging，试着让他们的一个客户投诉，并在该公司内部生成一张票。 这对他们来说很难忽视，但是从他们的angular度来看，他们并不会从他们的angular度来赢得任何好处。 如果这是重复发生，他们可能会开始取消这些票，只是为了不顾一切。
- build议您的合作伙伴绕过DNSlogging。 如果这是您的合作伙伴消耗的关键任务DNSlogging，并且以上选项都不可接受（即，您正在逐渐减less收入），则您的公司别无select，只能与合作伙伴一起绕过该问题。 如果他们不控制本地caching，通常这是通过在受影响的系统的主机表中插入条目来完成的，因为它避免了修改正在使用DNSlogging的程序的需要。 如果收入损失与选定的几家公司消费数据有关，这是唯一可行的。 在其他所有情况下，您都会遇到前三个选项。
那么，我首先看到的绑定configuration手册说，TTL是一个有符号的32位整数，以秒为单位，给它理论最大值2 ^ 31。 它说
有效TTL的范围是0-2147483647秒。
或大约68年。 所以你可能不能把它设置为100年。
所以，假设你把它设置为68年。 这很清楚会发生什么。 尊重DNSlogging中非常长的TTL的DNSparsing器会尽可能长时间地caching它们。 一些DNSparsing器根本不尊重TTL，只是实现他们自己的caching策略。
我们不能把一个硬编码放在最大值的原因是因为许多不同的供应商创build了许多不同的DNS实现，而且它们都使用稍微不同的variables。 例如，Juniper JunOS上运行的DNS服务器在TTL上最多只能运行604800秒或7天。