我正在build立一个新的网站，包括新的基础设施和服务。 我在CentOS 7.3上运行绑定DNS服务器，最近我注意到对外部资源的recursion查找失败。 我们的传统基础架构中不会发生这种情况。
新的可乐和传统可乐都可以上网。 我可以路由到外部资源（例如8.8.8.8）。 虽然ISP和路线会有所不同。
为了尝试排除故障并消除新旧DNS服务器之间的configuration差异，我安装了两个全新的CentOS 7虚拟机。 一个在旧的红外线，一个在新的红外线。 我使用相同的图像和方法来build立两个，所以他们将是相同的（负主机名/ IP）后构build。
我安装了绑定（版本9.9.4），并configuration为简单的recursionDNS服务器（没有区域特定的configuration或其他）。 两者都有默认的CentOSconfiguration：/etc/named.conf / var / named /
我做的唯一更改是在/etc/named.conf中：
这会导致默认的/etc/named.conf如下所示：
// // named.conf // // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS // server as a caching only nameserver (as a localhost DNS resolver only). // // See /usr/share/doc/bind*/sample/ for example named configuration files. // // See the BIND Administrator's Reference Manual (ARM) for details about the // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html options { listen-on-v6 port 53 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; /* - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion. - If you are building a RECURSIVE (caching) DNS server, you need to enable recursion. - If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users. Failing to do so will cause your server to become part of large scale DNS amplification attacks. Implementing BCP38 within your network would greatly reduce such attack surface */ recursion yes; dnssec-enable no; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; 我还设置了每个相应的服务器来解决它自己，只有自己，在/etc/resolv.conf。
从我的angular度来看，这应该消除所有其他的差异，
我testing了两个recursionDNS查询（对像google.com，amazon.com，dropbox.com等资源）。
和生产环境一样，在testing环境中，recursion查询的工作是从旧的而不是从新的。 新build服务器的dig + trace表示无法获得根NS的IP地址：
dig @10.50.60.111 google.com +trace +additional ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> @10.50.60.111 google.com +trace +additional ; (1 server found) ;; global options: +cmd . 518400 IN NS b.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. dig: couldn't get address for 'b.root-servers.net': no more
这个答案应该由本地绑定服务器本身提供，因为我们使用默认的根提示打包在/var/named/root.ca
快速查看日志（/var/named/data/named.run），发现新的服务器似乎忽略了这些响应，因为它收到了一个“不安全的响应”：
validating @0x7fc3c8055510: . NS: got insecure response; parent indicates it should be secure error (insecurity proof failed) resolving './NS/IN': 198.41.0.4#53
但是，旧的服务器不存在这个问题。 我尝试禁用dnssec（在/var/named.conf），并传递+ nodnssec挖。 这导致在recursion中更进一步，但是我们仍然无法获得com的NS。 域似乎是相同的原因。 虽然，在这种情况下，答案将来自根服务器。
我一直在寻找答案，并将继续这样做。 但是，我不明白什么因素会导致这种错误发生在一个colo /networking，而不是其他的服务器/ BINDconfiguration是相同的。 如果任何人有什么想法会导致这个或我应该看看下一个我很想听到它。
一般来说，我想了解以下内容：这是否仍然是一个简单的绑定configuration错误？ 这可能是由本地networkingconfiguration造成的？ 我是否需要configurationISP或外部DNS端，才能使用新的ISP / IP？