DNS子域委派与递归禁用场景下的解析配置问题及最佳实践咨询

环境概述 #

我在测试环境中有4台DNS服务器：

• DNS1需要成为domain.com的权威服务器
• 将子域sub.domain.com委派给另外3台服务器
• 客户端设备直接连接DNS1作为 resolver

配置文件详情 #

域配置文件 db.domain.com #

root@DNS1:/etc/bind# more db.domain.com

$TTL    604800

@       IN      SOA     domain.com. admin.domain.com. (
75     ; Serial
900     ; Refresh 15 mins
86400     ; Retry
2419200     ; Expire
604800 )   ; Negative Cache TTL
;
; name servers - NS records
IN      NS      ns1.domain.com.
; name servers - A records
ns1.domain.com.         IN      A       192.168.242.200

www.domain.com.         IN      CNAME   www.sub.domain.com.

;sub domain
sub.domain.com.         IN      NS      ns1.sub.domain.com.
sub.domain.com.         IN      NS      ns2.sub.domain.com.
sub.domain.com.         IN      NS      ns3.sub.domain.com.

ns1.sub.domain.com.     IN      A       172.16.14.50
ns2.sub.domain.com.     IN      A       10.10.4.50
ns3.sub.domain.com.     IN      A       192.168.100.50

BIND全局配置 named.conf.options #

root@DNS1:/etc/bind# more named.conf.options

options {
directory "/var/cache/bind";
recursion yes;                  # enables recursive queries
listen-on { any; };             # ns1 private IP address - listen on private network only
allow-transfer { none; };       # disable zone transfers by default
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys.  See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on-v6 { any; };
};

BIND本地配置 named.conf.local #

root@DNS1:/etc/bind# more 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 "domain.com" {
type primary;
file "/etc/bind/db.domain.com";
notify yes;
};

zone "sub.domain.com" {
type forward;
forwarders { 172.16.14.50; 10.10.4.50; 192.168.100.50; };
};

测试现象 #

客户端使用DNS1作为 resolver，测试NS记录查询：

递归启用时的结果 #

root@gns3-webterm-1:~# nslookup
> set type=ns
> sub.domain.com
Server:     192.168.242.200
Address:    192.168.242.200#53

Non-authoritative answer:
sub.domain.com  nameserver = ns3.sub.domain.com.
sub.domain.com  nameserver = ns2.sub.domain.com.
sub.domain.com  nameserver = ns1.sub.domain.com.

Authoritative answers can be found from:

此时DNS1会向192.168.100.50查询NS记录并返回结果。

递归禁用时的结果 #

> set type=ns
> sub.domain.com
Server:     192.168.242.200
Address:    192.168.242.200#53

Non-authoritative answer:
*** Can't find sub.domain.com: No answer

Authoritative answers can be found from:
sub.domain.com  nameserver = ns3.sub.domain.com.
sub.domain.com  nameserver = ns1.sub.domain.com.
sub.domain.com  nameserver = ns2.sub.domain.com.

ns3.sub.domain.com  internet address = 192.168.100.50
ns2.sub.domain.com  internet address = 10.10.4.50
ns1.sub.domain.com  internet address = 172.16.14.50

递归禁用后，客户端无法解析指向www.sub.domain.com的www.domain.com。

问题 #

1. 如果想禁用DNS1的递归，但仍能解析sub.domain.com，应该怎么配置？看起来单独定义转发区域不起作用？
2. 子域委派的最佳实践是什么？父域名服务器还需要额外配置吗？

解答 #

问题1：禁用递归后解析子域的配置方案 #

你遇到的问题核心是：当递归禁用时，BIND不会主动去查询子域的权威服务器，即使你配置了转发区域——因为转发功能依赖递归能力（转发本质是服务器替客户端做递归查询）。要解决这个问题，有两个靠谱的方案：

方案A：保留子域的委派记录，启用allow-recursion的精确白名单

不需要完全禁用递归，而是只允许客户端针对sub.domain.com相关的查询触发递归。修改named.conf.options里的配置：

recursion yes;
allow-recursion {
    你的客户端IP段; # 比如 192.168.242.0/24;
    localhost;
    localnets;
};
# 同时确保缓存查询的权限和递归一致
allow-query-cache { same as allow-recursion; };

这样既限制了递归的使用范围（只给你的测试客户端用），又能让DNS1替客户端查询子域的记录。

方案B：配置子域的Stub区域（替代转发区域）

Stub区域会让BIND从委派的NS服务器获取子域的权威记录缓存下来，不需要全量递归。修改named.conf.local里的sub.domain.com区域配置：

zone "sub.domain.com" {
    type stub;
    file "/etc/bind/db.sub.domain.com"; # 这个文件只需要包含子域的NS记录和对应的A记录
    masters { 172.16.14.50; 10.10.4.50; 192.168.100.50; };
};

对应的db.sub.domain.com文件内容可以直接从你现有的db.domain.com里复制子域部分：

$TTL 604800
@       IN      NS      ns1.sub.domain.com.
@       IN      NS      ns2.sub.domain.com.
@       IN      NS      ns3.sub.domain.com.

ns1.sub.domain.com.     IN      A       172.16.14.50
ns2.sub.domain.com.     IN      A       10.10.4.50
ns3.sub.domain.com.     IN      A       192.168.100.50

Stub区域会定期从masters服务器更新子域的NS记录，这样DNS1作为权威服务器，可以直接返回子域的NS信息，并且能缓存子域的其他记录（比如www.sub.domain.com），不需要全量递归。

问题2：子域委派的最佳实践 #

子域委派的核心是确保父域和子域的配置一致，避免"断链"。这里有几个关键的最佳实践：

• 确保父域的委派记录包含所有子域权威NS的A/AAAA记录：你现在已经做了这一点（在db.domain.com里添加了ns1-3.sub.domain.com的A记录），这很重要——否则 resolver 需要额外查询子域NS的地址，容易出现解析失败。
• 子域的权威服务器必须配置正确的SOA和NS记录：子域的权威服务器（ns1-3.sub.domain.com）上的sub.domain.com zone必须包含自己的NS记录，并且SOA的主服务器要指向其中一个NS，否则会出现"权威不一致"的问题。
• 避免重复配置子域的转发/Stub区域（除非必要）：如果父域已经正确配置了委派，正常情况下 resolver 会自动跟随NS记录去查询子域，不需要在父域服务器上额外配置子域的转发/Stub——只有当你需要禁用递归但仍要解析子域时，才需要用Stub区域。
• 启用区域通知（Notify）：你已经在父域的zone配置里加了notify yes;，这会让父域在委派记录更新时通知子域的NS服务器，确保记录同步。
• 测试委派的有效性：可以用dig +trace sub.domain.com来跟踪解析路径，确认父域的NS记录能正确指向子域的服务器，并且子域服务器能返回权威应答。

备注：内容来源于stack exchange，提问作者user117974