DNS TTL 最佳实践
起源
根据 CDN 小伙伴提供的数据发现，在印度，账号域名的 DNS 解析时间要比淘宝慢 174ms。
看到这，然后有了这个文章。
DNS 基础
TTL 在域名的设置里，其实是相当重要但是不容易被提起的一个值。TTL 的作用主要是告诉 Resolving Name Server 对 dns 记录的一个缓存时间。用户在浏览器输入 www.mi.com 的域名解析过程如下：
第一步，User 向 Resolving Name Server 发起 DNS 查询请求，Resolving Name Server 收到请求后，检查本地是否有该记录缓存，有没有 www.mi.com 的权威服务器，如果有则直接发送给 www.mi.com 的权威服务器，有没有 mi.com 的权威服务器，有没有 com 的名称服务器，到根后停止，因为每个名称服务器都知道 root 名称服务器的域名和地址。
第二步，Resolving Name Server 发起一个向根服务器的查询（所有的根服务器都是提供迭代解析，iterative resolution），根服务器返回一个负责处理. COM 的 gTLD 服务器域名列表。
第三步，Resolving Name Server 接受到根服务器返回的 gtld-servers，根据最小 RTT 的算法选择一个服务器去查找 www.mi.com
第四步，gtld 服务器也是和根服务器一样，只是提供迭代查询。Gtld 服务器返回给 Resolving Name Server mi.com 的权威服务器（authoritative name server）
第五步，Resolving Name Server 从返回的列表里选一个去继续查询 www.mi.com 的 a 记录，权威服务器查询后将返回一个 a 记录。【PS，我们的 www.mi.com 其实这里是一个 cname，一样的会继续第一步去查询这个过程】
第六步，Resolving Name Server 返回给浏览器 ip 地址，浏览器将发送特定的请求到给定的 ip。
整个解析过程看起来似乎非常复杂和繁琐，实际上是相当快的，一个最主要的原因就是缓存机制的存在。名称服务器将所获得是数据放入缓存，是为了加快以后查询的速度，下次当解析器询问本地名称服务器关于某个已知的域名的数据时，解析过程将大幅缩短。BIND 名称服务器还实现了否定缓存（negative cacheing），如果某个权威名称服务器返回的结果是所查询的域名或者数据类型不存在，则本地名称服务器也会将该信息暂时放入缓存中。
例如，假设名称服务器已经查询过 www.mi.com 的地址，在查询过程中，它会把 www.mi.com 以及 mi.com 名称服务器的名称和地址（包括 www.mi.com 的 ip 地址）加入缓存。现在如果某个解析器向该名称服务器询问 test.app.mi.com 的地址，则该名称服务器将跳过根查询这一步，名称服务器认为 mi.com 是它所知道的最接近 test.app.mi.com 的祖先，于是便会直接查询 mi.com 的名称服务器。
每次在浏览器输入域名进行查询时，以下两个问题有一个是否的话，都会去上一层进行查询。
1. 这个记录我们有缓存吗？
2. 如果缓存了，TTL 还有效吗？
什么是 TTL？
名称服务器不可能永久保存缓存数据，如果永久保存了当发生变更的时候记录无法进行传达。因此，通过定义一个生存时间（TTL），来定义数据在缓存中的存放时间，生存时间一到期，名称服务器就丢弃原有的缓存数据并从权威名称服务器获取新的数据。小米印度区域的账号域名 TTL 设置 600，在此期间如果没有相应的访问，名称服务器丢弃缓存数据，导致频繁请求上层权威，一定程度上增大解析时长。
常见 TTL 设置
TTl 通常用秒来表示。
一些常见的 TTL 设置如下：
300 seconds = 5 minutes = “Very Short” 3600 seconds = 1 hour = “Short” 86400 seconds = 24 hours = “Long” 604800 seconds = 7 days = “Insanity”
更改了 DNS 后什么时候生效？
平常会经常有业务问，hi 我修改完这个域名已经过去很久了，为什么还没有生效。
有以下几个原因：
- 浏览器缓存，浏览器缓存是将文件保存在客户端，在同一个会话过程中会检查缓存的副本是否足够新，在后退网页时，访问过的资源可以从浏览器缓存中拿出使用。通过减少服务器处理请求的数量，用户将获得更快的体验。该缓存并不遵循 DNS TTL 值，在此不做过多介绍。
- 运营商 local dns 会通过增加 TTL 来进行域名缓存，可以实现用户访问流量网内消化降低请求频率以及整体流量；有部分 LocalDNS 会把部分域名解析结果的所指向的内容缓存，并替换成第三方广告联盟的广告。
- 具有更多 DNS 服务器的复杂内部网络产生比预期更长的 DNS 更改时间。
以上是大多数服务声明如下的原因
注意：修改 DNS 服务器需要 0-72 小时的全球生效时间，如果发现某些地方记录没有生效，并且修改 DNS 的时间还不到 72 小时，请耐心等待。
什么时候使用小的 TTL？
- 知道域名会频繁更改记录。
- 一些重要的域名，一旦发生记录不可达则损失很大，这时候 TTL 建议设置的小一些。可以及时完成变更。（一些 local dns 会对 TTL 进行默认设置，所以在灾难恢复的时候时间不可控）
- 如果对 DNS 记录进行增加或者修改时，碰巧打错了记录，这时候最好的操作方法是增加或修改记录时，先修改到一个小的 TTL，然后对记录进行修改。
- 具体情境具体实现。在小米内部，办公网 DNS 和 IDC DNS 分为两部分，前者在信息部，后者在我们这，当办公网有 IDC 相关域名解析时，信息部的 DNS 管理员将解析 forward 到 IDC，在之前，IDC 的默认 TTL（$TTL）设置的是 86400，这时候导致的一个问题是当 IDC 域名发生变更后，办公网要过很长时间才能进行同步过来新的记录。在经过几次抱怨后，调整默认 TTL 到 600，当 IDC 域名发生修改，会在十分钟左右同步到办公网。
什么时候使用大的 TTL？
- 考虑到一定成本的时候，例如，dnspod 免费托管域名的最小 TTL 是 600，在 dnspod，越小 TTL 意味着价格更高的套餐也就是客户承担更大的成本。
- 一个大的 TTL 可以缩短查询时间。如果每次请求都去权威服务器，会增加解析的时间。
- MX 记录，DKIM and SPF，TXT 记录，这几个记录可以设置更长的 TTL。
- 域名的指向记录很少发生更改，CDN 域名，cname， A 记录，如果这些都确定很少更改，可以将 TTL 设置为 12h 或者一天。
- 当根域或者 ISP 级别的 dns 服务器发生 ddos 时，如果攻击事件在 TTL 内，部分用户会无感知。
但是需要注意的是，在对这些长的 TTL 域名进行更改时，最好是同时更改 TTL，等待缓存生效后，在进行其他更改。
TOP 500 Moz 域名的 TTL 设置
TTL 应该设置成怎样，有没有一个数据可以证明这个设置。Moz Top 500 网站已经完成了将所有网站都放到 CSV 文件的复杂工作。这里通过 ruby 脚本来遍历列表，查找每个域名当前记录的 TTL。这不是一个足够宽泛的范例，它是拉取当前（缓存）的结果。基于此前提，仍然有一些可以借鉴的结果。
查看修改代码：
https://gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b
查看 top500 Moz 域名：
https://moz.com/top500
运行结果：
http://note.youdao.com/noteshare?id=7a095fe319bbc36a3e22f92ad5f23a7d&sub=E772EBAD2B884659883C0F3E6360EA4E
Lowest TTL: | 1 |
|---|---|
Highest TTL: | 127,184 |
Domains Resolved: | 481 |
Average TTL: | 5092.465696465696 |
Median TTL: | 300 |
SOA TTL
在每个 DNS 区域的顶部，有几个 TTL 在 DNS 中发挥重要作用。
Refresh TTL – 从服务器向主服务器刷新的时间。Notify 参数可以设置主发生改变时主动向从更新，关闭 notify 时会采用这个 refresh 时间。
Retry TTL – refresh 失败后的重试时间。
Expiry TTL – 当 refresh 和 retry 都失败，从服务器无法和主服务器建连，过了 expiry 时间后将无法提供权威解析，从会删除自己的 copy。
一般这几个 TTL 不建议自行修改，除非明确知道自己在做什么。
综上，针对一开始的问题，最佳 TTL 可以设置为 86400 或者其他更大的值，通过设置更高 TTL 后查看效果会发现 dns 解析时间缩短。
参考文章
浏览器缓存：
http://www.alloyteam.com/2016/03/discussion-on-web-caching/
Definitive Guide to DNS TTL Settings：
https://blog.varonis.com/definitive-guide-to-dns-ttl-settings/
全局精确流量调度新思路 - HttpDNS 服务详解：
UNDERSTANDING TTL VALUES IN DNS RECORDS：
https://ns1.com/articles/understanding-ttl-values-in-dns-records
《DNS 与 BIND》 [美]Cricket Liu & Paul Albitz