彻底弄懂系列之一pod的dns解析

问题背景：

前段时间遇到了一个DNS解析的奇怪问题，在同一个集群，同一个节点上，解析同一个域名，有的pod可以，有的pod不可以，另外生产环境出现了一个case，解析一些国外的域名同样出错，结合这两个问题，彻底梳理清楚pod中dns解析的流程及细节

问题调研：进入pod至执行nslookup,可以解析的代码：

bash-5.1# nslookup mail11.xxx.com
Server:         192.168.64.10
Address:        192.168.64.10#53

Non-authoritative answer:
mail11.xxx.com.ciam-prod.svc.cluster.local     canonical name = mail11.xxx.com.
Name:   mail11.xxx.com
Address: 192.71.68.x
Name:   mail11.xxx.com
Address: 192.71.68.x
Name:   mail11.xxx.com
Address: 192.71.69.x
Name:   mail11.xxx.com
Address: 192.71.69.x
** server can't find mail11.xxx.com: NXDOMAIN

不可以解析的直接就是：

nslookup mail11.xx.com
Server:         192.168.64.10
Address:        192.168.64.10:53

** server can't find mail11.xx.com: NXDOMAIN

*** Can't find mail11.xx.com: No answer

但是虽然能解析，其实返回的也是非权威answer，其实pod的dns解析流程大概是：

K8S Pod DNS解析：
(1) pingwww.baidu.com -> Pod的容器里 local DNS cache(一般情况下容器镜像不会安装Linux nscd服务，这里跳过) ->

(2) Pod的容器里/etc/hosts文件->

例如：测试Pod对应容器里的 /etc/hosts

(3) CoreDNS(Pod的容器里/etc/resolv.conf中记录的nameserver（一般这里Pod dnsPolicy策略默认设置的是ClusterFirst，所以该nameserver为CoreDNS的Cluster IP） )->

例如：测试Pod对应容器里的 /etc/resolv.conf, 这里的10.0.248.10为CoreDNS的Cluster IP

下图是对应CoreDNS的Service信息：

(4) CoreDNS Cache（CoreDNS cache插件，该插件会缓存已经查询过的DNS解析的信息，见下图的cache字段）->

.:53 {
      autopath @kubernetes
      cache 30
      errors
      forward . /etc/resolv.conf
      health
      kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods verified
        fallthrough in-addr.arpa ip6.arpa
      }
      loadbalance
      loop
      prometheus :9153
      ready
      reload
    }

(5) 如果CoreDNS没查到(一般只提供了kubernetes集群内的部域名的解析，具体是CoreDNS kubernetes插件)，那么CoreDNS可以通过forward（内置，见上图中的forward字段）或proxy插件（第三方单独提供）转发给上游DNS Server。

当然，forward插件可配置查找当前容器内的/etc/resolv.conf文件的nameserver（配置可写为：forward . /etc/resolv.conf），注意CoreDNS的Pod dnsPolicy策略为Default，所以/etc/resolv.conf文件内容与node节点保持一致，如下：

问题原因：

原因就出现在coredns 的配置autopath @kubernetes这句话， 这句话的官方解释：

f the autopath plugin sees a query that matches the first element of the configured search path, it will follow the chain of search path elements and return the first reply that is not NXDOMAIN. On any failures, the original reply is returned. Because autopath returns a reply for a name that wasn’t the original question, it will add a CNAME that points from the original name (with the search path element in it) to the name of this answer.

Note: There are several known issues, see the “Bugs” section below.

简单理解就是当我们直接用svc名字在集群内部访问某个服务时，这个机制会帮助我们补全一些域名，例如加上.svc.cluster.local,这个配置是和pod里的etc/resolv.conf的某个配置配合使用的：

bash-5.1# cat resolv.conf 
nameserver 192.168.64.10
search xxx-prod.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

这里面的ndots其实限制的是.的数量，默认是5，但其实这个5还是有点大的，一般建议设为1，

就是域名的.数量小于5，就会补全域名后缀后查找，大于等于5直接查找，而且最后查找的才是什么后缀都没有的本来域名，所以可能一个外部域名需要第七次或者第八次才能解析成功，顺序像：

第一次解析：xxxx.redis.rds.aliyuncs.com.default.svc.cluster.local A

第二次解析：xxxx.redis.rds.aliyuncs.com.default.svc.cluster.local AAAA

第三次解析：xxxx.redis.rds.aliyuncs.com.svc.cluster.local A

第四次解析：xxxx.redis.rds.aliyuncs.com.svc.cluster.local AAAA

第五次解析：xxxx.redis.rds.aliyuncs.com.cluster.local A

第六次解析：xxxx.redis.rds.aliyuncs.com.cluster.local AAAA

第七次解析：xxxx.redis.rds.aliyuncs.com.zhenguanyu.com A

第八次解析：xxxx.redis.rds.aliyuncs.com.zhenguanyu.com AAAA

第九次解析：xxxx.redis.rds.aliyuncs.com. A

第十次解析：xxxx.redis.rds.aliyuncs.com. AAAA

能解析的pod在nslookup域名时，被后面补充上了后缀，导致它match上了cordns里的默认解析路径，就是.:53后面的配置，这个配置forward到的其实是pod所在节点的resolv.conf的nameserver，而这个nameserver一般是固定的，比如阿里云就会在他的ecs里面加上阿里云自己的dns服务器的地址，而恰巧我们要解析的域名在这上面有记录，所以就有返回值了，但其实它是不准确的，因为它没有去我们指定的nameserver，而解析失败的pod里面的nslookup版本和能解析的也是不一样的，本身镜像也不一样，所以导致有的补全，有的不补全，进而导致了虽然解析相同域名，但是匹配到了不同的nameserver

问题总结：

其实我们的测试也是有问题的，通过nslookup xx.com nameserver可以指定dns服务器去解析，这个命令没有返回值说明我们的dns服务器就没有这条记录，另外可能的是集群和指定的dns服务器网络不通，所以说解析不了是正常的，能解析是有问题的，再有就是dig命令其实每次都会从origin nameserver 返回记录，所以比nslookup更权威，建议coredns配置里面去掉autopath @kubernetes这个配置,最后一点是如果集群里有一些解析频繁的外部域名，且这些域名本身解析变化不频繁，会用到集群外的dns服务器，建议配合一些手段如NodeLocal DNSCache，private zone（阿里云vpc内dns解析服务）进行适当缓存