Linux服务器如何配置内网DNS转发解决跨机房域名解析问题-LINUX-PHP中文网

named转发不生效的首要原因是转发器被忽略：bind仅在无法权威回答且无根提示时才启用forwarders，若配置了root hints或zone "."则优先递归；需确认使用forward only、禁用hint、验证连通性并检查日志。

linux服务器如何配置内网dns转发解决跨机房域名解析问题

为什么 `named` 转发不生效？先确认转发器是否被忽略

Linux 服务器上用 named（BIND）做内网 DNS 转发时，最常见问题是配置写了但请求根本没发出去。根本原因通常是：BIND 默认对 forwarders 的使用有严格前提——只有当本机无法权威回答（即不是该 zone 的主/从服务器，且缓存中无记录）时，才会走转发；如果配置了 root hints 或本地有残余 zone "."，它会优先递归而非转发。

实操建议：

检查 /etc/named.conf 中全局 options 块是否包含 forward only;（不是 forward first;），否则 fallback 到递归可能绕过你的内网转发器
确认没有定义 zone "." { type hint; file "named.ca"; }; —— 这会让 BIND 自行递归，无视 forwarders
用 dig @localhost example.com +trace 看实际路径；若第一跳就去 198.41.0.4（根服务器），说明转发未触发
转发目标必须是可达的 UDP/TCP 53 端口，建议用 nc -uz 53 验证连通性

如何让不同机房域名走不同转发器？用 `view` + `match-clients` 隔离策略

跨机房场景下，A 机房要查 B 机房的内部域名（如 svc-b.internal），B 机房查 A 机房的（如 svc-a.internal），不能全扔给同一个上游。BIND 的 view 是唯一可靠解法，靠客户端 IP 匹配决定走哪组 forwarders。

实操建议：

每个 view 必须有唯一名称（如 view "dc-a"），且 match-clients 要写具体网段，避免用 any 导致策略错乱
forwarders 列表里放的是目标机房 DNS 服务器 IP，不是公网 DNS；多个 IP 用分号隔开，如 forwarders { 10.20.30.10; 10.20.30.11; };
所有 view 必须覆盖全部查询来源，否则未匹配的请求会被静默丢弃（日志里出现 client @0x...: query (cache) 'xxx' denied）
务必在每个 view 内显式声明 recursion no; 和 allow-query { ... };，否则可能被误当成开放递归服务器

`rndc reconfig` 后解析延迟高？检查 `max-cache-size` 和 `max-acache-size`

配置完转发并重载后，首次解析慢、后续又快，或者随机超时，大概率是缓存参数不合理。BIND 9.11+ 默认启用 acache（answer cache），但若内存限制太小，会频繁淘汰转发结果，导致重复发起上游查询。

实操建议：

在 options 或各 view 内设置 max-cache-size 256m; 和 max-acache-size 128m;（根据服务器内存调整，不低于 128MB）
用 rndc stats 查看 Cache size 和 ACache size 实际占用，若长期接近上限，需调大
避免在 view 级别设过小的 max-cache-ttl（如 30s），这会让转发结果很快失效，失去缓存意义
确认 /var/named/data 目录可写，否则 cache 文件无法持久化，重启后全量重建

转发失败时日志只显示 `query refused`？打开 `querylog` 和详细类别

默认日志几乎不记录转发过程细节，query refused 这类错误根本看不出是本地拒绝、上游拒绝，还是超时。必须手动开启细粒度日志才能定位。

实操建议：

在 named.conf 的 logging 部分添加：

channel query_log { file "/var/log/named/query.log" size 100m; severity info; print-time yes; }; category queries { query_log; };

同时启用转发调试：

category resolver { default_syslog; }; category lame-servers { null; };

避免日志被无用信息刷屏

关键线索看日志里的 forwarding 字样（表示已发往转发器）和 no valid response（表示上游无响应或拒绝）
若日志显示 forwarding to ... timed out，优先排查防火墙、MTU（尤其跨云厂商）、以及上游 DNS 是否真在监听 53 端口（ss -tuln | grep :53）