DNS缓存管理是域名解析系统运维的重要一环，本期云学堂从权威侧、递归侧、客户端等多个方面分析讲解了DNS缓存管理的关键措施，帮您避开运维雷区，enjoy：
一、DNS TTL存在位置
1.1互联网解析流程分析
之前的文章里对什么是DNS、DNS的作用等都做过详细分析，这里就不再做更多说明了。本篇先从一个典型的通过常见互联网业务访问开始说起DNS解析步骤。
客户端希望访问www.zdns.cn网站，要分别经历递归请求、迭代请求和客户端与服务端之间点到点的IP访问。
下图中第一象限为互联网权威服务器，第二象限为运营商“递归域名服务器”（后面统称为Local DNS或LDNS），第三象限为客户端，即我们经常使用的电脑、手机等终端，第四象限为应用服务器或服务器集群。
假设本次访问中所有环节都没有缓存
1、当用户希望访问www.zdns.cn网页时，在浏览器中输入www.zdns.cn，浏览器先检查是否有该网站的缓存（域名与IP的映射关系），有则直接使用访问，如果没有DNS请求发送到客户端解析器，解析器会向运营商LDNS发起解析请求；
2、LDNS会分别向根、cn.、zdns.cn.发起解析请求，最终获取到www.zdns.cn域名对应的ip地址：202.173.11.10，此时LDNS会将该信息缓存（随之一起缓存的还有A记录、TTL信息，假设此时TTL为300s），同时将“www.zdns.cn. 300 IN A 202.173.11.10”应答给用户客户端；
3、此时浏览器拿到www.zdns.cn对应的地址，因此客户端以本地公网IP为源地址向202.173.11.10发起http的业务请求；
4、此时LDNS在300秒内，若有另外一个客户端再向同一个LDNS发起www.zdns.cn请求，则LDNS不会再向权威服务器发起请求，但应答信息会有变化www.zdns.cn. 210 IN A 202.173.11.10其TTL为小于300秒的数值。
1.2缓存存在位置
缓存主要存在于第二象限LDNS、第三象限客户端中。
当第一象限中的的权威服务器打开递归功能后，则该服务器上也会有响应的缓存。
当地四象限中的服务器作为客户端解析其他域名的时候，其也会存在域名缓存。
在实际应用中，存在系统缓存、应用缓存、浏览器缓存。
由此可见DNS 缓存在整个访问流程中可能会无处不在，缓存的存在会给DNS服务器减轻解析压力，同时也会加快解析速度。但缓存的存在也会给业务切换的时效性带来一些困惑。
例如：
1、 当业务发生主动运维切换，业务切换到备服务器会有一定的延迟；
2、 当业务故障切换，由于缓存的存在，则会给用户使用带来负面体验；
3、 当权威域名被劫持，那么缓存会带来不可弥补的损失。
那么在复杂的生产应用环境中应该如何合理管理DNS缓存？
二、缓存管理
2.1权威服务器缓存管理注意事项
正常情况下权威DNS服务器不应该打开递归功能，因为权威DNS 服务器打开递归功能后当收到非本地权威域名解析，权威服务器会代替LDNS发起DNS解析请求。此时会降低权威服务器处理权威域名的性能，同时还可能遭受到互联网DNS攻击。
若在实际使用过程中必须要打开权威服务器的递归功能，则需要仅开通信任网段地址即可。
2.2递归服务器缓存管理注意事项
递归服务器主要是世界各地运营商的LDNS，其存在的作用为面向广大客户端群体，高速缓存权威域名的信息，提高解析效率。
正常情况下LDNS需要继承权威服务器设置的域名TTL，这样方便域名管理人员对缓存老化速度的掌握。但在实际使用过程中有一些偏远地区运营商为了减小服务器的眼里，否定了权威DNS服务器设置的TTL，强制将本地缓存的域名TTL设置为1天或更久，这样当域名地址发生变动后，用户实际体验就会变得非常糟糕。
同时针对递归服务器攻击类型纷繁复杂，对LDNS最可怕类型攻击莫过于域名拦截并篡改，当域名解析结果被篡改后客户端就会向非法服务器发起业务交互，此时客户信息就会彻底泄露。
针对该过程解析目前较为有效的办法是使用DNSSEC和HTTPDNS技术。但这两种技术目前国内使用均未完全普及。
DNSSEC
DNSSEC技术是通过对数据进行数字“签名”来抵御此类攻击，从而使您确信数据有效。DNSSEC技术已经在互联网从根服务器向下逐渐普及。
DNSSEC相比传统DNS解析而言对服务器有更多时间开销和传输开销，相信随着技术提高，这些问题会逐渐弱化。
HTTPDNS
HTTPDNS是基于HTTP协议由访问客户端直接向HTTPDNS服务器发送域名解析请求，从而避开LDNS缓存被非法篡改的可能性。HTTPDNS当前适用在自己开发的APP中。
ZDNS的产品支持DNSSEC、HTTPDNS技术，通过0x20安全加固、随机ID、随机端口等方法，在递归场景中提高服务安全性。
2.3客户端缓存管理
无论是PC终端还是服务器，当需要做DNS域名解析的时候都会作为客户端向服务器发起解析请求。而在业务解析的过程中不同系统类型客户端，不同应用环境对缓存的处理就会有不同的行为。这里对常见的几种进行分析：
Windows客户端
Windows系统对缓存默认是开启的，并继承DNS的缓存设置。当业务进行解析的时候系统就会对解析进行缓存。
需要注意的是当cname记录TTL设置较高，A记录TTL设置较低的时候Window客户端默认行为是缓存cname与A记录的TTL中较短的数值。
即例如当权威配置内容为：
www.baidu.com. 1200 IN CNAME www.a.shifen.com.
www.a.shifen.com. 300 IN A 180.101.49.12
www.a.shifen.com. 300 IN A 180.101.49.11
通过Windows系统解析后，查看系统缓存结果为：
www.baidu.com. 300 IN CNAME www.a.shifen.com.
www.a.shifen.com. 300 IN A 180.101.49.12
www.a.shifen.com. 300 IN A 180.101.49.11
CNAME的TTL备修改为300
Suse操作系统
Suse12操作系统默认不开启缓存，当开启缓存时，继承DNS记录的缓存值。
AIX操作系统
AIX7.1操作系统默认不开启缓存，当开启缓存时，不继承DNS记录的缓存值，继承操作系统本地配置的缓存超时时间。
JDK环境
JDK默认开启缓存，不继承DNS记录的缓存值，遵循自身配置的超时时间。
在实际使用过程中不同操作系统、应用环境组合对缓存的是否开启设置，会对业务切换有很多影响。因此为了保证业务的快速准确的切换，需要制定统一规范，要求系统必须遵循DNS设置TTL。同时制定在不同组合场景中如何设置才能满足遵循DNS设置TTL时长。
2.4否定缓存管理
在实际使用权威DNS会收到很多本区中不存在的域名，此时设备通过使用否定缓存时间对这种垃圾请求进行管理。
否定缓存时设置，在BIND设置中SOA记录设置最后一个时间就是否定缓存时间（Negative TTL）。
图2-1
否定缓存时间生效机制：否定缓存时间会与SOA记录的TTL进行比较，选取较小的值作为否定缓存时间。
例如图2-1所示，SOA的TTL设置时间为3600，而否定缓存时间设置为1800，此时对不存在域名进行解析，得到的TTL为1800，如图2-2所示
图2-2
若将SOA的TTL修改为1500
图2-3
此时对不存在域名进行解析，得到的TTL为1500
图2-4
三、服务器业务切换管理
3.1主动维护业务切换
主动维护业务切换主要场景为切换演练、业务迁移、灾备切换等场景。主动业务切换一般可以提前将域名TTL修改到较小值，当全网同步设置TTL后，域名将解析结果由老的IP地址更改到新的IP地址。
互联网场景中，老的集群需要与新的集群并行运行1-2天，保证偏远运营商下用户载缓存过渡期内的正常业务体验。
3.2被动业务切换
被动业务切换主要场景为业务集群故障，需要切换到备用集群做应急恢复。无论业务集群有多健壮都要做好业务异常切换的准备，此时对于内网和互联网业务缓存管理就要分别对待。
3.2.1内网生产环境
首先需要主动发现业务集群是否可用，设置DNS服务器主动探测服务器是否可用；
其次就是域名TTL设置，TTL设置时间过长会导致故障后会有较长时间的业务无法访问，若TTL设置较短，业务恢复就会恢复，但对DNS系统压力就会增大。因此根据不同业务的响应级别设置域名TTL，需要保证在秒级别。从而保证业务切换期间业务尽快恢复。
内网中若有LDNS服务器，则需要在做业务切换后联动清空LDNS上指定域名的缓存。
3.2.2内网办公环境
内网办公业务由于影响范围可控，同时配置变动较小，可以将TTL设置在小时级别。内网中若有LDNS服务器，则需要在做业务切换后联动清空LDNS上指定域名的缓存。
3.2.3互联网环境
互联网环境也需要配置监控业务是否可用，保证业务故障后可以自动切换。
同时互联网环境中由于运营商LDNS缓存服务器的存在，具有不可控性，因此不适宜配置较长的缓存时间，建议参考DNS性能配置较小缓存值，例如分钟级。
对于运营商的缓存，随着运营商DNS不断发展，已经可以做到对管辖下LDNS中的指定域名缓存进行清除。
3.3集群健壮性建设
为了保证业务的稳定运行需要减少被动的业务切换，因此业务集群需要考虑足够健壮。