Kubernetes CoreDNS 自定义域名解析

作者：Linux性能技术栈

核心思路： 不要把 DNS 当成零碎配置，而是当成集群流量治理的一部分。CoreDNS 把"域名该怎么被解析"变成一套集中、可审计、可回滚的规则。

零、CoreDNS 角色：插件链就是策略链

CoreDNS 是 Kubernetes 默认集群 DNS，通过 Corefile 组织插件，每个请求按插件顺序处理。

顺序决定行为。 比如 rewrite 写在 kubernetes 前面还是后面，结果完全不同。把 Corefile 当成策略链而不是配置文件。

一、场景一：自定义 Hosts（固定映射）

需求： 集群外固定服务（如 Harbor）用统一域名访问。

hosts {
    172.16.29.203 harbor.idcsec.com
    fallthrough
}

经验点：

• hosts 简单直观，类似 /etc/hosts，适合少量固定映射
• fallthrough 一定要加 — 没命中继续后续插件，否则查询被截断
• 条目增多时升级为企业 DNS 统一管理，避免 Corefile 变成"大字典"

❌ 不要在 Pod 里手工改 hosts — 短期快长期是雷。

二、场景二：Rewrite Service 别名

需求： 用户访问 example.com，内部转到 example.default.svc.cluster.local。

rewrite name example.com example.default.svc.cluster.local

经验点：

• 对外名称稳定、内部服务可演进
• ⚠️ rewrite 只改查询名，不保证网络可达 — Service 端口、NetworkPolicy、后端 Pod 健康需单独确认

三、场景三：存根域（按后缀分流）

需求： 公司内网域名（*.idcsec.com）由内网 DNS（10.10.0.10）解析。

idcsec.com:53 {
    errors
    cache 30
    forward . 10.10.0.10
    prefer_udp
}

经验点：

• "按后缀分流"，只影响匹配域名，不污染全部查询
• 建议至少配置两个上游，避免单点
• 上游 DNS 有 ACL 限制时，提前确认 CoreDNS Pod 网段被放行

四、场景四：统一上游 DNS

需求： 合规或统一审计，非集群域名全部通过企业 DNS。

forward . 10.10.0.10 10.10.0.20 {
    prefer_udp
}

经验点：

• ⚠️ 全集群影响级别，必须灰度
• 上游 DNS 必须能递归或继续转发公共域名，否则大面积解析失败
• 不建议通过改节点 /etc/resolv.conf 来"曲线救国" — 把问题转移到更难管控的层

五、场景五：拦截 AAAA（减少 IPv6 噪音）

需求： 业务明确不使用 IPv6，降低 AAAA 查询。

template IN AAAA .

经验点：

• 前提必须明确：当前业务和网络栈不依赖 IPv6
• 双栈环境贸然启用会把问题"优化"出来

六、变更三件套：生效 → 验证 → 回滚

排障参考：k8s-service-access-troubleshooting（DNS 是十步工作流的关键环节）

关联页面