如何解析bind9中的子域？
Mhe*_*eni 0 domain-name-system bind subdomain internal-dns
在我们公司，我们有来自一个大 B 类 (/16) 地址的单独 /24 子网。
（参考图片）
我在domain1.company.com工作，从那里我能够解析同一个域xx.domain1.company.com中的所有主机名（例如 server1.doamin1.company.com）。
我也可以使用domain3.company.com 中的 DNS 服务器作为转发器访问互联网。
但是当尝试解析另一个子域（例如：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.default-zones
// 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; };
};
为便于讨论，我们将您公司的域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 层次结构递归下降时，同样的事情经常发生在多个级别。如果任何级别给出无效信息，那么低于该级别的任何子级别都不太可能正常运行。我怀疑您公司的顶级域名服务器可能存在配置错误，或者出于某种原因可能有意限制域之间的访问。
对树进行故障排除
我们可以任意选择其中一个ROOT-SERVERS名称服务器，并.com使用强大的 DNS 实用程序询问它我们应该将主机名查询发送到哪里dig。这里我们dig用来查询域名服务器@198.41.0.4并询问域名有com.哪些ns记录——也就是说，域名的com域名服务器是什么？
$ 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 正常工作。具体来说，如果配置错误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
使用上一个dig命令返回的实际 IP，而不是 172.16.177.4 。通常，您随后看到的信息应确认现有 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 查询可能因多种原因而失败。一些最常见的原因是区域文件中的 IP 号码错误；或者因为 IP 无法从您的网络访问（无论是来自防火墙或未知路由，还是几种类型的网络故障中的任何一种）；或者因为高级名称服务器引用的低级名称服务器没有正确配置来回答查询。
| 归档时间： |
|
| 查看次数： |
5154 次 |
| 最近记录： |