我在主名称服务器中有一个有趣的错误。 我使用绑定9.3.4运行Fedora Linux。 服务器计划被replace，因为它已经很老了，但是我必须在这段时间才能正常工作。 问题是我的名字服务器无法parsingdigbypines.ca。 digbypines.ca的权威名称服务器是204.15.193.162和204.15.193.163。 我的名字服务器是24.222.7.12。
一个防火墙的bug（传出的DNS连接被传送到端口53）使得不可能联系digbypines.ca的域名服务器。 所以如果我要在24.222.7.12的ssh到我的名字服务器并运行
dig @204.15.193.162 digbypines.ca 我会得到的
;; connection timed out; no servers could be reached
如果我尝试telnet到端口53上的204.15.193.162，我也会得到一个超时。 既然如此，我删除了SNAT防火墙规则，现在上面的命令按预期工作。 但是这里有趣的部分。
出于某种原因，我无法说服绑定与digbypine的名称服务器交谈！ 即使在固定SNATting之后，它也不起作用。
运行“dig + trace digbypines.ca”显示我将得到NSlogging，但拒绝解决它们：
挖+追踪digbypines.ca
; << >> DiG 9.3.4-P1 << >> + trace digbypines.ca ;; 全局选项：printcmd。 在NS
i.root-servers.net。 。 在NS
j.root-servers.net。 。 在NS
k.root-servers.net。 。 在NS
l.root-servers.net。 。 在NS
m.root-servers.net。 。 在NS
a.root-servers.net。 。 在NS
b.root-servers.net。 。 在NS
c.root-servers.net。 。 在NS
d.root-servers.net。 。 在NS
e.root-servers.net。 。 在NS
f.root-servers.net。 。 在NS
g.root-servers.net。 。 在NS
h.root-servers.net。 ;; 在1 ms内收到来自192.168.0.12＃53（192.168.0.12）的408个字节约 172800在NS l.ca-servers.ca。 约
172800在NS sns-pb.isc.org。 约 172800在NS m.ca-servers.ca。 约 172800 IN
NS c.ca-servers.ca。 约 172800在NS
a.ca-servers.ca。 约 172800在NS
j.ca-servers.ca。 约 172800在NS
f.ca-servers.ca。 约 172800在NS
k.ca-servers.ca。 约 172800在NS
z.ca-servers.ca。 约 172800在NS
e.ca-servers.ca。 ;; 在120毫秒内从192.36.148.17＃53（i.root-servers.net）收到430字节digbypines.ca。 86400在NS ns2.extremehosting.ca。 digbypines.ca。 86400在NS ns1.extremehosting.ca。 ;; 在31 ms内收到来自156.154.101.4＃53（l.ca-servers.ca）的114个字节
挖：无法获得“ns2.extremehosting.ca”的地址：失败
我有点卡住了 我打电话给他们的支持小组，他们向我保证，我的IP不会被阻止。 我真的不知道如何在命令行上挖掘他们的名字服务器，但不能通过绑定进行相同的操作。
我也尝试重新启动绑定，networking，并运行“rndc冲洗”。 没爱。
我可以解决digbypines.ca和ns2.extremehosting.ca和ns1.extremehosting.ca从家里，所以我不知道发生了什么事情。
我也可以从我的名字服务器的命令行上成功运行dig @204.15.193.163 ns2.extremehosting.ca 。
那我解决了。 原来我之前的系统pipe理员已经强制所有传出的查询到端口53. extremehosting.ca的名称服务器似乎阻止端口53上的传入连接，源于端口53，因此我无法与他们沟通。
通过从named.conf中删除这些行：
query-source port 53; query-source-v6 port 53;
并确认防火墙不会引起任何进一步的问题，名称parsing再次起作用。
另外，我发现这篇文章有助于确定你的名字parsing器的源端口行为是非常有用的。 整理这个DNS问题的副作用是我也插入了一个潜在的名称caching中毒漏洞。
感谢所有评论。
嗯，当你使用nslookup与他们的服务器交谈时会发生什么？ IE：
$ nslookup >server 204.15.193.162 Default server: 204.15.193.162 Address: 204.15.193.162#53 > www.digbypines.ca Server: 204.15.193.162 Address: 204.15.193.162#53 www.digbypines.ca canonical name = digbypines.ca. Name: digbypines.ca Address: 204.15.193.162 >
这应该让你知道，如果这是一个BIND问题或防火墙之一。