CoreDNS需手动配置插件链才能正确解析Golang微服务名：Consul环境启用consul插件并指定地址，Etcd环境配etcd插件及路径前缀，禁用kubernetes插件避免冲突；同时须将CoreDNS地址写入容器/etc/resolv.conf首行、监听0.0.0.0:53，并用rewrite或template插件处理环境后缀域名。
CoreDNS 能在 Golang 微服务集群里稳定承担内部 DNS 解析，但直接部署默认配置会踩坑——它默认不自动发现 Kubernetes Service，也不适配非 K8s 环境下的 Consul/Etcd 服务注册，更不会主动监听 127.0.0.1 以外的地址。必须手动配置插件链和上游策略，否则服务间 curl http://user-svc:8080 就会超时失败。
怎么让 CoreDNS 正确解析 Golang 微服务名（如 user-svc）
CoreDNS 默认不感知你的微服务注册中心，得靠插件补全服务发现能力。如果你用的是 Consul，必须启用 consul 插件；用 Etcd 就得配 etcd；纯文件驱动可选 file 或 hosts。Kubernetes 集群外的 Go 微服务几乎不会走 kubernetes 插件，硬加反而导致启动失败或 503 错误。
- Consul 场景：在
Corefile中写consul 127.0.0.1:8500 { }，并确保 Consul ACL token（如有）通过token指令传入 - Etcd 场景：用
etcd /skydns { endpoint http://etcd:2379 }，注意路径前缀要和 Go 服务注册时一致（比如 go-micro 默认用/micro/services/） - 避免混用插件：同时启用
kubernetes和consul会导致查询顺序混乱，fallthrough不生效，查不到就静默返回 NXDOMAIN
为什么 Golang 客户端解析慢或超时
Go runtime 的 DNS 解析器默认使用系统 /etc/resolv.conf，如果 CoreDNS 地址没写进该文件，或写成了 127.0.0.1（容器内不可达），就会 fallback 到公网 DNS，造成延迟甚至解析失败。Golang 还会缓存失败结果（TTL=0 时也缓存 5 秒），加剧问题。
- 容器内必须把 CoreDNS 的 ClusterIP 或宿主机 IP 写进
/etc/resolv.conf的第一行，不能只靠--dns启动参数 - 在 Go 服务中显式设置
GODEBUG=netdns=cgo可绕过 Go 的内置 resolver，改用 libc 解析（支持ndots和 search 补全） - CoreDNS 自身要监听
0.0.0.0:53，不能只绑127.0.0.1；若用 hostNetwork 模式，需确认宿主机防火墙放行 UDP 53
如何让 CoreDNS 支持服务名+环境后缀（如 user-svc.staging）
微服务多环境共用一套 CoreDNS 时，光靠插件查注册中心不够，得靠 template 或 rewrite 插件做域名重写。否则 user-svc.staging 会被当成完整 FQDN 直接查询，而 Consul/Etcd 里只存了 user-svc。
立即学习“go语言免费学习笔记（深入）”；
- 用
rewrite stop type A user-svc.staging user-svc把带后缀的请求转成无后缀再查 - 更灵活的做法是配合
template：定义template IN A user-svc\.([a-z]+)\.local { ... }，从正则捕获环境名，再拼接 etcd key 路径 - 务必在
forward插件前放置rewrite或template，否则重写不生效；log插件建议打开，方便确认重写是否命中
真正麻烦的不是部署 CoreDNS，而是让每个 Golang 服务进程正确读取并信任它——Docker 的 --dns 对 multi-stage 构建无效，Kubernetes 的 dnsConfig 在 initContainer 里不生效，而 Go 的 net.DefaultResolver 又无法运行时热更新。这些边界情况，比配 Corefile 更容易漏掉。
