前言

resolv.conf是在各种操作系统中用于配置系统的域名系统(DNS)解析器的计算机文件的名称。该文件是一个纯文本文件，通常由网络管理员或管理系统配置任务的应用程序创建。

该配置文件会影响主机对 Internet 域名系统 (DNS) 的访问： 解析进程启动时会读取resolv.conf配置文件中的内容，resolv.conf文件包含各种参数及option，用来改变或调优对外的DNS解析行为；

resolv.conf涉及的参数及option众多，下面针对最常用的参数进行详细分析及讲解

常用参数

nameserver：

解析器应该查询的名称服务器的Internet地址，按照RFC 2373，要么是IPv4地址(点符号)，要么是冒号(可能是点符号)的IPv6地址。如果不存在命名服务器条目，默认情况下使用本地机器上的名称服务器。

（指定需要使用的DNS地址）

机制总结：

1. 如果指定多个nameserver字段，默认向一个名称服务器解析，如果查询失败（解析超时、得到REFUSE等错误应答），则顺序尝试下一个名称服务器，直到尝试所有的名称服务器（最大值默认为三个），并达到最大的重试次数。
2. 如果指定多个nameserver字段，最多生效3个nameserver字段，在不同的版本的glibc中生效的MAXNS nameserver不一样，可查阅/usr/include/resolv.h文件进行查看

经过实际查看不同系统/usr/include/resolv.h，相关限制如下：

• Centos6.4（glibc Version:2.12 Release:1.166.el6_7.7）的最大限制为：3
• Centos7.2（glibc Version:2.17 Release:307.el7.1）的最大限制为：3
• Centos8.2（glibcVersion:2.28 Release 151.el8）的最大限制为：3（实际行为测试得出）

配置建议：

nameserver指定的DNS服务器最多不超过三个，且需要保证每个DNS服务器解析稳定。

timeout：

设置本地客户端向另一个DNS服务器发起重试查询之前等待的超时响应时间。

机制总结：

1. 默认值为RES_TIMEOUT(当前为5，参见<resolv.h>)，以秒为单位（值必须为整数）
2. 此选项的值被静默封顶为30
3. 对于第二轮和连续轮查询，解析器将初始超时加倍，并除以resolv.conf文件中的名称服务器数量。

配置建议：

为了能在首要DNS服务器发生故障时，客户端能够及时向另一个DNS服务器发起查询，建议将timeout时间设置为最小值，如下：

timeout：1

search & ndots

search：设置搜索列表，客户端可以通过只搜索关键字，然后系统自动补全所需的域。

ndots：为必须出现在请求的域名名称中的点的数量设置阈值，缺省值是1，此选项的值被静默封顶为15

机制总结：

解析器查询小于ndots(默认值为1)将依次使用搜索路径的每个组件进行尝试，直到找到匹配。

搜索列表目前仅限于六个域，总共256个字符。

最大限制有所不一样，详见红帽官网：https://access.redhat.com/solutions/58028

配置建议：

根据业务需求进行设置，非必要建议不使用。

single-request

该参数主要控制客户端对外查询域名A/AAAA类型时的行为，主要有如下两个参数

• single-request (since glibc 2.10)
• single-request-reopen (since glibc 2.9):

机制总结：

single-request：

• 使glibc按顺序执行IPv6和IPv4域名解析请求
• （即串行发送A类型和AAAA类型域名解析请求）

single-request-reopen：

• 如果来自同一端口的两个请求没有得到正确处理，它将关闭套接字并在发送第二个请求之前打开一个新的套接字。
• 发送A类型请求和AAAA类型请求使用不同的源端口。

glibc在较低版本时，客户端可能会出现使用相同的源ip以及端口对外发起A/AAAA类型的查询，可能会存在如下风险：

1. 客户端内核层面可能会引发某种内核bug导致部分域名A/AAAA的DNS请求被丢掉
2. 网络层面部分防火墙可能会对该种端口复用情况进行特殊处理——丢弃部分域名A/AAAA的DNS请求。

如上两种场景皆可引发客户端异常行为，即：触发Linux-DNS的默认5秒超时机制，再次发送DNS请求才成功收到响应，进而导致业务受到延迟、中断。

配置建议：

在配置文件中，均加上参数：single-request-reopen

参考文档：
A:single-request-reopen参数说明：http://coolnull.com/3820.html
概述：同样源目的ip,同样源目的port，同样的第4层协议的连接会被防火墙看成是同一个会话，因此可能存在返回包被丢弃现象。如下图：

B:kubernetes集群中夺命的5秒DNS延迟：https://tencentcloudcontainerteam.github.io/2018/10/26/DNS-5-seconds-delay/
概述：内核conntrack模块的bug，多个线程或进程并发从同一个socket发送相同五元组的UDP报文时，有一定概率会发生查询请求被丢弃，导致有DNS请求没有到达kube-dns pod，进而触发了Linux默认DNS机制的5秒超时，再次发送DNS请求才成功收到响应。
（为什么是5秒？ man resolv.conf可以看到glibc的resolver的缺省超时时间是5s）