☰

DNS 是分层的

tag-icon • tag-icon domain-name-system bind subdomain internal-dns
DNS 是分层的

在我们的公司中，我们有一个来自一个大的 B 类（/16）地址的单独的 /24 子网。

（参见图片）

我在域名1.company.com从那里我能够解析同一域中的所有主机名xx.domain1.company.com（例如 server1.doamin1.company.com）。

我也可以使用 DNS 服务器访问互联网域名3.company.com作为货运代理。

但当尝试解析另一个子域中的任何内容时（例如：server3.domain2.company.com）， 它失败。

在此处输入图片描述

这就是我的样子named.conf.options。


acl "inner-net" {
    A.B.C.0/24;
    10.11.200.0/24; //private mgmt network
};

acl "blocked-from-recursion" {
    A.B.C.66/32;
};

options {
    directory "/var/cache/bind";
    // recursion yes;
        allow-recursion { inner-net; };
    blackhole { blocked-from-recursion; };
        listen-on { any; };
        allow-transfer { none; };
    allow-query { inner-net; };
        forwarders {
                A.B.E.2; // ip address of the DNS fowarder
                x.x.x.x; //second forwarder
                //8.8.8.8;
        };
    dnssec-enable yes;
    dnssec-validation yes;

    auth-nxdomain no;    # conform to RFC1035
    // listen-on-v6 { any; };
};

如果我无法访问其他子网中的其他 DNS 服务器，我该如何解决这个问题？（无法更改其配置）

编辑：添加默认区域

/etc/named.conf.默认区域

// prime the server with knowledge of the root servers
zone "." {
    type hint;
    file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

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

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

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

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

/etc/bind/named.conf.local

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "domain1.company.com" {
    type master;
    file "/etc/bind/zones/db.domain1.company.com";
//    allow-transfer { 10.20.30.14; };
};

zone "A.B.C.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.A.B.C";
//    allow-transfer { 10.20.30.14; };
};

zone "10.11.200.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10.11.200";
//    allow-transfer { 10.20.30.14; };
};

答案1

为了讨论的目的，我们将您公司的域名称为example.com虚构的，而不是company.com真实存在的。

TL;DR 从上到下调试 DNS 问题，直到找到问题所在的级别。编辑您的帖子以包含一些基本dig结果，例如：

dig @A.B.E.2 example.com ns
dig @A.B.E.2 domain2.example.com ns
dig @A.B.E.2 server3.domain2.example.com

如果您的问题中没有更多细节，例如具体dig查询及其详细结果，则很难明确评估您的问题。

如果以下内容均无帮助，请编辑您的帖子以显示这些命令的结果。

DNS 是分层的

如果您愿意为正在学习 DNS 的读者做一点复习，DNS 本质上是一个分层数据库，其中顶级名称服务器指定二级名称服务器的信息，依此类推，可以进行多层递归。DNS 也可以按“平面”拓扑排列（域和子域都混合到同一个区域文件中），但至少在最高级别，它是分层的。

我们将您公司的域名统称为example.com。

顶级 DNS 级别是“。”区域。这对应于您配置中的“提示”区域。该提示区域列出了几个顶级 DNS 服务器：

.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
; 
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b
..snip..

每个子级别都要求上一级正确

这些“根级”名称服务器知道如何到达其下的任何级别，即下一个“子域”。它们知道“要获取com地址，请转到此处。要获取org地址，请转到此处。”等等。由于我们example.com在本例中指的是层次结构，这意味着下一级是层次com结构。当我们递归地通过 DNS 层次结构时，同样的事情经常发生在多个级别。如果任何级别给出无效信息，则该级别以下的任何子级别都不太可能正常运行。我怀疑贵公司的顶级名称服务器可能存在配置错误，或者出于某种原因，可能存在域之间的故意访问限制。

排除树故障

我们可以任意选择其中一个名称服务器，并使用可靠的 DNS 实用程序ROOT-SERVERS询问它我们应该将主机名查询发送到哪里。在这里，我们使用查询名称服务器并询问域的记录是什么——也就是说，域的名称服务器是什么？.comdigdig@198.41.0.4com.nscom

$ dig @198.41.0.4 com. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 2252
;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12 
;; QUESTION SECTION:
;; com. IN      NS

;; ANSWER SECTION:

