Linux下域名解析的优化

缘起

Linux系统下域名解析的配置文件是/etc/resolv.conf,这个大家都知道。估计一般的系统管理员、运维人员都知道在这里面配置上两个或更多的nameserver,以便一个挂掉后还能正常解析域名。但真的情况是这样吗?
我从某次故障说起吧,有一次,线上报大量的dns解析失败,上去看,发现是一台nameserver挂掉了,幸好/etc/resolv.conf中的另外一台没有挂,所以,还不是百分百的解析失败。从逻辑上来讲,这些失败的请求应该会去尝试另外一个(好的)nameserver的,但是重试的场景和策略是什么呢?不得而知。所以我就关注了下/etc/resolv.conf文件的配置问题。

下策

优化方案之一,就是在/etc/resolv.conf中做优化设置。优化前内容如下:

1
2
3
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3

优化之后,文件内容变为:

1
2
3
4
options timeout:1 attempts:1 rotate
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3

这里大概讲下新加的几个选项的含义:

  • nameserver:dns服务器的ip地址。最多能设三个。
  • timeout:查询一个nameserver的超时时间,单位是秒。系统缺省是5,最大可以设为30。这他娘不是坑爹吗?那个应用的dns请求会允许这么长的超时时间?早tm超时出错返回了吧。所以我们这里改成最小值:1
  • attempts:这个是查询的整个都尝试一遍的次数。缺省是2,我觉得在有3台nameserver的前提下,都查询一遍就完全够了(毕竟三台中有一台能正常查出结果的概率是相当大的吧,尤其是nameserver都有监控的说)
  • rotate:这个参数的含义是随机选取一个作为首选查询的dns server。系统缺省是从上到下的,所以你该了解到为什么缺省情况下第一个nameserver的负载比第三个的大多了吧。

之所以这只是下策,是因为这种解决方案如果碰到有一台nameserver(假如是10.0.0.1)挂掉的情况下,客户端解析请求如果又恰好分到这台nameserver的时候,应用会解析超时失败的概率太高了。

中策

中策就是做nameserver的高可用,用lvs来做,做两个vip:10.0.0.4和10.0.0.5,后端real server还是指向这三台真实的nameserver:10.0.0.1、10.0.0.2和10.0.0.3,这样real server的健康状况就由lvs来维护了,这样当客户端来访问vip时,只要后端的3台不都挂掉,就一定能保证返回正确的结果。
具体的配置我就不贴了,直接用keepalived来做即可。
这个解决方案其实也挺完美的,尤其是当有现成的lvs director的时候。看了最后一策,就知道为什么这个只是中策了。

上策

这个方案是我仔细考虑后推荐的方案,尤其适用于没有现成的lvs director的环境里。这个方案的主要特点是:

  • 本机起dnsmasq,监听本地的udp 53口,用来监听来自于本地的解析请求。
  • 在dnsmasq里,将上层服务器定义为10.0.0.1、10.0.0.2和10.0.0.3。

这个方案的优点在于:

  • 本地虽然多起一个dnsmasq服务,但是仅监听127.0.0.1,所以基本不影响性能
  • dnsmasq会自己维护上游服务器的健康状况,不会把解析请求发到挂掉的上游服务器上

这个方案能够自动做dns server的故障切换,而且不引入任何外部的依赖(dnsmasq是本机跑的),几乎不影响性能,甚至于还有可能提升性能,毕竟,dnsmasq也是会做一级缓存的。所以,我认为其为上策!