![新 COLO 的 BIND9 DNS Sec 出现故障](https://linux22.com/image/713199/%E6%96%B0%20COLO%20%E7%9A%84%20BIND9%20DNS%20Sec%20%E5%87%BA%E7%8E%B0%E6%95%85%E9%9A%9C.png)
我正在建立一个新网站,包括新的基础设施和服务。我有一个在 CentOS 7.3 上运行的 Bind DNS 服务器,我最近注意到对外部资源的递归查找失败了。这在我们的旧版基础设施中不会发生。
新的 colo 和传统的 colo 都可以访问互联网。我能够路由到两者中的外部资源(例如 8.8.8.8)。尽管 ISP 和路由会有所不同。
为了尝试排除故障并消除新旧 DNS 服务器之间的配置差异,我设置了两个全新的 CentOS 7 VM。一个在旧基础设施中,一个在新基础设施中。我使用相同的映像和方法来构建两者,以便构建后它们相同(减去主机名/ip)。
我安装了 Bind(版本 9.9.4),并将两者配置为简单的递归 DNS 服务器(无区域特定配置或其他)。两者均具有默认的 CentOS 配置:/etc/named.conf /var/named/
我所做的唯一更改是在 /etc/named.conf 中:
- 删除了“listen-on port 53 { 127.0.0.1; };”(这使其在所有设备上监听端口 53)。
- 设置 listen-on-v6 端口 53 { none; };(不监听 ipv6)
- set allow-query { any; }; (允许任何主机查询)
这将产生一个默认的 /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 中将每个相应的服务器设置为仅针对其自身进行解析。
从我的角度来看,这应该消除除以下之外的所有其他差异:
- 物理/服务器虚拟机管理程序
- 托管/网络/ISP
我对两者(针对 google.com、amazon.com、dropbox.com 等资源)测试了递归 DNS 查询。
与生产环境一样,在测试环境中,递归查询在旧基础设施中有效,但在新基础设施中无效。新基础设施中服务器的 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 传递给 dig。这导致递归更进一步,但我们仍然无法获取 com. 域的 NS,原因似乎相同。不过,在这种情况下,答案将来自根服务器。
我一直在寻找答案,并将继续这样做。但是,我不明白当服务器/BIND 配置相同时,哪些因素会导致此错误在一个 colo/网络中发生,而在另一个 colo/网络中不发生。如果有人知道是什么原因导致这种情况或我下一步应该去哪里,我很乐意听听。
总的来说,我试图理解以下内容:这仍然是一个简单的绑定配置错误吗?这可能是由本地网络配置引起的吗?我是否需要配置某些 ISP 或外部 DNS 端才能与新的 ISP/IP 配合使用?