;; AUTHORITY SECTION:
com.    172800  IN      NS      e.gtld-servers.net.
com.    172800  IN      NS      b.gtld-servers.net.
com.    172800  IN      NS      j.gtld-servers.net.
com.    172800  IN      NS      m.gtld-servers.net.
com.    172800  IN      NS      i.gtld-servers.net.
com.    172800  IN      NS      f.gtld-servers.net.
com.    172800  IN      NS      a.gtld-servers.net.
com.    172800  IN      NS      g.gtld-servers.net.
com.    172800  IN      NS      h.gtld-servers.net.
com.    172800  IN      NS      l.gtld-servers.net.
com.    172800  IN      NS      k.gtld-servers.net.
com.    172800  IN      NS      c.gtld-servers.net.
com.    172800  IN      NS      d.gtld-servers.net.

;; ADDITIONAL SECTION:
e.gtld-servers.net.     172800  IN      A       192.12.94.30
e.gtld-servers.net.     172800  IN      AAAA    2001:502:1ca1::30
b.gtld-servers.net.     172800  IN      A       192.33.14.30
b.gtld-servers.net.     172800  IN      AAAA    2001:503:231d::2:30
j.gtld-servers.net.     172800  IN      A       192.48.79.30
j.gtld-servers.net.     172800  IN      AAAA    2001:502:7094::30
m.gtld-servers.net.     172800  IN      A       192.55.83.30
m.gtld-servers.net.     172800  IN      AAAA    2001:501:b1f9::30
i.gtld-servers.net.     172800  IN      A       192.43.172.30
i.gtld-servers.net.     172800  IN      AAAA    2001:503:39c1::30
f.gtld-servers.net.     172800  IN      A       192.35.51.30
f.gtld-servers.net.     172800  IN      AAAA    2001:503:d414::30

;; Query time: 23 msec
;; SERVER: 198.41.0.4
;; WHEN: Fri Aug  9 12:55:15 2019
;; MSG SIZE  rcvd: 509

这是相当多的输出，所以我会把它分解开来。对于我们当前的目的来说，最重要的一行是：

;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12

这意味着我们在 198.41.0.4 查询的名称服务器收到 1 个查询，返回 0 个答案和 13 个权威来源。我们暂时忽略“其他”条目，但它们的存在基本上是为了方便并加快可能随之而来的进一步 DNS 查询。

事实上，我们收到 0 个答案基本上意味着名称服务器在告诉我们，“我不知道答案......”，而 13 个权限条目意味着，“......但我做知道这些名称服务器可以回答这个问题。”这被称为delegated域。顶级服务器ROOT-SERVERS不直接了解com域（除了它存在），但他们已将com域的权限专门委托给列表中出现的 13 个名称服务器。可以查询其中任何一个以获取有关层次结构中域的详细信息com。让我们这样做：

$ dig @192.12.94.30 example.com ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 38217
;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;; example.com.       IN      NS

;; ANSWER SECTION:

;; AUTHORITY SECTION:
example.com.  172800  IN      NS      ns.example.com.
example.com.  172800  IN      NS      ns2.example.com.

;; ADDITIONAL SECTION:
ns.example.com.       172800  IN      A       172.16.177.4
ns2.example.com.      172800  IN      A       172.16.217.4

;; Query time: 4 msec
;; SERVER: 192.12.94.30
;; WHEN: Fri Aug  9 13:05:51 2019
;; MSG SIZE  rcvd: 98

部分信息是虚构的，仅供参考。具体来说，我们假设这些172.16.x.y地址是真实的公共 IP 地址，对于真实的域名来说，它们基本上必须是真实的.com。我们再次看到，ANSWER: 0因此名称服务器告诉我们“我不直接了解example.com，但这些名称服务器知道。” ns.example.com和ns2.example.com是您公司的最高级别域名服务器。它们可能不是解析服务器（最佳实践是它们不会是解析服务器），但它们必须是权威的。也就是说，它们需要 a)有任何有关贵公司域名的 DNS 查询的答案example.com；或者 b) 他们需要知道当 DNS 客户端需要任何无法直接从他们处获得的 DNS 记录时，该将 DNS 客户端引向何处。您的问题很可能就出在这层，即贵公司的顶级名称服务器。

正如我之前提到的，DNS 的层次结构意味着高级别的问题可能会阻止较低级别的 DNS 正常工作。具体来说，如果配置错误阻止ns.example.com您获取有关子域的信息domain1.example.com，那么这可能是您遇到问题的原因之一。另一个原因可能是顶级名称服务器给出了正确的信息，但公司内部路由或防火墙策略有意或无意地阻止了您的访问。

这可能有助于您确定它是配置错误还是路由/防火墙问题：

dig @192.12.94.30 example.com ns

