k8s pod dns 问题记录

突然收到，反馈，一个服务短信验证码，验证很慢。第一反应是网络问题。

默认pod生成的dns 解析配置文件是如下:

由于pod 使用的是，alpine:latest

采用 apk add --update tcpdump 安装

抓包查看dns 解析过程，抓取所有网络包： tcpdump -nnvXSs 0 -i any

以下摘自网络：

/etc/resolv.conf的关键字主要有四个，分别是：

nameserver #定义DNS服务器的IP地址其中最终要的就是nameserver，其他都是可选的，可以配置多个，在查询时，按照nameserver在本文中的次序进行，当第一个dns没有反应时，才查询第二个

domain #定义本地域名

声明主机的域名。很多程序用到它，如邮件体系；当为沒有域名的主机进行DNS查询时，也要用到。如果沒有域名，主机名将被使用，删除所有在第一个点( . )前面的內容。

search #定义域名的搜索列表

它的多个参数指明域名查询次序。当要查询沒有域名的主机，主机将在由search声明的域中分离查找。domain和search不能共存；如果同时存在，后面呈现的将会被使用。

sortlist #对返回的域名进行排序

允许将得到域名进行特定的排序。它的参数为网络/掩码对，许可任意的排列次序。

options 以下选项允许你对某些解析变量进行修改，语法类似：options xxx ...，其中xxx可以是如下选项：

debug sets RES_DEBUG in _res.options.

ndots:n sets a threshold for the number of dots which must appear in a name given to res_query(3) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15. 这一段看的脑残了.... timeout:n 解析器在查询远程name server时的超时时间，默认是5秒。 attempts:n 设置解析器在查询name server失败几次后放弃该name server，默认上限是5。 rotate 这会导致在查询时循环选择nameserver中列出的服务器，从而负载均衡所有的nameserver，而不是让所有的客户端尝试第一个列出的服务器 no-check-names 禁止现代BIND检查输入的主机名和电子邮件中的无效字符 edns0 (since glibc 2.6) 使支持RFC 2671Z中的dns扩展 single-request (since glibc 2.10) 自从版本2.9之后，glibc在执行查找IPV4和IPV6时是并行执行的，但是一些DNS服务器不能很好的处理这种情况，并显示请求超时，次选项禁止glibc的并行查找，从而执行顺序查找 domain和search关键字是互相排斥的，如果同时设置了这两个关键字，则最后设置的生效。resolv.conf文件中的search关键字的值可以被LOCALDOMAIN环境变量锁改变， options关键字则可以被环境变量RES_OPTIONS所改变。

现象解析： 关键字`search'与`options ndots:${n}'配合工作，指示resolver在解析域名的时候是否要在用户传入的名称后面添加域名信息，以及添加什么信息。详细规则如下： 1. 如果用户传入的域名是`绝对'域名，即域名以`.'结尾（如上面的 www.baidu .）,则查询的仅是该域名。 2. 如果传入的域名是`相对'域名，且该域名中包含的`.'的数目大于或等于option ndots:${n}命令指定的数,则查询的仅是该域名。 3. 如果不是绝对域名，且传入的域名包含的`.'的数目少于option ndots:${n}命令指定的数，则resolver会依次往传入的域名后追加search列表中的后缀，直到解析出ip地址，或者解析完列表中所有后缀才会停止。 搜索列表利弊？ 由上分析可见，如果search列表较长并且查询了不存在的域名的话，网络上的dns查询报文量会急剧增加，并且可能引发dos攻击。但是搜索列表的一个好处是对于一些常用的域，我们只要输入主机名就可以了，不用每次都输入后面的域名，这在有些时候是挺简洁的（比如在内网中经常要访问不同的机器，search列表便可省很多事）

https://jimmysong.io/posts/configuring-kubernetes-kube-dns/