Linux下域名解析的优化

缘起

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

下策

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

nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3

优化之后，文件内容变为：

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也是会做一级缓存的。所以，我认为其为上策！