☰

在系统日志中绑定 FORMERR 错误

tag-icon • tag-icon domain-name-system router bind
在系统日志中绑定 FORMERR 错误

我最近更换了一个故障的路由器...并且，过了一段时间，我发现 /var/log/syslog 中报告了很多错误（至少比查询的数量多一个数量级） - 形式为：

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

我在 bind.conf 中得到以下内容可能是相关的：

dnssec-enable no;
dnssec-validation no;

这可能是新路由器损坏 UDP 数据报的问题，还是其他问题？新路由器是 (廉价的) Netgear WNR854T - 它应用了最新的固件。

如果从上述情况看不出来，有人能建议如何最好地诊断这个故障吗？

-- 附加详细信息 -- 这是我确信应该能够解析的地址所做出的典型 dig 响应。

$ dig A barclays.co.uk                                         ~

; <<>> DiG 9.8.1-P1 <<>> A barclays.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22161
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;barclays.co.uk.                        IN      A

;; Query time: 84 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 20 23:08:40 2013
;; MSG SIZE  rcvd: 32
$

答案1

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

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

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

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

答案2

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

  1. 您的 BIND 向根服务器发出非递归请求，并且只期望权威答案（在这种情况下，指的是负责该区域的 NS 服务器）。
  2. 响应拦截请求的缓存 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
  1. 您的 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
  1. 然后，您的 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 拦截

答案3

我正在印度尼西亚访问，我收到这些消息是因为运营商/政府破坏了 DNS。DNSSEC 无法验证，直接访问根服务器会导致记录 FORMERR 消息（bind9，每个 DNS 查询 13 条消息）。您示例中的地址是 DNS 根服务器 G。

相关内容