BIND 9.3 下使用 TSIG key 简化 view 的设置

ailms

------------------------------------------------------------------------------------------------------------------------
注 ：该文参考了如下内容 ：

A）isc bind FAQ
B）netmanl 兄的大作 ：http://bbs.chinaunix.net/viewthr ... &extra=page%3D2
                 
作者 ：ailms <ailms{@}263{dot}net>
版本 ：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 兄的贴子 ：

http://bbs.chinaunix.net/viewthr ... &extra=page%3D2
      
前提条件就是必须主从服务器都有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 部分 ：
      

1. 
   
2.       
   
3. query-source address <master_ip_1>  port 32782;
   
4. 
   
5. notify-source <master_ip_1>;       
   
6. 
   
7. /* 确保对外发送的 notify 消息的源地址一定为 <mater_ip_1> ，这样才能被从服务器所识别 */
   
8.       
   
9. allow-transfer { <slave_ip_1>; };
   
10. 
    
11. /* 只有来自 <slave_ip_1> 的 zone transfer query 才允许 */
    
12.       
    

复制代码

      
unicoml view 部分 ：
      

1. 
   
2.       
   
3. query-source address <master_ip_2> port 32783;
   
4. 
   
5. notify-source <master_ip_2>;       
   
6. 
   
7. /* 确保对外发送的 notify 消息的源地址是 <master_ip_2> ,这样才能被从服务器所接受 */
   
8.       
   
9. allow-transfer { <slave_ip_2>; };
   
10. 
    
11. /* 只有来自 <slave_ip_2> 的 zone transfer 请求才允许 */
    
12.       
    

复制代码

      
从服务器上的配置 ：
      
telecom view 部分 ：
      

1. 
   
2.       
   
3. query-source address <slave_ip_1> port 32782;
   
4. 
   
5. /* 确保发送 soa query 时采用 <slave_ip_1> */
   
6.       
   
7. transfer-source  <slave_ip_1>;
   
8. 
   
9. /* 确保从服务器以 <slave_ip_1> 的源地址请求 Zone Transfer */
   
10.       
    
11. allow-notify { <master_ip_1>; };
    
12. 
    
13. /* 确保从服务器只接收来自内部view的主服务器 <master_ip_1> 的 notify 消息 */
    
14.       
    

复制代码

      
unicom view 部分 ：
      

1. 
   
2.       
   
3. query-source address <slave_ip_2> port 32783;
   
4. 
   
5. /* 确保从服务器以 <slave_ip_2> 发送 soa query */
   
6.       
   
7. transfer-source  <slave_ip_2>;       
   
8. 
   
9. /* 确保从服务器以 <slave_ip_2> 的源地址请求 Zone Transfer */
   
10.       
    
11. allow-notify { <master_ip_2>; };       
    
12. 
    
13. /* 确保从服务器只接收来自内部view的主服务器 <master_ip_2> 的 notify 消息 */
    
14. 
    

复制代码

      
      