这应该会返回类似上述虚构的信息，并告诉您公司名称的顶级名称服务器是什么。现在我们将直接查询它们，并询问有关子域的信息。由于我们持怀疑态度，我们将问它一个我们已经知道答案的问题。名称服务器domain1.example.com是你的BIND 服务器，对吗？让我们看看企业名称服务器是否同意：

dig @172.16.177.4 domain1.example.com ns

不要使用 172.16.177.4，而要使用上一个命令返回的实际 IP dig。通常，您随后看到的信息应确认现有 BIND 服务器的配置（其主机名和 IP 号码），因为它对 具有权威性domain1.example.com。

代表团破裂？

同样，顶级公司名称服务器也应该知道要使用的正确名称服务器全部贵公司中有效的子域。根据定义，权威名称服务器必须知道该域中任何查询的答案，或者至少能够引用知道答案的另一个名称服务器（或知道知道答案的人等）。由于这domain2.example.com是您的具体问题案例，让我们来看看：

dig @172.16.177.4 domain2.example.com ns

这里至少会出现几种情况。第一种情况是，我们假设ns.example.com配置错误，并且不知道domain2.example.com存在。你会看到这样的答案：

;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 21457
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; domain2.example.com.       IN      NS

;; ANSWER SECTION:

;; AUTHORITY SECTION:
example.com.  3600    IN      SOA     ns.example.com. hostmaster.example.com. 201906260 7200 900 2592000 3600

;; ADDITIONAL SECTION:

;; Query time: 4 msec
;; SERVER: 172.16.177.146
;; WHEN: Fri Aug  9 14:03:16 2019
;; MSG SIZE  rcvd: 89

再次注意：ANSWER: 0; AUTHORITY: 1。“我不知道”，但第二部分不同。在上面的“推荐”回复中，我们得到了额外的NS记录来查阅，这意味着“我不知道，但可以询问其中之一。”这里的“权威”条目是域本身的“权威开始”记录。换句话说，它可能意味着“没有其他人可以询问，因为我是 的权威服务器example.com。”这种结果风格（答案：0，指向域的 SOA 的权威）是明确的“该记录不存在”。该字符串rcode: NXDOMAIN也是“不存在”结果的诊断。

无法访问的名称服务器

可能出现的第二种情况是，公司名称服务器确实返回了值，但您无法访问该主机。假设您查找名称服务器domain2.example.com并获取：

$ dig @172.16.177.146 domain2.example.com ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3098
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; QUESTION SECTION:
;; domain2.example.com.        IN      NS

;; ANSWER SECTION:
domain2.example.com.   3600    IN      NS      ns1.domain2.example.com.
domain2.example.com.   3600    IN      NS      ns2.domain2.example.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
ns1.domain2.example.com.       3600    IN      A       172.16.92.50
ns2.domain2.example.com.       3600    IN      A       172.16.27.50

;; Query time: 0 msec
;; SERVER: 172.16.177.146
;; WHEN: Fri Aug  9 14:08:17 2019
;; MSG SIZE  rcvd: 200

这看起来很有希望！现在我们知道该找谁来解析 中的主机名domain2。但如果发生这种情况：

$ dig @172.16.27.50 host.domain2.example.com
Error: error sending query: Could not send or receive, because of network error

那么您可能有防火墙阻止您，或者路由器不知道如何到达该子网。

“蹩脚的”域名服务器

如果一个名称服务器将子域名委托给另一个名称服务器，但第二个名称服务器不知道该委托（换句话说，它没有专门配置为响应该区域的查询），则下游名称服务器被称为“无能”。它应该响应查询，但它不知道应该这样做。或者有时情况可能相反，下游名称服务器已经退役，但上游名称服务器仍在提供错误的引荐记录。我没有一个容易制作的例子来说明这种情况会是什么样子，但假以时日，你会遇到这种情况。第一个名称服务器会说：“我不知道，但可以问这个人。”第二个名称服务器会说：“我怎么会知道？你为什么要问我？”

概括

由于 DNS 是一个递归搜索的分层数据库，因此只要任何一个级别出现故障，DNS 就可能出现故障。解决无法解析 DNS 查询问题的关键是从顶部开始，然后向下查找，直到找到正确解析查询的最后一级。那么问题可能就出在下一级，即最后一个已知良好名称服务器返回的引用记录。

DNS 查询可能因多种原因而失败。最常见的原因是区域文件中的 IP 号码错误；或者 IP 无法从您的网络访问（无论是来自防火墙还是未知路由，或任何一种类型的网络故障）；或者高级名称服务器引用的低级名称服务器未正确配置以回答查询。

相关内容