CoreDNS的hosts模块的一个配置问题卡了2天
Kuberentes 环境中 CoreDNS 是一个基础服务，他提供外部域名、Service名称、POD名称等资源的 DNS 解析功能。CoreDNS 可以通过插件来进行功能扩展，但是如果对插件配置使用不当，可能会引起整个集群的故障。
问题背景
问题背景是在一次 argocd 服务的部署场景中，安装完后总是提示 argocd-redis 连接不上，服务名无法解析。而 argocd-redis 就是和 argocd helmchart 一起部署的一个组件，并在同一个 Namespace 中。
# kubectl -n argocd logs -f argocd-server-56748df646-cmnjv
......
redis: 2026/09/09 03:08:04 pool.go:715: redis: connection pool: failed to dial after 5 attempts: dial tcp: lookup argocd-redis on 10.43.0.10:53: server misbehaving
time="2026-09-09T03:08:04Z" level=warning msg="Reconnect to redis because error: \"dial tcp: lookup argocd-redis on 10.43.0.10:53: server misbehaving\""
根据错误提示，问题方向应该是 argocd 服务访问 CoreDNS 网络异常，或者 CoreDNS 本身异常。
分析阶段
首先分析的 CoreDNS 本身是否异常，我尝试使用 CoreDNS 的 ClusterIP 作为 DNS 服务器解析我配置的一条 hosts 静态解析，发现 CoreDNS 解析功能正常。
[root@openeuler100 ~]# dig -q registry-local.cncfstack.com @10.43.0.10 +short
192.168.1.100
这时还没有意识到问题就在这里，并且没有对 Kubernetes Service 域名进行解析。
之后查看 CoreDNS 的日志，也没有异常
[root@openeuler100 ~]# kubectl -n kube-system logs rke2-coredns-rke2-coredns-659b8fb74b-mjbvn
maxprocs: Updating GOMAXPROCS=1: using minimum allowed GOMAXPROCS
.:53
[INFO] plugin/reload: Running configuration SHA512 = 8ddb920c44cdb2ea9739bb839367dce3c606218288682d235afb136b108331bf3e841310cd49aa1180936b6da52f1e9b46f5c0cfc3dcf42250394ffbed16ffcc
CoreDNS-1.14.6
linux/amd64, go1.25.12 X:boringcrypto, 424d12577
然后就去分析网络问题，验证路由是否正确、分析 Iptables、NetworkManager 影响， 分析 NetworkPolicy 影响等等，还是没有找到问题原因。
就在一天中午吃完饭，打开一局 LOL 时，突然想到之前使用 CoreDNS hosts 模块时好像有插件顺序和 fallthrough 配置要求，真的是突然意识到的。
根因确定
意识到 CoreDNS 插件有顺序要求时，立马看下了 Corefile 的配置文件
[root@openeuler100 ~]# kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o yaml
apiVersion: v1
data:
Corefile: |-
.:53 {
errors
health {
lameduck 10s
}
hosts {
192.168.1.100 registry-local.cncfstack.com
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus 0.0.0.0:9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
kind: ConfigMap
果然，hosts 插件在 kubernetes 上面。这是我才想起来验证 Service 域名解析的问题
argocd-redis 的服务运行正常，日志没有报错，但就是无法解析
[root@openeuler100 ~]# dig argocd-redis.argocd.cluster.local @10.43.0.10
; <<>> DiG 9.20.21 <<>> argocd-redis.argocd.cluster.local @10.43.0.10
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36787
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: af2575f3f760bae5 (echoed)
;; QUESTION SECTION:
;argocd-redis.argocd.cluster.local. IN A
;; Query time: 0 msec
;; SERVER: 10.43.0.10#53(10.43.0.10) (UDP)
;; WHEN: Wed Sep 09 11:04:38 CST 2026
;; MSG SIZE rcvd: 74
我就尝试注释掉 hosts 模块的配置，之后发现 service 域名解析正常，那这基本确认就是 hosts 模块引起的。
结合之前的经验， CoreDNS 由一系列插件组成，这些插件按顺序形成一条处理链， 默认从配置文件上到下依次执行插件。下面有 kubernetes 配置呀，为什么无法解析 Service 域名呢？
这是因为 hosts 插件缺少 fallthrough 配置导致的。当 hosts 插件无法找到某个域名的匹配记录时，如果没有配置 fallthrough 就是返回解析失败，但是如果配置了fallthrough就会把这次查询传递给链中的下一个插件（例如 kubernetes 插件，或者 forward 插件）继续解析。
解决方法
找到问题的原因，解决方法就简单了。hosts 是我专门添加用来解析自定义域名的，所以 hosts 插件需要保留。
那就给hosts插件添加fallthrough配置，为了防止以后手动修改hosts出现啥问题，我还将 hosts模块放在 Kubernetes 模块后面。
[root@openeuler100 ~]# kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o yaml
apiVersion: v1
data:
Corefile: |-
.:53 {
errors
health {
lameduck 10s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
hosts {
192.168.1.100 registry-local.cncfstack.com
fallthrough
}
prometheus 0.0.0.0:9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
kind: ConfigMap
之后在验证，自定义域名、Kubernets Service服务名、外部域名解析都正常。argocd 的服务也正常了，问题算是解决好了。
总结
这次遇到的问题处理的效率有点低，从事后来看这个问题本来是我早就知道的技术点 CoreDNS的插件有顺序要求，hosts需要fallthrough配置，结果还要靠 顿悟。
按照之前不使用AI辅助的习惯，这种问题的分析思路应该是：
- argocd-server 日志明确提示 argocd-redis 服务名无法解析，在 argocd-server 验证其他域名是否可以正常解析，比如
registry-local.cncfstack.com可以解析，但kubernetes.default.svc.cluster.local无法解析。结论：CoreDNS Servcie 域名解析异常。 - 查看 CoreDNS 日志，日志没有报错。查看 Corefile 配置文件，发现与默认配置项目多了 hosts 插件配置。
- 查看 CoreDNS hosts插件官网文档 ，就会在插件介绍的最前面有句话
If you want to pass the request to the rest of the plugin chain if there is no match in the hosts plugin, you must specify the fallthrough option.
这次是和 DeepSeek 一起分析的，我提供了背景、日志、配置等信息，它也提供了很多验证方法，但并没有准确找到问题点，反而浪费了大量的时间。
反思：思想懒惰，强依赖AI帮我分析。
另外开源项目最靠谱的资料还是源码和官网，你有多久没有访问开源项目的官网了？