VPN 环境下的 BIND：条件转发还是 stub 区域？

通过 VPN 解析一个私有区域的三种方式及各自适用场景：forward、stub 或 secondary，以及决定选择的上游源地址检查。

你的办公解析器对所有域名都有答案，只有一个企业命名空间例外，而了解它的企业 DNS 服务器位于 VPN 的另一端。BIND 可以用三种不同方式把这一个区域交给上游，而它们的失败方式各不相同。条件转发是承诺最小的做法，stub 区域保留委派数据，secondary 保留完整副本。选择依据应是上游允许什么、你希望解析器保存什么，而不是你最先搜到哪段配置。

同一个命名空间的三种安排

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

条件转发：承诺最小的做法

假设办公解析器在 192.168.10.53，企业服务器在 10.40.0.53，且可通过已批准的隧道访问。声明只有三行，有意思的是 forward only，因为它改变的是失败时的行为，而不是路径。

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

加上 forward only 后，上游不可达时该区域会返回 SERVFAIL，而不是回落到迭代解析。对私有命名空间来说这通常正是你想要的，因为回落会把私有名字发给公共解析器，从互联网带回毫无用处的答案。 BIND 参考文档 说明了这两种策略，其中的差别比片段暗示的更重要。请把该区域并入现有配置，而不是替换同名区域已有的定义。

stub 还是 secondary：什么时候委派才重要

stub 区域先向企业服务器查询该区域的 NS 记录，然后直接查询权威服务器。当上游区域很大或进一步细分，而你希望解析器跟随委派而不是把一切钉在一个地址上时，就选它。代价是依赖 NS 数据保持最新，并且依赖列出的每台名称服务器都能从解析器的源地址访问到。

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

secondary 从本地数据应答，能扛住上游故障，这正是接受传输依赖的理由。这也意味着解析器现在持有一份自己并不拥有的区域副本，因此文件路径、主服务器上的传输 ACL 以及刷新定时器都成了你运维面的一部分。

在两者之间做决定的那项检查

BIND 会自己生成出站查询，所以问题不是笔记本能否到达 10.40.0.53，而是解析器主机能否以企业服务器将看到的源地址到达它。先问内核，再问服务器，顺序不能反。

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

在路径上同时放行 UDP 和 TCP：被截断的响应会强制改用 TCP，而只放行 UDP 的策略会造成间歇性失败，看起来像丢包。企业侧既需要一条针对解析器源地址的放行规则，也需要一条返回该地址的路由；这个源地址可能是解析器的路由地址，也可能是显式转换后的地址，很少是客户端地址池中的地址。如果 NS 查询失败，那么无论 forward 区域行为如何，stub 区域都无法工作。

验证答案，而不是隧道

通过办公解析器查询一个你从未查过的名字，并检查响应的 authority 部分，判断它是否来自企业区域。缓存中的答案无法证明当前路径，直接向上游查询成功也不能证明解析器选用了那个区域。用 TCP 重复同一个查询，确认路径能承受截断。

让客户端始终指向办公解析器，并保持 DNSSEC 验证开启。配置了独立加密解析器的浏览器会完全绕开这套安排，而为了让意外答案看起来正确去关闭验证，只是把看得见的失败换成了看不见的失败。

把三种类型中你选了哪一种、为什么写下来。下一个看到区域故障的人，需要的正是那句话，而不是配置文件。

相关文章