linux bind 间歇性 dns 解析问题

Question 1

看起来您拥有该fitsaas.com区域数量惊人的权威服务器：

$ dig +short fitsaas.com NS
ns1.alpnames.com.
ns3.alpnames.com.
ns1.fitsaas.com.
ns3.fitsaas.com.
ns2.alpnames.com.
ns4.alpnames.com.
ns4.fitsaas.com.
ns2.fitsaas.com.
ns0.fitsaas.com.

由于所有这些都在 NS 记录中发布，因此这些名称服务器中的每一个都应该了解有关该fitsaas.com区域的所有信息（除了可能的子区域，但这些服务器中的每一个必须至少拥有这些子区域的委托记录）。每个域信息查询fitsaas.com将有效地随机发送到这些 DNS 服务器之一，以平衡 DNS 服务器的负载。

然而，看起来只有少数人能够真正为我提供答案：

$ for i in $(seq 0 4); do echo "ns$i.fitsaas: "; dig +short dallas1.fitsaas.com @ns$i.fitsaas.com; done
ns0.fitsaas:
ns1.fitsaas:
ns2.fitsaas:
63.142.255.107
ns3.fitsaas:
63.142.255.107
ns4.fitsaas:

$ for i in $(seq 1 4); do echo "ns$i.alpnames: "; dig +short dallas1.fitsaas.com @ns$i.alpnames.com; done
ns1.alpnames:
ns2.alpnames:
ns3.alpnames:
ns4.alpnames:

其余问题名称的结果是类似的：只有ns2.fitsaas.com和ns3.fitsaas.com似乎准备向世界提供有关这些名称的答案。

通过替换+short命令dig选项，+noall +answer +comments我们可以获得有关出现问题的更多信息。

$ for i in $(seq 0 4); do echo "ns$i.fitsaas: "; dig +noall +answer +comments dallas1.fitsaas.com @ns$i.fitsaas.com || echo "error"; done
ns0.fitsaas:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 62501
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[...]

status: REFUSED表示该服务器拒绝回答我的查询。这没什么大不了的，因为这显然是一个错误，DNS解析器只会询问另一个权威DNS服务器。其他不合作的ns*.fitsaas.com名称服务器似乎也做出了同样的反应。

然而，ns*.alpnames.com名称服务器会给出不同的答案：

$ for i in $(seq 1 4); do echo "ns$i.alpnames: "; dig +noall +answer +comments dallas1.fitsaas.com @ns$i.alpnames.com; done
ns1.alpnames:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23895
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
[...]

status: NXDOMAIN意思是“我确信这样的 DNS 名称不存在。”这是一个令人震惊的事实：当某个区域的权威 DNS 服务器表示某个名称在该区域中不存在时，这不是一个错误：这是一个有效答案，尽管答案是否定的。否定答案甚至可以缓存，尽管缓存时间通常比肯定答案短。

一旦解析器从对请求的域具有权威性的 DNS 服务器获得否定答案，它必须将其视为真理：没有这样的名称。由于给定区域的所有权威服务器都应该对该区域有完整且最新的了解，因此向另一个权威服务器征求第二意见应该只是浪费时间和资源。

这些ns*.alpnames.com服务器是否应该对您的区域具有权威性？如果不是，请联系您的 DNS 注册商，并将它们从授权 NS 记录中删除。由于这些授权记录处于 TLD 级别.com，因此您不能仅通过编辑权威 DNS 服务器中的 NS 记录来执行此操作。

由于ns0.fitsaas.com、ns1.fitsaas.com和ns4.fitsaas.com似乎拒绝外部查询，您也应该考虑将他们从代表团的 NS 记录中删除——他们似乎不愿意为公众服务，因此在代表团中提及他们毫无意义。

Answer