推荐的 DNS TTL

Bri*_*her 27 domain-name-system web-hosting ttl

我知道根据情况它可能会有很大不同,但是对于托管一个没有计划移动托管服务器的网站来说,在 DNS 记录上设置什么 TTL 是好的?

cee*_*yoz 23

我倾向于将其保留为 Slicehost 的默认值,即 86,400 秒(1 天)。当我有待处理的动作并等待一两天时,我会将其缩短到 10 分钟。

编辑:这些天(2016 年)我倾向于保持低 - 约 5 分钟。

  • @AnthonyGeoghegan 现代服务器可以处理更频繁的请求,现在我使用的是高度可靠的名称服务器(AWS Route 53),我希望能够灵活地随时更改 DNS。 (3认同)

dmo*_*ati 14

标准建议(写了一个很长的时间1987年以前)建议86400秒(1天)为最小默认TTL。

将 TTL 设置为适当的值很重要。TTL 是解析器在再次询问您的服务器之前将使用它从您的服务器获得的数据的时间(以秒为单位)。如果您将值设置得太低,您的服务器将被大量重复请求加载。如果您将其设置得太高,那么您更改的信息将不会在合理的时间内分发。如果将 TTL 字段留空,它将默认为区域的 SOA 记录中指定的内容。

大多数主机信息在很长一段时间内不会发生太大变化。设置 TTL 的一个好方法是将它们设置为较高的值,然后如果您知道即将发生更改,则降低该值。您可以将大多数 TTL 设置为一天 (86400) 和一周 (604800) 之间的任何位置。然后,如果您知道某些数据在不久的将来会发生变化,请将该 RR 的 TTL 设置为较低的值(一小时到一天),直到发生变化,然后再将其恢复为之前的值。

此外,所有具有相同名称、类和类型的 RR 应具有相同的 TTL 值。

请参阅 RFC 1033:http : //tools.ietf.org/html/rfc1033

RFC 1912(从 1996 年开始)建议 3 天可能更适合SOA记录。

http://www.ietf.org/rfc/rfc1912.txt

  • 我对此发表评论很晚,但应该注意的是,将这些 RFC 中的任何一个称为“标准”都是不合适的。([RFC 1796](http://tools.ietf.org/html/rfc1796)) 我注意到这一点是为了让今天的读者不要带着错误的理解离开这个问答。 (8认同)
  • 您引用的这两个标准都仅指 SOA 记录的“最小”字段,无论如何都不再用于确定默认或最小 TTL,正如编写这些标准时所打算的那样。27 年和 18 年前编写的 DNS 最佳实践是在 DNS——实际上是互联网——是一个不同的野兽时编写的。如今,300 秒(5 分钟)对于主要 A/AAAA 记录来说是一个相当常见的 TTL,尽管仅在需要快速故障转移时才有用,否则 6 小时以上会更合适。NS 记录以及 NS 地址的 A/AAAA 记录通常为 1 天或更长时间。 (6认同)
  • 我认为 1987 年和 1996 年来自低 TTL 的 DNS 流量比 2011/2012 年的问题要严重得多。 (4认同)

小智 7

我注意到缩短 TTL 以便能够更快地响应紧急情况(尤其是在 HA DNS 环境中)变得越来越流行。