------------------------------------------------------------------------------------------------------------------------
注 ：该文参考了如下内容 ：
A）isc bind FAQ
B）netmanl 兄的大作 ：
作者 ：ailms
版本 ：v1
最后修改 ：2006/12/14 14:22
------------------------------------------------------------------------------------------------------------------------
一、前言提到 BIND 9，相信大家对于 view 功能一定有所耳闻了吧。
view 的好处有下面几点 ：a）节省主机资源。原来可能需要一台 DNS server 对外，一台对内服务。
现在有了 view ，可以只使用一台 server 就实现上面的功能
b）能够根据查询者（外部 nameserver 或者内部 nameserver ）的 ip 作出判断，对同一个域名或者 ip 返回不同的结果。
针对当前国内的互联互通情况， 这个可能是大家喜欢用 view 的原因。
不过 view 的使用也带来了一些问题 ：a）首先就是配置的复杂性也增加了。
b）其次是资料的同步问题
假设下面的情况 ：如果你的主服务器上有两个 view ，一个为 telecom ，一个为 unicom 。
假设这两个 view 都有一个 zone : bob.com.
现在你修改了 unicom 的 bob.com. 的 zone data 文件 : bob.com.telecom ，
紧接着你执行了 rndc reload bob.com 。
问题1 ：这时你 reload 的是那个 view 的 bob.com. 的数据呢？
问题2 ：即使 reload 的是 telecom view 的 bob.com. ，主服务器向从服务器发送了一个 notify 消息。
从服务器如何知道需要更新 telecom view 的 bob.com. 的数据呢？有两个 bob.com. ，有什么方法可以区分这个 notify 究竟对应那个 view ？
问题3 ：假设从服务器按照 SOA 中的 refresh 字段定时查询主服务器上的 bob.com. 的 serial ，主服务器如何知道应该返回那个 view 的 bob.com. 的 serial 呢？
二、BIND 9.2 是如何建立 view 的？关于这方面的配置可以参考 netman 兄的贴子 ：
前提条件就是必须主从服务器都有2个或者2个以上的ip才好做。
假设 主服务器的 ip 为 master_ip_1，master_ip_2；分别用于 telecom view 和 unicom view
假设从服务器的 ip 为 slave_ip_1，slave_ip_2；分别用于 telecom view 和 unicom view
下面是主服务器上的配置 ：telecom view 部分 ：
query-source address port 32782;
notify-source ;
/* 确保对外发送的 notify 消息的源地址一定为 ，这样才能被从服务器所识别 */
allow-transfer { ; };
/* 只有来自 的 zone transfer query 才允许 */
unicoml view 部分 ：
query-source address port 32783;
notify-source ;
/* 确保对外发送的 notify 消息的源地址是 ,这样才能被从服务器所接受 */
allow-transfer { ; };
/* 只有来自 的 zone transfer 请求才允许 */
从服务器上的配置 ： telecom view 部分 ：
query-source address port 32782;
/* 确保发送 soa query 时采用 */
transfer-source ;
/* 确保从服务器以 的源地址请求 Zone Transfer */
allow-notify { ; };
/* 确保从服务器只接收来自内部view的主服务器 的 notify 消息 */
unicom view 部分 ：
query-source address port 32783;
/* 确保从服务器以 发送 soa query */
transfer-source ;
/* 确保从服务器以 的源地址请求 Zone Transfer */
allow-notify { ; };
/* 确保从服务器只接收来自内部view的主服务器 的 notify 消息 */
三、BIND 9.2 方式的缺陷？使用上面的方式可什么缺点呢？
a）首先需要大量的 ip 地址。如果你有多个 view ，则需要配置多个 ip
b）多个 ip 可能带来路由的问题
有么有什么方法可以做到只用一个 ip 就可以实现多个 view 的目的呢？四、使用 key 可以解决这一问题还记得 TSIG key 吗？ rndc ，allow-* 语句都经常要用到它。为什么它可以用来简化 view 的设置呢？
因为一旦使用 TSIG ，则两台 server 之间的通信都会用指定的 key 进行标识；通信双方必须具有一样的 key ，如果 key 不一致，则另一方会拒绝请求。
是否可以从这点推广到 view 的配置呢？
答案是可以的。
下面以具体的配置为例说明 ：（注意，只列出部分语句而已 ！！）
主服务器方面 ：
view "telecom" IN { // 定义一个名为 telecom 的 view
match-clients { key telecomkey ; telecom_addr; }; // 范围是匹配那些用 telecomkey 加密的，以及 telecom_addr
recursion no; // 禁止处理来自 telecom 的主机的递归请求
allow-transfer { key telecomkey; }; // 只允许用 telecomkey 加密过的 zone transfer 请求
server { keys telecomkey; }; // 向从服务器发送消息时，用 telecomkey 加密
zone "bob.com" IN {
type master;
file "/usr/local/bind-9.3.3/data/bob.com.telecom";
};
};
view "unicom" IN { // 建立一个名为 unicom 的 view
match-clients { key unicomkey ; unicom_addr; }; // 范围是匹配那些用 unicomkey 加密的，以及 unicom_addr 中的地址
recursion no; // 禁止处理来自 unicom 的递归请求
allow-transfer { key unicomkey;}; // 只允许用 unicom 加密过的 zone transfer 请求
server { keys unicomkey; }; // 向从服务器发送消息时，用 unicomkey 加密
zone "bob.com" IN {
type master;
file "/usr/local/bind-9.3.3/data/bob.com.unicom";
};
};
从服务器方面：
view "telecom" IN { // 定义一个名为 telecom 的 view
match-clients { key telecomkey ; telecom_addr; }; // 范围是匹配那些用 telecomkey 加密的，以及 telecom_addr
recursion no; // 禁止处理来自 telecom 的递归请求
allow-transfer { none;}; // 禁止任何人向从服务器请求 zone transfer
server { keys telecomkey; }; // 向主服务器发送消息时，用 telecomkey 加密
zone "bob.com" IN {
type slave;
masters { ;};
file "/usr/local/bind-9.3.3/data/bob.com.telecom.slave";
};
};
view "unicom" IN { // 建立一个名为 unicom 的 view
match-clients { key unicomkey ; unicom_addr; }; // 范围是匹配那些用 unicomkey 加密的，以及 unicom_addr 中的地址
recursion no; // 禁止处理来自联通 view 的递归请求
allow-transfer {none;}; // 禁止所有人向从服务器请求 zone transfer
server { keys unicomkey; }; // 向主服务器发送消息时，用 unicomkey 加密
zone "bob.com" IN {
type slave;
masters {;};
file "/usr/local/bind-9.3.3/data/bob.com.unicom.slave";
};
};
五、过程分解 关键就是 match-clients 和 server 语句 ，下面我就针对 “前言”部分提出的问题对具体问题进行一步步的分解 ：
1）你修改并 reload 了 telecom view 的 bob.com. 这个 zone 。注意！正确的命令是 rndc reload bob.com. IN telecom ，记得加上后面的 "IN telecom‘ 。
2）主服务器将向从服务器发送一个 notify 消息，这个消息是用 telecomkey 标识过的。
（主→从 ：notify）
3）当从服务器收到这个 notify 消息时，会根据消息尾部的 TSIG 部分找出 key 的名称 ：telecomkey 。
4）从服务器对比每个 view 的 match-clients ，发现匹配 telcom 这个 view 的设定
5）从服务器返回一个 notify response 消息，根据 telecom view 的 server 语句，用 telecomkey 加密并发给主服务器。
（从→主 ：notify response）
6）接着从服务器就会启动 soa query，同样该 query 也是用 telecomkey 加密的。（从→主 ：soa query）
7）主服务器收到这个 soa query 后，发现是用 telecom key加密的 ，返回 telecom 的 bob.com. SOA 记录，并用 telecomkey 进行表示
（主→从 ：soa query response）
8）从服务器在收到来自主服务器的 response 后，和它自己 telecom view 的 bob.com zone 的 serial 比较，发现的确是增大了
8）从服务器向主服务器发送 tcp 消息，请求 zone transfer （从→主 ：zone transfer 请求）
9）主服务器检查 telecom view 的 allow-transfer ，发现该请求是以 telecomkey 加密的，则允许进行 zone transfer
10）主服务器返回 telecom view 的 bob.com 这个 zone 的数据（来自文件 bob.com.telecom）
（主→从 ：zone transfer 开始）
11）zone transfer 完成，主从服务器关闭 TCP 连接 （zone transfer 完成）
下面是整个过程的截图 ：（参考第 52 - 69 步）
注意，看到第二个窗口下面的 ”additional record“部分吗？这就是 TSIG key 的部分。
六、实际测试用模拟的联通 ip 作测试
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.13.113
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 192.168.13.1
C:\Program Files\dig>dig @192.168.13.114 test.bob.com. +short
20.0.0.1
用模拟的电信ip 作测试
Ethernet adapter nap:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.13.115
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 192.168.13.1
C:\Program Files\dig>dig @192.168.13.114 test.bob.com. +short
10.0.0.1
C:\Program Files\dig>
可以看到两次查询返回了不同的地址，说明在查询这块已经没有问题了。
接下来测试的是 zone data file 的同步
测试 telecom view 的同步现在 telecom vie 的 serial 是
[root@dns1 etc]# dig bob.com. SOA +short
dns1.bob.com. root.dns1.bob.com. 4 10800 900 604800 86400
[root@dns1 etc]#
现在修改 bob.com.telecom. 的 serial 为 5，并重新加载telecom 的 bob.com
[root@dns1 etc]# rndc reload bob.com. in telecom
zone reload queued
[root@dns1 etc]#
检查从服务器的日志
14-Dec-2006 13:49:29.528 notify: info: client 192.168.13.114#32772: view telecom: received notify for zone 'bob.com': TSIG 'telecomkey'
14-Dec-2006 13:49:29.531 xfer-in: info: transfer of 'bob.com/IN' from 192.168.13.114#53: connected using 192.168.13.116#32784
14-Dec-2006 13:49:29.535 xfer-in: info: transfer of 'bob.com/IN' from 192.168.13.114#53: end of transfer
再检查从服务器上的 bob.com.telecom.slave 文件
[ => data]#cat bob.com.telecom.slave
$ORIGIN .
$TTL 86400 ; 1 day
bob.com IN SOA dns1.bob.com. root.dns1.bob.com. (
5 ; serial
10800 ; refresh (3 hours)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dns1.bob.com.
NS dns2.bob.com.
可以看到从服务器的 bob.com.telecom.slave 文件已经更新了。
同样，unicom view 也是一样的情况。
七、总结不知道经过上面的描述，你是否清楚整个思路了呢？最好配合 ethereal 或者 tcpdump 进行试验会更好。
那使用 TSIG key 来配置 view 有什么需要注意的呢？
a）key 在另一台 server 上不存在
b）同一个名称的 key 在两台 server 上的内容不一样
c）两台 server 的时间不同步，导致 TSIG key 验证通不过。所以最好两台 server 用 ntp 进行同步。
这种情况比较隐蔽，需要特别注意。经过试验，两台 server 如果时间相差超过 5min 就会导致失败。
阅读(1988) | 评论(1) | 转发(0) |
