![使用 bind 为根区域提供服务并利用 RPZ](https://linux22.com/image/687096/%E4%BD%BF%E7%94%A8%20bind%20%E4%B8%BA%E6%A0%B9%E5%8C%BA%E5%9F%9F%E6%8F%90%E4%BE%9B%E6%9C%8D%E5%8A%A1%E5%B9%B6%E5%88%A9%E7%94%A8%20RPZ.png)
我在将 BIND 配置为根区域的私人服务器时遇到了一些问题。
我已尝试使用点“。”(在某处读到过)和空字符串“”(我的错误猜测)作为根区域标识符(两者都有语法错误)
zone "." { ; sorry
...
};
还
zone "" { ;sorry
...
};
您对如何服务根区域有什么提示吗?
(我的注释:服务根区域可能与作为根服务器有所不同!)
更新
问题实际上在于根(“。”)处的响应策略区域:
options {
#response-policy {zone "com"; }; #it is OK (before commenting)
response-policy {zone "."; }; #it makes error when loading the config
};
zone "."{
type master;
file "db/zone.root.db";
};
zone "com"{ #just for syntax test/check
type master;
file "db/zone.root.db";
};
named-checkconf -zj named.conf
zone ./IN: NS 'LOCALHOST' has no address records (A or AAAA)
zone ./IN: not loaded due to errors.
_default/./IN: bad zone
zone com/IN: loaded serial 1
笔记:在两种配置中:服务加载的配置和终止的配置,输出是相同的
挖掘 www.google.com @127.0.0.1
01 ; <<>> DiG 9.10.4-P2 <<>> www.google.com @127.0.0.1
02 ;; global options: +cmd
03 ;; Got answer:
04 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58406
05 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
06
07 ;; OPT PSEUDOSECTION:
08 ; EDNS: version: 0, flags:; udp: 4096
09 ;; QUESTION SECTION:
10 ;www.google.com. IN A
11
12 ;; ANSWER SECTION:
13 www.google.com. 5 IN CNAME nosslsearch.google.com.rpz.zone.
14 nosslsearch.google.com.rpz.zone. 3600 IN A 216.239.32.20
15
16 ;; AUTHORITY SECTION:
17 rpz.zone. 3600 IN NS LOCALHOST.
18
19 ;; Query time: 44 msec
20 ;; SERVER: 127.0.0.1#53(127.0.0.1)
21 ;; WHEN: Mon Aug 01 17:07:14 Daylight Time 2016
22 ;; MSG SIZE rcvd: 127
注意:请参阅第 13 行及其尾随的“.rpz.zone”。
nslookup
01 > server 127.0.0.1
02 Default server: 127.0.0.1
03 Address: 127.0.0.1#53
04 > www.google.com
05 Server: 127.0.0.1
06 Address: 127.0.0.1#53
07
08 Non-authoritative answer:
09 www.google.com canonical name = nosslsearch.google.com.rpz.zone.
10 Name: nosslsearch.google.com.rpz.zone
11 Address: 216.239.32.20
ping www.google.com -n 1
1 Pinging nosslsearch.google.com.rpz.zone [216.239.32.20] with 32 bytes of data:
2 Reply from 216.239.32.20: bytes=32 time=149ms TTL=45
3
4 Ping statistics for 216.239.32.20:
5 Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
6 Approximate round trip times in milli-seconds:
7 Minimum = 149ms, Maximum = 149ms, Average = 149ms
以上输出片段的摘要:rpz.zone 被添加到各处,这就是我想移动到根区域的原因。
这是我的
zone.root.db 文件
01 $TTL 1H
02 @ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
03 NS LOCALHOST.
04
05 nosslsearch.google.com A 216.239.32.20
06 google.com CNAME nosslsearch.google.com
07 www.google.com CNAME nosslsearch.google.com
08
我只想摆脱附加到响应中的 rp.zone!怎么办?
答案1
RPZ 区域具有特殊语义定义,这样区域的名称实际上与其操作无关。
事实上,选择的名称不应与实际区域冲突。从区域加载 RPZ 数据只是一种利用现有区域加载/同步机制的方法。
因此您不会想给 RPZ 区域命名.
或com
类似名称。但是,由于它是作为区域加载的,因此常规主文件规范确实适用于内容的解释方式。
例如,对于名为的区域example
,以下内容
www.google.com CNAME nosslsearch.google.com
方法
www.google.com.example. CNAME nosslsearch.google.com.example.
(除非明确覆盖$ORIGIN
)
虽然 RPZ 以某种方式定义所有者名称(最左列),以便在通过查询名称匹配时它会自动附加 RPZ 区域名称,
名称
QNAME 策略记录由请求的查询名称和解析以生成响应的 CNAME 记录目标触发。QNAME 策略记录的所有者名称是相对于策略区域的查询名称。
如果您提供本地数据,则按原样使用 CNAME 记录数据(右侧)。(即,当 CNAME 数据不是 RPZ 中定义的特殊情况之一时,例如rpz-drop.
,,等).
*.
本地数据
可以使用一组普通的 DNS 记录来回答查询。对于非该集合的记录类型的查询,将使用 NODATA 来回答。
一种特殊形式的本地数据是 CNAME,其目标是通配符,例如 *.example.com。在将星号 (*) 替换为查询名称后,其使用方式与普通 CNAME 相同。这种特殊形式的用途是将查询记录到围墙花园的授权 DNS 服务器中。
长话短说,你可能想要这样的东西:
www.google.com CNAME nosslsearch.google.com.