CoreDNS中实现Split DNS配置的技术解析

前言

在企业网络环境中，Split DNS（分割DNS）是一种常见的需求，它允许根据客户端IP地址返回不同的DNS解析结果。本文将通过一个实际案例，深入分析如何在CoreDNS中正确配置Split DNS功能，并解释其中的关键技术和常见误区。

Split DNS的基本原理

Split DNS的核心思想是根据查询来源的不同返回差异化的DNS记录。典型应用场景包括：

• 内网用户访问内部域名时返回内网IP
• 外网用户访问相同域名时返回公网IP
• 特定部门或区域用户访问特殊资源

初始配置的问题分析

在初始配置中，作者尝试通过两个server块实现Split DNS：

1. 第一个server块(example.com:53)处理所有example.com域名的查询
2. 第二个server块(example.com:5302)包含view插件，期望只对特定IP(10.1.1.1和10.2.2.2)返回特殊记录

然而实际运行中发现，host3.example.com的记录对所有客户端都返回了25.25.25.3，这与预期不符。

问题根源：forward插件的行为特性

关键问题在于对forward插件工作原理的理解不足。当使用forward插件时：

1. 查询从第一个server块转发到第二个server块时
2. 查询的源IP会变为CoreDNS服务器本身的IP(通常是127.0.0.1)
3. 原始客户端的IP信息丢失
4. 导致view插件中的client_ip()判断始终基于本地回环地址

正确的配置方案

修正后的配置将view判断逻辑上移到第一个接收请求的server块：

example.com:53 {
  bind 0.0.0.0
  loadbalance round_robin
  view split-dns {
    expr client_ip() in ["10.1.1.1","10.2.2.2"]
  }
  template IN ANY host3.example.com {
    answer "host3.example.com 60 IN A 25.25.25.3"
  }
  forward example.com 127.0.0.1:5302
  errors
}

example.com:5302 {
  bind lo
  template IN ANY host1.example.com {
    answer "host1.example.com 60 IN A 25.25.25.1"
  }
  template IN ANY host2.example.com {
    answer "host1.example.com 60 IN A 25.25.25.2"
  }
  forward . 127.0.0.1:5301
  errors
}

这种结构调整确保了：

1. 客户端IP信息在最初接收请求时就进行判断
2. 只有符合条件的客户端才会得到host3的特殊记录
3. 其他记录(hos1和host2)保持对所有客户端可用

最佳实践建议

1. IP判断前置：将客户端IP的判断逻辑尽量放在处理链的最前端
2. 明确转发策略：清楚了解forward插件会改变查询源IP的特性
3. 模块化设计：将不同功能的DNS记录处理分离到不同的server块中
4. 测试验证：使用dig等工具从不同源IP测试验证Split DNS效果

总结

CoreDNS作为一款灵活的DNS服务器，通过view和forward等插件的组合，能够实现复杂的Split DNS场景。关键在于理解插件间的工作机制和数据流变化，合理设计配置结构。本文分析的案例展示了如何正确处理客户端IP信息的传递，为类似需求提供了可参考的实现方案。