☰

BIND9 作为仅缓存名称服务器不起作用

tag-icon • tag-icon domain-name-system bind ubuntu-12.04 dig
BIND9 作为仅缓存名称服务器不起作用

我在apt-get新安装并完全更新的 UBUNTU 12.04 上安装了 BIND9，并在 VirtualBox 上进行了虚拟化。
我想将其用作仅缓存的名称服务器。

named.conf仅包含以下几行：

options {
    directory "/var/cache/bind";  
    dnssec-validation auto;  
    auth-nxdomain no;  
    listen-on-v6 {any;};  

    recursion yes;
    allow-recursion {localnets;};
    allow-query-cache {localnets;};
    allow-query {localnets;};
};  

zone "." {
    type hint;
    file "/etc/bind/db.root";
};

zone "localhost" {
   type master;
   file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
   type master;
   file "/etc/bind/db.127";
};

现在，如果我dig使用我的名称服务器进行任何操作，查找将失败connection timed out; no servers could be reached，并且 BIND9 日志也将充满DNS format error [...] non-improving referral或FORMERR。

更具体地说，结果dig @127.0.0.1 www.amazon.com是

; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 www.amazon.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

此外，使用 Wireshark 我可以看到发往根服务器的数据包，但从未收到响应。

但是如果我dig使用外部名称服务器（例如 8.8.8.8），或者在 BIND9 的转发器选项中使用它，则查找会成功。

为什么？

答案1

我假设您已经验证过在 VirtualBox 中的 Ubuntu 中实际的互联网连接能够正常运行。

如果是这样，你自己的递归服务器无法正常工作的一个常见原因是你的互联网提供商阻止了对在端口上运行的其他权威名称服务器的访问domain。我看到你已经尝试直接向根服务器发出请求，但没有成功直接与dig，这表明确实存在一些连接问题。

简而言之，你可以这样做一个简单的测试：尝试运行dig @8.8.8.8 +trace www.google.com以模拟递归解析器如何进行名称解析。

如果您在之前遇到超时.，则可能是您的连接出现问题，或者您的提供商阻止了 Google 公共 DNS（并且很可能阻止了任何其他 DNS）。

如果您在之后立即出现超时.，则您的提供商将阻止对根服务器的访问（也可能阻止所有其他权威名称服务器）。

如果您的递归解析没有超时，但缺少com.和google.com.步骤，直接从跳到.（www.google.com.或者甚至不必从.开始），则意味着您的提供商正在将所有domain-port 请求重定向到他们自己的一组递归 DNS 服务器，并且您无法在这样的互联网连接下运行您自己的递归名称服务器。

如果您通过所有、和步骤获得与下面几乎完全相同的结果.，com.那么您自己的本地递归解析器应该可以正常工作，只要遵循安装和配置说明google.com.。www.google.com.

# dig @8.8.8.8 +trace www.google.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 +trace www.google.com
; (1 server found)
;; global options: +cmd
.                       2244    IN      NS      a.root-servers.net.
.                       2244    IN      NS      b.root-servers.net.
.                       2244    IN      NS      c.root-servers.net.
.                       2244    IN      NS      d.root-servers.net.
.                       2244    IN      NS      e.root-servers.net.
.                       2244    IN      NS      f.root-servers.net.
.                       2244    IN      NS      g.root-servers.net.
.                       2244    IN      NS      h.root-servers.net.
.                       2244    IN      NS      i.root-servers.net.
.                       2244    IN      NS      j.root-servers.net.
.                       2244    IN      NS      k.root-servers.net.
.                       2244    IN      NS      l.root-servers.net.
.                       2244    IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 25 ms

com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
;; Received 504 bytes from 192.33.4.12#53(c.root-servers.net) in 15 ms

google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 168 bytes from 192.55.83.30#53(m.gtld-servers.net) in 183 ms

www.google.com.         300     IN      A       74.125.225.208
www.google.com.         300     IN      A       74.125.225.211
www.google.com.         300     IN      A       74.125.225.212
www.google.com.         300     IN      A       74.125.225.209
www.google.com.         300     IN      A       74.125.225.210
;; Received 112 bytes from 216.239.38.10#53(ns4.google.com) in 24 ms

答案2

我注意到的第一件事是，named.conf 中没有“recursion yes;”。出于安全原因，BIND 默认不支持递归（一段时间内）。您应该授权本地网络使用递归查询来查询解析器：

acl me {
            ::1/128;
            127.0.0.0/8;
};
...
    recursion yes;
    allow-recursion   { me; };
    allow-query-cache { me; };
    allow-query { me; };

它无法解释您在日志中发现的奇怪错误消息。坦率地说，在 ServerFault 的问题中，我讨厌模糊的总结，例如“现在，如果我使用我的名称服务器挖掘任何东西，查找就会失败，连接超时”。发布完整的命令和完整的结果，我们会看到。

相关内容