DNS负载均衡在企业内网常失效，因客户端缓存首个IP、忽略TTL且应用默认只用首IP连接；需结合视图划分、短TTL、客户端配合，或降级至L4 VIP、反向代理、Service Mesh实现真实分发。
为什么 DNS 负载均衡在企业内网中常失效
直接用 bind 或 dnsmasq 配置轮询 a 记录，在多数企业内网里根本达不到负载均衡效果。根本原因是：客户端 resolver（比如 windows 的 dnsclient 服务、glibc 的 getaddrinfo()）会缓存首个返回的 ip，且多数不遵守 dns 响应中的 ttl（尤其短 ttl 下），更关键的是——现代浏览器、java 应用、.net sdk 默认只用第一个 ip 连接，失败后才尝试下一个，不会主动分发请求。
真正可用的 DNS 策略组合：视图 + TTL + 客户端配合
必须把 DNS 当作“流量入口调度器”，而非“简单轮询器”。核心是让不同客户端群体拿到**语义上不同但逻辑等价**的地址：
- 按物理位置划分视图：例如
view "shanghai" { match-clients { 10.1.1.0/24; }; }返回app.internal→10.1.1.10；view "beijing" { match-clients { 10.2.1.0/24; }; }返回同一域名 →10.2.1.10 - TTL 设为
30秒以内（dig app.internal +short可验证），避免中间 DNS 缓存长期固化 - 强制客户端禁用本地 DNS 缓存：Windows 执行
ipconfig /flushdns，Linux 上停用systemd-resolved或配置resolve.conf直连内网 DNS 服务器
绕过 DNS 层级的更可靠替代方案
当业务要求真实并发分发（比如 API 网关后多实例）、或客户端不可控（IoT 设备、老旧系统）时，DNS 策略本质是妥协方案。此时应降级到下一层：
- 用
keepalived+ipvsadm在内网 VIP 上做 L4 负载均衡（如10.0.100.100:80→ 后端池），所有客户端直连该 VIP - 部署轻量反向代理（如
nginxwithupstream { hash $remote_addr consistent; }），让 DNS 只解析到这台代理，由它完成真实分发 - 若已用 Service Mesh（如 Istio），直接通过
DestinationRule配置simple: ROUND_ROBIN，DNS 只需解析到网格入口
常见故障排查点
配完 DNS 策略却看到流量全打到一台机器？先检查这几个硬性条件是否满足：
-
named -t /etc/named -g启动时无view 'xxx' matches multiple views报错（顺序和子网重叠是高频坑） - 客户端执行
nslookup app.internal 10.0.1.5（指定内网 DNS IP）结果是否符合预期视图，而非从上游 DNS 缓存中返回旧值 - 抓包确认客户端发出的 DNS 查询是否带 EDNS Client Subnet（ECS）扩展——部分新版
bind依赖它做地理调度，但 Windows 默认不发，需注册表启用EnableEDNSProbing - 应用层连接日志里出现大量
Connection refused却没切到备用 IP？说明客户端未实现重试逻辑，这不是 DNS 问题，是应用健壮性缺陷
DNS 策略能做的只是“首次地址分发”，后续连接稳定性、失败转移、健康探测，它一概不参与。这点经常被忽略。
