CoreDNS配置详解：forward、cache、rewrite插件最佳实践指南

在Kubernetes集群里，DNS解析是服务发现的核心支撑，而作为K8s默认DNS组件的CoreDNS，它的配置直接决定了整个集群的网络通信效率。但不少开发者在日常使用中往往只沿用默认配置，对forward、cache、rewrite这三个核心插件的深度优化并不了解。

之前一次生产环境的故障排查，让我切实意识到CoreDNS配置的重要性。当时集群里多个微服务之间频繁出现连接超时，一开始我们都以为是网络链路出了问题，层层排查下来才发现根源是DNS解析延迟过高。调整CoreDNS的cache配置之后，平均解析时间直接从300ms降到了30ms，问题立刻就解决了。

forward插件：外部域名解析优化

forward插件的作用是把集群内无法解析的域名转发到外部DNS服务器。默认配置虽然能正常运行，但放到生产环境里往往需要更精细的调整。

典型配置问题：不少团队会直接沿用默认的8.8.8.8或者114.114.114.114作为上游DNS，却忽略了不同网络环境下的延迟差异和解析策略的适配性。如果是混合云或者多数据中心的部署场景，最好根据节点的地理位置选择最近的DNS服务器作为上游，能有效降低解析延迟。

优化后的forward配置参考如下：

css 复制代码

.:53 {
    forward . 10.0.0.10 10.0.0.11 {
        max_concurrent 1000
        health_check 5s
        policy sequential
    }
    cache 30
    reload 10s
    loadbalance round_robin
}

关键参数解析 ： - max_concurrent：控制并发查询的上限，避免请求量过高压垮上游DNS - health_check：定期对上游服务器做健康检查，自动剔除故障节点 - policy sequential：按照配置顺序依次尝试上游服务器，而非随机选择 - loadbalance round_robin：多台上游服务器之间采用轮询策略实现负载均衡

cache插件：性能提升的关键

cache插件通过缓存DNS查询结果大幅提升解析效率，但缓存策略不能一概而论，需要结合业务实际特点调整。

缓存时间设置：TTL（生存时间）设置是核心：如果TTL太短，会导致频繁向上游DNS发起查询，反而拉高延迟；如果TTL太长，又可能无法及时同步域名变更信息。一般来说，内部服务域名可以设置较长的缓存时间，外部域名则建议优先遵循域名本身的TTL设置。

nginx 复制代码

cache {
    success 9984 30
    denial 9984 5
    prefetch 10 60s 10%
}

缓存分层策略 ： - success：针对查询成功的记录设置缓存，第一个参数是最大缓存条数，第二个是默认缓存时长（单位为秒） - denial：针对查询失败的记录设置缓存，避免重复查询不存在的域名浪费资源 - prefetch：预取机制，在缓存过期前主动刷新记录

预取机制的优势：当某条记录的缓存命中率达到10%且剩余TTL小于60秒时，系统会自动预取最新的记录，用户完全感知不到缓存过期的过程。

rewrite插件：域名重写与规范化

rewrite插件支持在查询流程中修改域名，在多环境部署、域名迁移这类场景下非常实用。

常见使用场景： 1. 把旧域名重定向到新域名，实现平滑迁移 2. 给测试环境的域名自动添加特定后缀，简化访问配置 3. 统一不同服务的域名格式，降低运维管理成本

cs 复制代码

rewrite stop {
    name regex (.*)\.old-domain\.com {1}.new-domain.com
    answer name (.*)\.new-domain\.com {1}.old-domain.com
}

双向重写机制：上面的配置用了双向重写逻辑：不仅会把用户查询的old-domain重写为new-domain发起请求，还会在返回结果时把new-domain重写回old-domain，保证客户端看到的始终是自己请求的原始域名。

多规则组合 ：rewrite支持多规则按顺序执行，可以通过continue或stop参数控制执行流程：匹配到stop标记的规则后就不再执行后续规则，continue则会继续匹配后面的规则。

综合配置最佳实践

在实际生产环境中，三个插件需要配合使用才能发挥最大效用。下面是经过线上验证的完整优化配置示例：

bash 复制代码

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    # 内部域名直接查询
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
    }
    # 重写规则
    rewrite stop {
        name regex (.*)\.test\.company\.com {1}.test.company.com.svc.cluster.local
    }
    # 缓存配置
    cache {
        success 9984 3600
        denial 9984 300
        prefetch 5 120s 20%
    }
    # 外部域名转发
    forward . /etc/resolv.conf {
        max_concurrent 1000
        health_check 10s
        policy sequential
        expire 10s
    }
    prometheus :9153
    reload 15s
}

监控与调优：配置上线后还要做好持续监控和迭代：通过Prometheus暴露的9153端口可以采集CoreDNS的各项运行指标，重点关注查询成功率、缓存命中率、平均响应时间这几个核心指标。定期分析这些数据，结合业务迭代、网络环境的变化及时调整配置参数。

结语

CoreDNS的配置优化不是一劳永逸的工作，需要随着业务发展持续调整。forward插件决定了外部域名解析的稳定性，cache插件直接影响整体解析性能，rewrite插件则为域名管理提供了极高的灵活性，三者缺一不可。

你在日常使用CoreDNS的过程中遇到过哪些配置踩坑的经历？或者有什么独家的优化经验？欢迎在评论区和大家交流分享。欢迎关注我的小绿书《老卢聊运维》