递归不可用：这是 DNS 策略，不是隧道故障

内部名称能够解析，而同一台服务器对外部名称则以拒绝递归作答。这种组合并不矛盾。发布自己的区域与解析整个互联网是服务器可以提供的两项独立服务，服务器能做前一件而不做后一件。把拒绝当作策略声明，然后核对策略是否与设计相符。

拒绝与超时是两种不同的答复

记录名称、查询类型、应答服务器、状态以及返回的记录。递归警告不会自动使随它到达的权威答复失效。先写下状态，再作解释。一小时后凭记忆重建的状态是另一回事。

DNS 报文首部携带递归请求以及服务器是否提供递归的指示，而协议规范把这些标志与答复数据分开。正因如此，一个答复可以既实用又带着抱怨。超时、否定答复与拒绝是三种不同结果。它们各自指向不同层次，只有拒绝是服务器在向你说明策略。

先读状态码，再判断这条警告对本次查询是否重要。指出区域名称的权威答复，即使递归位被拒绝也可使用。没有答复的拒绝是策略结果，不是数据包路径故障。

解析器把你的来源记成了什么

客户端可能来自服务器允许的递归范围之外的地址池，也可能经过转换后看起来像网关。客户端自己的网卡地址并不能证明解析器收到了什么。去问服务器管理员实际观测到的来源，而不是从你这一侧推测。每经过一次转换，两个地址就可能不同。

从客户端和服务器已经信任的主机分别查询同一个名称。两个答复之间的差异就是来源条件，它比任何单个答复都有用。

dig +short host.corp.example
dig +short example.com

如果部署希望为 VPN 客户端提供递归，管理员应通过服务器自身的控制来授权相应的来源范围。为了让一个测试通过而向所有网络开放递归，其改动远大于正在测试的那一项。把授权范围写在规则旁边，因为下一位评审会问这条策略原本要服务哪些来源。没有归属人的来源范围，正是临时测试变成永久配置的方式。

分离式 DNS 是一种设计，不是故障

有些部署只把工作域送到私有解析器，其余全部送到另一台经批准的解析器。这是查询路由的设计，并不能证明私有服务器需要更宽松的策略。在该设计下，外部名称经私有解析器失败是预期结果，而非故障。拒绝正说明设计在生效，不是需要压制的症状。

公共解析器可以恢复浏览，同时却破坏内部名称，或把私有查询送到不该去的地方。改动任何解析器地址之前，先把预期行为写下来。

用两次查询验证策略

按预期修正后，从真实客户端分别查询一个允许的私有名称和一个外部名称。返回的应当是策略承诺的结果，而不只是更安静的诊断。记录每次答复的应答服务器，然后把这一对结果与策略对照。这个对照才是测试，单次成功查询不是。

resolvectl query host.corp.example
resolvectl query example.com

如果私有名称可用而公共名称被拒绝，说明策略正按它所说的执行。如果私有名称也失败，问题就在区域、路由或来源授权上，递归只是干扰项。两种结果都有用，各自排除剩余假设的一半。

把拒绝当作证据来读

拒绝是一种答复。它意味着服务器收到了查询并拒绝执行所请求的工作，这与从未到达的数据包不同。这一区别就是全部诊断。把它记录为答复，而不是连通性故障。

这一区别告诉你该去哪里看：服务器日志、它的访问策略以及它记录的来源。改防火墙不能修好策略拒绝，改策略也不能修好缺失的路由。在有证据之前，让两个假设保持分开。

把结果和策略负责人写进工单，让下一个人从决定出发，而不是从警告出发。写明被授权的来源范围和你测试的两个名称。带着这三项事实的工单可以重跑；只写“递归坏了”的工单不能。