内网域名解析服务的高可用，核心在于消除单点故障、实现快速故障切换，并确保解析结果的一致性和低延迟。这不是买两台服务器简单做主备就能解决的事，域名解析一旦出问题，业务系统再健壮也进不了门，下面我从架构设计、配置实操、监控告警三个层面,拆解一套能落地的内网DNS高可用方案。
内网DNS高可用方案的核心矛盾：同步与切换
先想清楚一个场景：办公室几百号人，业务系统依赖api.internal.example.com这个域名，如果只有一台DNS服务器，它宕机了，所有人访问内部系统都会报“找不到服务器”，内网DNS高可用的第一层思考，就是至少两台物理机或虚拟机，组成一个解析集群。
但问题来了，两台机器上各存一份zone文件，如果A机器上改了记录，B机器不知道，解析就会时对时错，这就是内网域名解析高可用方案里最难处理的数据同步问题，行业共识是，优先使用主从架构，由主DNS负责更新，通过NOTIFY和AXFR/IXFR机制把zone变化推送给从DNS，这个机制成熟可靠,不需要额外开发。
搭建高可用内网DNS的三种主流架构
根据企业规模和容灾要求，架构可以分三档,你可以对号入座。
单机房双机热备：最基础的入门配置
适用于百人以下的中小企业，两台DNS服务器，一台master，一台slave，放在同一个机房的同一网段，所有客户端的/etc/resolv.conf里，nameserver指两个内网IP，主服务器故障时，从服务器接管解析，这里要注意：客户端的DNS超时时间默认是5秒，也就是说主DNS挂了，业务访问会卡顿几秒后才切到备用IP,对于非核心系统可以接受。
跨机房双活：解决带宽和容灾问题
人数多、有多个办公地点的公司，通常会在总部和分公司各部署一套DNS，分公司客户端就近指向本地的DNS，本地DNS通过zone transfer从总部同步数据，这种架构下，即使总部网络断了，分公司的内网域名解析依然正常工作，最近几年，很多企业把业务迁到云上，混合云场景下,云上VPC内的DNS和公司机房的DNS之间也需要做这样的双向同步。
基于负载均衡器的DNS集群：适合对延迟极敏感的场景
用Keepalived或云平台的SLB，将多个DNS节点组成一个虚拟IP，客户端只认这个VIP，请求进来后由负载均衡器分发到后端多个BIND或CoreDNS实例，这种内网域名解析高可用架构的优点是：任一节点宕机，客户端完全无感知，因为VIP漂移是秒级的，但配置复杂度也最高，需要处理健康检查、会话保持和缓存一致性。
配置内网DNS高可用的实操要点
下面这套动作，我建议你在测试环境先完整跑一遍，以最常见的BIND 9为例，假设两台机器IP是168.1.10（主）和168.1.11（从），域名为corp.example.com。
主从同步的配置清单
在主服务器的/etc/named.conf中,你需要指定允许哪些从服务器来拉取zone数据：
options {
listen-on port 53 { any; };
allow-transfer { 192.168.1.11; }; # 只允许从服务器传输
also-notify { 192.168.1.11; }; # 主动通知从服务器
allow-query { 192.168.0.0/16; }; # 仅内网网段可查
};
zone "corp.example.com" IN {
type master;
file "master/corp.example.com.zone";
};
从服务器的配置更简单，zone类型改为slave,指定master的IP：
zone "corp.example.com" IN {
type slave;
file "slaves/corp.example.com.zone";
masters { 192.168.1.10; };
};
配置完以后，件别用named-checkconf和named-checkzone检查，然后重启服务，在从服务器上执行rndc retransfer corp.example.com手动触发同步，确认从服务器上能解析corp.example.com，比如用dig @192.168.1.11 cc.corp.example.com，能看到status: NOERROR,说明同步成功。
客户端切换策略：优先用相对IP
搭建好服务端，客户端这侧也要配合，Linux服务器上，/etc/resolv.conf
里写多个nameserver时，要注意顺序很重要，第一个是主解析，第二个是备解析，如果第一个DNS没响应，系统会按顺序往下试，行业实践建议，把同网段、延迟最低的那台DNS放在第一位。
如果你是做桌面办公网络，建议在DHCP服务器中下发多个DNS地址，避免手动改，对于容器化环境，Kubernetes的CoreDNS高可用则不同，它天然是多副本的，通过Service抽象负载均衡，但要注意CoreDNS的存根域配置,防止上游故障影响集群内解析。
故障切换与监控告警：别等用户抱怨才发现
很多团队把DNS搭起来就不管了，这是大忌，DNS属于“基础中的基础”，它挂了，监控系统本身可能也发不出告警，因为监控也要走域名解析，这里有一种常用的“自举监控”思路：监控系统用IP地址直接访问DNS探测接口,不依赖域名本身。
需要监控的三个指标
- 可用性：每隔30秒对每台DNS实例发起一次UDP 53端口探测,连续3次失败即触发告警。
- 解析延迟：统计从发出查询到收到响应的时间，内网DNS的响应通常在10毫秒以内,超过100毫秒就需要排查网络问题。
- zone序列号一致性：主从服务器的zone文件序列号应该一致，用
dig SOA corp.example.com对比返回的serial值,不一致说明同步断了。
自动故障切换的一个妙招
对于Linux服务器，可以写一个简单的脚本来检测默认DNS是否可用，不可用时自动切换/etc/resolv.conf中的nameserver顺序，虽然不如VIP方案优雅，但在纯静态配置的场景下很实用，脚本逻辑很简单：nslookup test.corp.example.com，如果第一个nameserver不响应,就把它挪到列表末尾。
高可用与安全性：防外部干扰的内部防线
内网DNS高可用不仅仅是“不出故障”，还要防“被劫持”，近年来公开的网络安全事件中，DNS劫持导致内网渗透的案例不在少数，一个有效的防护措施是启用
TSIG签名，让主从服务器之间的区域传输通过密钥验证，防止伪造DNS响应的中间人攻击,生成密钥的命令：
tsig-keygen hmac-sha256 dns-transfer-key
写到主从服务器的named.conf中，并在zone配置里使用key "dns-transfer-key";引用，开启DNS解析日志（category queries），可以帮助你及时发现异常的解析请求模式,比如短时间内大量解析某个不在zone中的域名。
常见问题快速排查
遇到“从服务器收不到zone更新”，先查什么？
先确认主服务器上的allow-transfer是否包含从服务器IP，再看从服务器的日志（/var/log/messages或named.run），如果日志提示connection refused，多半是防火墙拦了TCP 53端口，注意：zone传输用的是TCP，不是UDP，很多人只开放了UDP 53,导致传输失败。
内网DNS解析延迟突然变高，怎么回事？
先做一次dig响应时间对比，分别指向主DNS和从DNS，看是否只是某一台有问题，再抓包看是否有大量重传，另一种常见原因是zone文件过大，比如内网域名记录超过了几万条，而服务器没有开启递归限制,导致大量外部递归请求挤占CPU。
多个办公点需要统一管理域名，但又不想暴露总部DNS地址，怎么办？
使用“DHCP按站点分发不同DNS”的方式，每个办公点部署一台只读的从DNS，客户端就近指向它，从DNS不需要对公网开放，只接受内网客户端的查询，即使某个站点到总部的专线断开，本地的从DNS依然能提供历史数据解析,这就是时效性和可用性的折中。
落地的内网DNS高可用方案，没有“最好”，只有“最合适”，小型公司从双机主从做起，中型企业考虑跨机房或负载均衡架构，同时务必把监控告警和TSIG安全机制纳入同等重要的位置，记住一句话：域名解析恢复的速度，决定了业务故障恢复的下限，别让一台老旧的DNS服务器,成为整个内网最脆弱的那个点。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/621048.html