三、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 <slave_ip>  { 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 <slave_ip> { 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 <master_ip> { keys telecomkey; };             // 向主服务器发送消息时，用 telecomkey 加密
        
       zone "bob.com" IN {

                type slave;

                masters { <master_ip>;};

                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 <master_ip> { keys unicomkey; };      // 向主服务器发送消息时，用 unicomkey 加密


zone "bob.com" IN {

                type slave;

                masters {<master_ip>;};

                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 作测试

1. 
   
2. Connection-specific DNS Suffix  . :
   
3. IP Address. . . . . . . . . . . . : 192.168.13.113
   
4. Subnet Mask . . . . . . . . . . . : 255.255.255.128
   
5. Default Gateway . . . . . . . . . : 192.168.13.1
   
6. 
   
7. C:\Program Files\dig>dig @192.168.13.114 test.bob.com. +short
   
8. 20.0.0.1
   

复制代码

用模拟的电信ip 作测试

1. 
   
2. Ethernet adapter nap:
   
3. 
   
4.         Connection-specific DNS Suffix  . :
   
5.         IP Address. . . . . . . . . . . . : 192.168.13.115
   
6.         Subnet Mask . . . . . . . . . . . : 255.255.255.128
   
7.         Default Gateway . . . . . . . . . : 192.168.13.1
   
8. 
   
9. C:\Program Files\dig>dig @192.168.13.114 test.bob.com. +short
   
10. 10.0.0.1
    
11. 
    
12. C:\Program Files\dig>
    

复制代码

可以看到两次查询返回了不同的地址，说明在查询这块已经没有问题了。

接下来测试的是 zone data file 的同步

测试 telecom view 的同步

现在 telecom vie 的 serial 是

1. 
   
2. [root@dns1 etc]# dig bob.com. SOA +short
   
3. dns1.bob.com. root.dns1.bob.com. 4 10800 900 604800 86400
   
4. [root@dns1 etc]#
   

复制代码

现在修改 bob.com.telecom. 的  serial 为 5，并重新加载telecom 的 bob.com

1. 
   
2. [root@dns1 etc]# rndc reload bob.com. in telecom
   
3. zone reload queued
   
4. [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 文件

[root@dns2.bob.com => 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 就会导致失败。


  自从在 ISC BIND FAQ 上看到了用 TSIG key 的方法，一直就想找个机会尝试一下。但由于其他原因一直没有动手，
  
直到前天晚上才真正动手试了一把。我想肯定有人早就做过了，而且做的得更好，在此向各位多多请教，希望不吝赐教！

[ 本帖最后由 ailms 于 2007-10-14 21:08 编辑 ]

網中人

讚！！

版主快了加精！   ^_^

vepeta

好！有空我也试一下！

ailms

多谢两位支持 ^_^

发表于: 2006-12-15 03:42    主题：

netman 兄的作息时间也太恐怖了吧

chinaglwo

我也测试成功，方法基本和你相同，但是对过程和含义了解不够深刻

看了你的帖子，感觉弄通了不少东西

谢谢楼主啊

bsdunix

那使用 TSIG key 来配置 view 有什么需要注意的呢？
        
        a）key 在另一台 server 上不存在
        
问题1:  如何生成key?还是任意指定字母数字作为key?


        b）同一个名称的 key 在两台 server 上的内容不一样

    问题2:必须一样还是必须不一样?

ailms

1）man dnssec-keygen

2）要一致。

ailms

你可以对比一下我给的 server 语句和你写的 server 语句的格式有那些不同，尤其是少了什么标点符号。

下面是我原来用的 controls 语句

inet 127.0.0.1 allow { localhost;} keys { rndckey; };

现在我把它改为

inet 127.0.0.1 allow { localhost;} keys { rndckey };

再执行 ：

1. 
   
2. [root@home etc]# rndc reload
   
3. rndc: 'reload' failed: failure
   
4. [root@home etc]#
   

复制代码

检查 messages 文件可以发现 ：

Dec 16 17:22:07 home named[4670]: /usr/local/bind-9.3.3//etc/named.conf:16: missing ';' before '}'
Dec 16 17:22:07 home named[4670]: reloading configuration failed: failure
[root@home etc]#

所以。。

gaochong

我重起named,成功，，如下：
[root@dns1 ~]# /usr/local/named/sbin/rndc reload
server reload successful
[root@dns1 ~]#
查看/var/log/messages没有错误提示，如下：
[root@dns1 ~]# /usr/local/named/sbin/rndc reload
server reload successful
[root@dns1 ~]# tail -8 /var/log/messages
Dec 16 11:19:17 dns1 named[21464]: client 222.46.18.12#32878: view crc: zone transfer 'goupper.com/AXFR/IN' denied
Dec 16 19:21:38 dns1 sshd(pam_unix)[23407]: session opened for user root by root(uid=0)
Dec 16 11:24:24 dns1 named[21464]: client 222.46.18.12#32879: view crc: zone transfer 'goupper.com/IXFR/IN' denied
Dec 16 11:24:25 dns1 named[21464]: client 222.46.18.12#32880: view crc: zone transfer 'goupper.com/AXFR/IN' denied
Dec 16 11:25:12 dns1 named[21464]: loading configuration from '/etc/named.conf'
Dec 16 11:25:42 dns1 named[21464]: client 222.46.18.12#32881: view crc: zone transfer 'goupper.com/IXFR/IN' denied
Dec 16 11:25:43 dns1 named[21464]: client 222.46.18.12#32882: view crc: zone transfer 'goupper.com/AXFR/IN' denied
Dec 16 11:34:17 dns1 named[21464]: loading configuration from '/etc/named.conf'

说明我的配置文件中没有语法错误。

但我的问题依然存在，如题:http://bbs.chinaunix.net/viewthr ... p;page=1#pid6164533,请 ailms 兄 及各位指点，小弟不胜感激！
或者我可以把机器信息给 ailms 及 网中人 。这个问题困惑我很久后才发现的这么好的文章。我一定要解决！！
Thanks very much !

[ 本帖最后由 gaochong 于 2006-12-16 20:56 编辑 ]

ailms

原帖由 gaochong 于 2006-12-16 20:52 发表
我重起named,成功，，如下：
[root@dns1 ~]# /usr/local/named/sbin/rndc reload
server reload successful
[root@dns1 ~]#
查看/var/log/messages没有错误提示，如下：
[root@dns1 ~]# /usr/local/named/s ...

并非这样就表示配置没有问题的。

有些配置是至关重要，出错了就会导致 BIND 无法正常运行。

有些错误不会影响 BIND 的运行，所以在 log 不一定会表现出来

为什么不试一下修改 server 语句呢？