在系统日志中绑定 FORMERR 错误

Question 1

如果您怀疑网络元素（例如路由器）正在截断或破坏 UDP DNS 流量，您可以尝试以下操作：

再次使用 dig 执行相同的查询，看看是否也会得到 FORMERR 作为响应代码。Dig（使用正确的选项）的执行方式与递归服务器类似，但可以让您更清楚地了解该过程。
如果您使用 dig 收到 FORMERR，请尝试 dig +tcp 并查看错误是否仍然存在（以排除 UDP 问题）
使用 Wireshark 或其他嗅探器来捕获服务器在递归满足查询时实际接收的内容。

您的日志中的所有 FORMERR 错误是否都在抱怨未改善的引荐？dig 所说的内容位于生成这些错误消息的查询的“附加”部分中？

最后，您是否设置了未提及的存根区域或前向优先或仅前向区域？

Answer

如果您怀疑网络元素（例如路由器）正在截断或破坏 UDP DNS 流量，您可以尝试以下操作：

再次使用 dig 执行相同的查询，看看是否也会得到 FORMERR 作为响应代码。Dig（使用正确的选项）的执行方式与递归服务器类似，但可以让您更清楚地了解该过程。
如果您使用 dig 收到 FORMERR，请尝试 dig +tcp 并查看错误是否仍然存在（以排除 UDP 问题）
使用 Wireshark 或其他嗅探器来捕获服务器在递归满足查询时实际接收的内容。

您的日志中的所有 FORMERR 错误是否都在抱怨未改善的引荐？dig 所说的内容位于生成这些错误消息的查询的“附加”部分中？

最后，您是否设置了未提及的存根区域或前向优先或仅前向区域？

Question 2

你的 DNS 流量可能会被透明拦截，并路由到缓存 DNS 服务器和你要求的答案无法用简短的回答完全回答和缓存 DNS 服务器给出截断的答案，而不是最小答案（“最小响应是；”）。例如，www.nvidia.com.edgekey.net通过 CNAMES 和一长串名称服务器进行解析，其完整答案无法容纳在 500 字节左右的响应中。步骤如下：

您的 BIND 向根服务器发出非递归请求，并且只期望权威答案（在这种情况下，指的是负责该区域的 NS 服务器）。
响应拦截请求的缓存 DNS 服务器会以非权威但不完整的答案做出响应，例如，所寻找的确切 A 记录，但其权威部分被截断，其中不包含该记录的权威服务器。示例（请注意，akamaiedge.net 没有 NS 引用）：

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  59893
;; flags: qr rd ra; QUESTION: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 2
;; QUESTION SECTION:
;www.nvidia.com.edgekey.net.    IN      A

;; ANSWER SECTION:
www.nvidia.com.edgekey.net. 21559 IN    CNAME   e14462.a.akamaiedge.net.
e14462.a.akamaiedge.net. 19     IN      A       184.85.26.247

;; AUTHORITY SECTION:
edgekey.net.            13382   IN      NS      a18-65.akam.net.
edgekey.net.            13382   IN      NS      ns5-66.akam.net.
edgekey.net.            13382   IN      NS      a6-65.akam.net.
edgekey.net.            13382   IN      NS      ns7-65.akam.net.
edgekey.net.            13382   IN      NS      a5-65.akam.net.
edgekey.net.            13382   IN      NS      a13-65.akam.net.
edgekey.net.            13382   IN      NS      ns1-66.akam.net.
edgekey.net.            13382   IN      NS      ns4-66.akam.net.
edgekey.net.            13382   IN      NS      a28-65.akam.net.
edgekey.net.            13382   IN      NS      adns1.akam.net.
edgekey.net.            13382   IN      NS      a12-65.akam.net.
edgekey.net.            13382   IN      NS      usw6.akam.net.
edgekey.net.            13382   IN      NS      a16-65.akam.net.

;; ADDITIONAL SECTION:
a13-65.akam.net.        11507   IN      A       2.22.230.65
adns1.akam.net.         13382   IN      A       96.7.50.66

您的 BIND 看到来自所谓权威服务器的非权威答案（答案本身包括 NS 引用，因此 BIND 知道响应服务器对 A 记录没有权威性），并使用 FORMERR 丢弃整个响应：

DNS format error from 192.58.128.30#53 resolving www.nvidia.com.edgekey.net/A for client 127.0.0.1#53636: unrelated A e14462.a.akamaiedge.net in edgekey.net authority section

OP问题包括问题的等效描述（非改进的NS记录==权威部分中不相关的记录）：

Mar 18 19:53:20 kenneth named[4022]: DNS format error from 192.112.36.4#53 resolving ./NS: non-improving referral

然后，您的 BIND 会尝试对下一个根服务器进行相同的非递归查询，并重复该循环，直到没有更多的根服务器可尝试，并且 BIND 使用 SERVFAIL 响应原始递归查询。

可以说问题出在 BIND 本身的一个或几个错误：

检查非递归问题答案中 AUTHORITY 部分的一致性，例如，将查询转发到上游缓存时。它不应拒绝不一致的答案，因为它们可能是由长 AUTHORITY 部分的有效截断引起的
缓存时，它会天真地截断答案。它应该更聪明地截断并给出截断后更有用的 AUTHORITY 部分，或者如果截断的 AUTHORITY 部分没有用，则给出最少的答案（没有 AUTHORITY 部分）。
在缓存模式下，它应该默认为“minimal-responses yes;”。
如果其权威查询由非权威服务器应答（即，在发送的查询中未设置 RD 标志，但在收到的响应中设置），它应该记录/报告，即检测并报告拦截的 DNS 流量。

我应该指出，可以在小数据包中完全回答的查询不会触发这些错误，因此大多数 DNS 查询都能得到正确解析。

可能的解决方案：

要求你的 ISP 将“minimal-responses yes;”添加到他们的缓存配置中。
让 ISP 不要拦截你的 DNS，也许可以通过更换 ISP 来实现
运行没有错误的不同 BIND 版本（我不知道是否存在这样的版本）或其他软件。
通过 VPN 路由 BIND 的上游查询，并绕过 DNS 拦截

Answer