DNS解析及缓存技术研究与应用

Posted 匠心独运维妙维效

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了DNS解析及缓存技术研究与应用相关的知识,希望对你有一定的参考价值。

喜欢就关注我吧,订阅更多最新消息


引言





2
Linux DNS客户端



domain ebank.com

search ebank.com

nameserver 192.168.0.1

nameserver 192.168.0.2



3
解析机制及响应时间

domain用来定义本地域名,这个是对域名没有加”.”符号的加上域名,即在进行不完全域名解析时,默认的附加域名后缀。对于search是用于定义域名的搜索列表,当访问的域名不能被DNS解析时,会将该域名加上search指定的参数,在没有设置search的情况下,search默认为domain的值。



options timeout:1

options attempts:1



总体来看,为了加快操作系统在作为客户端进行域名解析时的速度,避免在DNS故障时造成的DNS解析响应率低,一方面可调整options参数以降低超时时间和尝试的轮询次数,另一方面不设置domain和search,使得DNS解析失败更快速,也提高主DNS故障时切换效率。




4
DNS解析缓存及失效



nscd是glibc中带的dns缓存组件,通常调用C库的网络解析函数如gethostbyaddr、gethostbyname等时会使用到nscd的缓存功能,不需要显示的调用nscd功能。通常Java或python库中相关的函数最终也是调用的C库中的解析函数,所以也会用到nscd的dns缓存功能。如果没有使用C库中相关的网络解析函数,是无法默认使用nscd的dns缓存功能的,如nslookup、dig等工具。


默认suse12中nscd服务用于dns等的缓存服务,里面配置了用于hosts(即DNS缓存),passwd,group,service等的缓存。本文主要探讨DNS缓存服务。


用于缓存时间长短的参数为:

positive-time-to-live   hosts  600

negative-time-to-live   hosts   0


其中positive-time-to-live正向解析缓存时间,单位秒。查看glibc-2.17/nscd目录下的代码,实际上这个参数并未使用,而是直接以DNS应答(answer)报文中带的TTL值为准,即DNSServer上对应解析项设置的有效期。


DNS解析及缓存技术研究与应用

reload-count默认为5,解释如下:

Limit on the number of times a cached entry gets reloaded withoutbeing used  before  it getsremoved.


此参数代表是缓存nscd中缓存的dnscache记录自动reload的次数,默认是5次。由nscd主动往dnsserver发起dns请求,如果期间解析结果有变动会更新nscdcache中缓存的记录reload触发的时间点TTL+CACHE_PRUNE_INTERVAL(宏定义为15),即每次reload间隔75秒。

彻底从cache中被移除的时间应该是75*(1+5)=450s左右。


negative-time-to-live为反向解析缓存的cache时间,单位为秒,默认值为0,即不缓存DNS反向解析。

不管是正向还是反向解析cache,失效后都会被清除,nscd-d 调试的时候可以看到类似的输出:removeGETAI entry "www.baidu.com"


redhat7.5母带默认没有安装nscd,不涉及缓存。如果自行安装,则默认hosts(即dnscache)的positive和negativettl值分别为3600s(实际不生效)和20s。



5
实验验证环节



环境:

Redhat7.5,Client:master, 192.168.43.100, 

DNSServer:gateway,192.168.43.1


配置/etc/resolv.conf

nameserver192.168.43.1  ##默认网关,再通过网关路由到后面公有DNSserver


配置/etc/nscd.conf中:

negative-time-to-live  hosts  10

systemctlrestart nscd重启nscd生效。


测试命令:pingwww.baidu.com


从抓包看,A记录的DNS应答报文中带的TTL为60s,即DNSServer上对应解析项设置的有效期为60s。


DNS解析及缓存技术研究与应用


NSCDdebug输出中包含Reloading的记录,可以看到刚开始第一次获取到了ip,然后nscd自动从dnsserver 重新reload记录信息。每次间隔正好是60s+ 15s=75s。


Sun24 Jan 2021 12:49:16 AM EST - 23536:  GETAI (www.baidu.com)

Sun24 Jan 2021 12:49:16 AM EST - 23536:  GETHOSTBYADDR (39.156.66.18)

Sun24 Jan 2021 12:50:31 AM EST - 23536: Reloading "www.baidu.com"in hosts cache!

Sun24 Jan 2021 12:51:46 AM EST - 23536: Reloading "www.baidu.com"in hosts cache!

Sun24 Jan 2021 12:53:01 AM EST - 23536: Reloading "www.baidu.com"in hosts cache!

Sun24 Jan 2021 12:54:16 AM EST - 23536: Reloading "www.baidu.com"in hosts cache!

Sun24 Jan 2021 12:55:31 AM EST - 23536: Reloading "www.baidu.com"in hosts cache!

Sun24 Jan 2021 12:56:46 AM EST - 23536: remove GETAI entry www.baidu.com


ping www.baidu.com 成功。来看其中的DNS解析环节:

1)一开始是会有正向解析请求的,然后还会有反向解析请求。

2)10s内紧接着再ping,这个时候是没有正向请求的,因为被nscd cache了。 也没有反向解析请求,因为反向请求也被cache了且在有效期内(10s)。

3)超过10s再ping www.baidu.com,仍然会有发往dns server的反向解析请求。在正向解析cache有效期TTL时间内,不会再发送相关正向解析请求,仍然使用nscd缓存的正向解析cache。

4)如果在10s中间执行nscd -i hosts 则cache被invalidate, 再ping的话正向和反向请求均会发出。



另外如果DNS服务器没有配置相关PTRentry,会等待超时返回,这会降低应用响应时间。在我行年金系统上曾经出现过这种情况。通过在DNS服务器上配置相关PRTentry(尽管是无用的配置,但是能提高响应速度)



5
使用建议



有类似场景的应用系统应掌握和理解DNS解析及缓存机制,合理设置dns解析的重试、超时范围,合理利用DNScache加速解析,同时也要避免设置不合理造成的解析不同步,影响业务响应及失败,特殊场景下可通过工具或回调方式显示触发invalidatedns cache操作,保障dns解析的时效性。




编辑:张至南








以上是关于DNS解析及缓存技术研究与应用的主要内容,如果未能解决你的问题,请参考以下文章

腾讯技术工程 | 腾讯AI Lab解析2017 NIPS三大研究方向,启动教授及学生合作项目

我眼中的 Nginx:深入 Nginx/Openresty 服务里的 DNS 解析

最近开始研究php的缓存技术,来个系统自带的OPcache

想用好 DNS 技术必看:浅析DNS缓存技术及应用考虑

CDN的功能及原理

域名缓存侦测(DNS Cache Snooping)技术