|
[color=blue] ------------------------------------------------------------------------------------------------------------------------ 注 ：该文参考了如下内容 ： A）isc bind FAQ B）netmanl 兄的大作 ：http://bbs./viewthread.php?tid=308556&extra=page%3D2 作者 ：ailms <ailms{@}263{dot}net> 版本 ：v1 最后修改 ：2006/12/14 14:22 ------------------------------------------------------------------------------------------------------------------------ [/color] [size=4]一、前言[/size] 提到 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 。 [color=red]问题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 呢？ [/color] [size=4]二、BIND 9.2 是如何建立 view 的？[/size] 关于这方面的配置可以参考 netman 兄的贴子 ： http://bbs./viewthread.php?tid=308556&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 [color=red]下面是主服务器上的配置 ：[/color] telecom view 部分 ：
unicoml view 部分 ：
[color=red]从服务器上的配置 ：[/color] telecom view 部分 ：
unicom view 部分 ：
[size=4]三、BIND 9.2 方式的缺陷？[/size] 使用上面的方式可什么缺点呢？ a）首先需要大量的 ip 地址。如果你有多个 view ，则需要配置多个 ip b）多个 ip 可能带来路由的问题 [color=red]有么有什么方法可以做到只用一个 ip 就可以实现多个 view 的目的呢？[/color] [size=4]四、使用 key 可以解决这一问题[/size] 还记得 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"; }; }; [size=4]五、过程分解[/size] 关键就是 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 的部分。 [size=4]六、实际测试[/size] 用模拟的联通 ip 作测试
用模拟的电信ip 作测试
可以看到两次查询返回了不同的地址，说明在查询这块已经没有问题了。 接下来测试的是 zone data file 的同步 测试 telecom view 的同步 现在 telecom vie 的 serial 是
现在修改 bob.com.telecom. 的 serial 为 5，并重新加载telecom 的 bob.com
检查从服务器的日志 引用： 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 文件 引用： [[email]root@dns2.bob.com[/email] => 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 也是一样的情况。 [size=4]七、总结[/size] 不知道经过上面的描述，你是否清楚整个思路了呢？最好配合 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 编辑 ] 網中人 回复于：2006-12-15 03:42:34 讚！！ 版主快了加精！ ^_^ vepeta 回复于：2006-12-15 10:29:58 好！有空我也试一下！ ailms 回复于：2006-12-15 11:08:41 多谢两位支持 ^_^ 引用： 发表于: 2006-12-15 03:42 主题： netman 兄的作息时间也太恐怖了吧 chinaglwo 回复于：2006-12-16 00:40:00 我也测试成功，方法基本和你相同，但是对过程和含义了解不够深刻 看了你的帖子，感觉弄通了不少东西 谢谢楼主啊 bsdunix 回复于：2006-12-16 12:18:58 那使用 TSIG key 来配置 view 有什么需要注意的呢？ a）key 在另一台 server 上不存在 问题1: 如何生成key?还是任意指定字母数字作为key? b）同一个名称的 key 在两台 server 上的内容不一样 问题2:必须一样还是必须不一样? ailms 回复于：2006-12-16 15:12:43 1）man dnssec-keygen 2）要一致。 ailms 回复于：2006-12-16 17:25:07 你可以对比一下我给的 server 语句和你写的 server 语句的格式有那些不同，尤其是少了什么标点符号。 下面是我原来用的 controls 语句 引用： inet 127.0.0.1 allow { localhost;} keys { rndckey; }; 现在我把它改为 引用： inet 127.0.0.1 allow { localhost;} keys { rndckey }; 再执行 ：
检查 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 回复于：2006-12-16 20:52:18 我重起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 [color=Red]Dec 16 11:34:17 dns1 named[21464]: loading configuration from '/etc/named.conf'[/color] 说明我的配置文件中没有语法错误。 但我的问题依然存在，如题:http://bbs./viewthread.php?tid=870609&page=1#pid6164533,请 ailms 兄 及各位指点，小弟不胜感激！ 或者我可以把机器信息给 ailms 及 网中人 。这个问题困惑我很久后才发现的这么好的文章。我一定要解决！！ Thanks very much ! [ 本帖最后由 gaochong 于 2006-12-16 20:56 编辑 ] ailms 回复于：2006-12-16 21:23:54 引用：原帖由 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 语句呢？ gaochong 回复于：2006-12-16 21:46:09 我正在修改。。。。 但为什么 view telcom 和 view cnc 的 zone transfer 没有问题呢？ 在多个view的情况，用TSIG你这种方法和dns server的ip（所属网通、铁通或者电信）有没有关系呢？ 请ailms兄 指点迷津！ gaochong 回复于：2006-12-16 22:57:47 请问 ailms兄 ，你的master/slave 是3个或者更多个view吗？ 可以把你的实际配置文件贴出来吗？ 或者发站内短信给我可以吗？ 谢谢！ 網中人 回复于：2006-12-17 00:03:45 那先別急著設多個 view， 先分一個 internet 跟 intranet 的，也就是外網跟内網。 等這個 ok 了，再繼續增加。 有時，心急吃不了熱湯丸。 gaochong 回复于：2006-12-17 08:13:15 谢谢網中人 斑竹 指点。。。。 view和zone transfer的原理我还不是特别清楚，要仔细看看书了。 希望 網中人 斑竹 也可以贴一篇 view 和 zone transfer 相关的文章。 现在先设internal和external2个view，如果有问题再麻烦 網中人 斑竹了。。。 谢谢 gaochong 回复于：2006-12-17 08:51:51 还不懂。。。。網中人 斑竹。 看了ISC.ORG的FAQ，如下： [QUOTE]Q: How can I make a server a slave for both an internal and an external view at the same time? When I tried, both views on the slave were transferred from the same view on the master. A: BIND 9.3 and later: Use TSIG to select the appropriate view. Master 10.0.1.1: key "external" { algorithm hmac-md5; secret "xxxxxxxx"; }; view "internal" { match-clients { !key external; 10.0.1/24; }; ... }; view "external" { match-clients { key external; any; }; server 10.0.1.2 { keys external; }; recursion no; ... }; Slave 10.0.1.2: key "external" { algorithm hmac-md5; secret "xxxxxxxx"; }; view "internal" { match-clients { !key external; 10.0.1/24; }; ... }; view "external" { match-clients { key external; any; }; server 10.0.1.1 { keys external; }; recursion no; ... }; [/QUOTE] 但我现在的master和slave都是公网IP，而且分别属于网通、铁通运营商。 这种情况下的internal、external 的 view 改如何实现呢？ gaochong 回复于：2006-12-17 11:07:48 [QUOTE] 五、过程分解 关键就是 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 的设定 [/QUOTE] 第4个过程我不是很理解，ailms 可以解释详细一点吗？？谢谢 ailms 回复于：2006-12-17 17:14:29 是的，我有3个 view（telecom、unicom、local），而且同步都正常 既然现在不行，那我们不烦一步步来，通常我会这样做 1）是不是 key 不对？用 ethereal 抓包，看 additional 部分 2）是 address list 有问题吗？ 3）view 的排列顺序有问题吗？因为 BIND 实际上不一定比较所有的 view 的 match-clients ，而是先匹配那个 match-clients ，就 返回那个 view 的数据。 先从这三方面入手，不行再慢慢找 [ 本帖最后由 ailms 于 2006-12-17 17:26 编辑 ] ailms 回复于：2006-12-17 17:25:13 引用：原帖由 gaochong 于 2006-12-17 11:07 发表 第4个过程我不是很理解，ailms 可以解释详细一点吗？？谢谢 BIND 会根据 view 的出现顺序，将请求的源地址和 match-clients 一个个做比较， 那个先匹配，就使用该 view 。所以 view 的排列也是很重要的。 gaochong 回复于：2006-12-17 20:23:18 谢谢 ailms 兄，真的感谢无私奉献的人们。。。 我修改后的配置文件如下： [QUOTE] slave中view crc配置如下： view "crc" { match-clients { key "crc-key"; !60.12.226.8; crc; }; allow-transfer { none; }; server 60.12.226.8 { keys "crc-key"; }; zone "." IN { type hint; file "named.ca"; }; zone "goupper.com" IN { type slave; masters { 60.12.226.8; }; file "goupper.com.zone.crc"; }; }; [/QUOTE] 但我的配置文件中有6个view，所以其他的view 也要花费不少时间来研究一下下view排列顺序了。 [ 本帖最后由 gaochong 于 2006-12-17 21:08 编辑 ] 網中人 回复于：2006-12-17 21:11:00 引用：原帖由 gaochong 于 2006-12-17 08:51 发表 但我现在的master和slave都是公网IP，而且分别属于网通、铁通运营商。 这种情况下的internal、external 的 view 改如何实现呢？ 我之前有寫過，不過有點舊了。我相信用 key 的方式是更好的方法。 既然已經有 ailms 兄的文章，我認為已經很足夠了。 雖然我沒弄過 key 的方法，但“由簡而繁”，是我一向的設定方針。給你參考一下。 ailms 回复于：2006-12-17 21:14:56 6 个 view ？需要这么多吗？ gaochong 回复于：2006-12-17 21:31:50 多谢 網中人 和 ailms 文章了。 但我更适应 TSIG 这种方法。 是的，包括了6个view。 在这个过程遇到了很多问题，相信到最后测试完毕还会有很多问题，到时再请教各位了。 Thanks very much ! [ 本帖最后由 gaochong 于 2006-12-18 12:01 编辑 ] ailms 回复于：2006-12-17 21:37:34 也要多谢 gaochong 的提问，看来我漏写了一些东西了 gaochong 回复于：2006-12-17 21:39:46 现在有3个view，master/slave运行稳定，解析、zone transfer 正常,但为什么dnsreport依然出现原来的错误呢？ 域名： goupper.com ，其中的warn 和 fail 见附件。请各位指点问题所在。谢谢。 [ 本帖最后由 gaochong 于 2006-12-17 21:54 编辑 ] dnsreport_warn_fail.rar ailms 回复于：2006-12-17 21:49:10 这个不确定。我想可能和 dnsreport.com 采取的方式有关。 例如它的 ip 不在你的所有 view 中，所以被所有的 view 都拒绝了；或者其他方面的原因。 btw ：我认为 dnsrepot.com 这样的 site 只能说有参考价值，不一定非要全部相信。 更应该相信的是 BIND 的 log 说什么。。 gaochong 回复于：2006-12-18 09:31:13 [QUOTE] 例如它的 ip 不在你的所有 view 中，所以被所有的 view 都拒绝了； [/QUOTE] 提醒了我。谢谢，看来我又要增加一个view。 網中人 回复于：2006-12-18 10:09:49 一般來說，不是有一個给 any 的 view 放在最後作 default 的嗎？ gaochong 回复于：2006-12-18 11:09:23 是这样的。呵呵。。。但是昨天测试，只有3个 view , default view 没有加。现在在加。 gaochong 回复于：2006-12-18 12:15:22 又碰到问题， ailms兄 。 过程分解中如下： [QUOTE] 4）从服务器对比每个 view 的 match-clients ，发现匹配 telcom 这个 view 的设定 [/QUOTE] 从服务器依据[color=Red]master的IP[color=Black]还是[/color]TSIG[/color]来对比每个 view的match-clients 呢？ 现在还是很困惑。 请 ailms 指教！ 谢谢！ [ 本帖最后由 gaochong 于 2006-12-18 12:17 编辑 ] ailms 回复于：2006-12-18 12:19:35 我想过程应该如此 ： 1）首先 notify 消息要通过 match-clients 这一关，也就是 key 或者 ip 的匹配 2）进入 view 后再根据 allow-notify 的 key 来判断。 gaochong 回复于：2006-12-18 12:27:41 [QUOTE] 我想过程应该如此 ： 1）首先 notify 消息要通过 match-clients 这一关，也就是 key 或者 ip 的匹配 2）进入 view 后再根据 allow-notify 的 key 来判断。 [/QUOTE] 我的疑问在于：第1步的详细过程。 同时[QUOTE] 进入view后在根据allow-nofity的key来判断[/QUOTE]，我的配置文件中没有配置allow-nofity.这应该是master的配置吧？ ailms 回复于：2006-12-18 12:37:27 1）根据 match-clients 中的排列顺序；这个你尽可以自己做实验的。 2）不是。从服务器上的。 gaochong 回复于：2006-12-18 16:17:39 哎呀．．．．．． 添加一个defalut view ,用了一个下午时间．．．．．． 不过还有２个view要添加．．．． How time flies ! ^_^ gaochong 回复于：2006-12-18 21:46:47 还有个问题请教： view view1 { match-clients { !ip1; key key1; acl1; }; ...................; }; 当ip1做为clien查询t时，是直接跳过view1 ？ 还是跳过 !ip1 继续查询key1 、acl1 ？ 困惑。。。。谢谢！ gaochong 回复于：2006-12-18 22:37:48 我做过测试，结论：直接跳过view1. 请各位指出是否正确。 谢谢！ alexa 回复于：2006-12-19 14:25:48 原先的两个dns服务器也打算用主从的 就是ip问题 比较麻烦 一直没有好的办法 ailms 的文章很棒 ：） gaochong 回复于：2006-12-19 14:27:11 IP不是最大问题。view才是最大的问题。。。。 ailms 回复于：2006-12-19 14:29:49 引用： 会员UID：471145 注册时间：2006-9-29 15:39 最后登录：2006-12-19 12:05 帖子总数： 1 精华帖子： 0 积分：1 lz 的处女贴竟然给了俺，真是感动死了。^_^ gaochong 回复于：2006-12-19 15:30:14 5个view的master/slave于2006-12-19 15：30完工！ 大家可以帮忙测试一下，test.goupper.com 电信（移动）返回60.191.3.140 ,网通（联通） 返回 60.12.226.6 ,铁通返回 222.46.18.254。 如有错误，请各位贴出，以便修改完善。 但还需要看看TSIG时zone transfer的构成分解！ Thanks a lot ! gaochong 回复于：2006-12-19 18:42:48 再次请教各位,我的域名(goupper.com)DNSREPORT现在还有2个warn,1个fail,其中fail我知道是何原因(MX反向解析没做),但2个warn不知如何解决(如下),请各位指点.在此不胜感激 1.[color=Red]Single Point of Failure[/color] WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2. 2.[color=Red]SPF record[/color] Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004). [ 本帖最后由 gaochong 于 2006-12-19 18:44 编辑 ] gaochong 回复于：2006-12-20 18:40:47 请各位老大出马.... bsdunix 回复于：2006-12-20 20:41:24 Dec 20 19:18:22 up named[578]: dumping master file: slave/cernet/tmp-zQjYBvI00p: open: permission denied Dec 20 19:18:22 up named[578]: transfer of 'glnc.edu.cn/IN' from 202.193.208.100#53: failed while receiving responses: permission denied Dec 20 19:20:35 up named[578]: zone glnc.edu.cn/IN/view_any: refresh: could not set file modification time of 'slave/telecom/glnc.edu.cn': permission denied Dec 20 19:33:06 up named[578]: dumping master file: slave/cernet/tmp-kLbi1BCcHM: open: permission denied Dec 20 19:33:06 up named[578]: transfer of 'glnc.edu.cn/IN' from 202.193.208.100#53: failed while receiving responses: permission denied Dec 20 19:47:58 up named[578]: dumping master file: slave/cernet/tmp-JOmo8eBv7L: open: permission denied Dec 20 19:47:58 up named[578]: transfer of 'glnc.edu.cn/IN' from 202.193.208.100#53: failed while receiving responses: permission denied Dec 20 19:52:36 up named[578]: zone 208.193.202.in-addr.arpa/IN/view_cernet: refresh: could not set file modification time of 'slave/cernet/rev.208': permission denied Dec 20 20:02:17 up named[578]: dumping master file: slave/cernet/tmp-1YPx8FoKu7: open: permission denied Dec 20 20:02:17 up named[578]: transfer of 'glnc.edu.cn/IN' from 202.193.208.100#53: failed while receiving responses: permission denied Dec 20 20:04:31 up named[578]: zone 208.193.202.in-addr.arpa/IN/view_any: refresh: could not set file modification time of 'slave/telecom/rev.208': permission denied Dec 20 20:15:27 up named[578]: dumping master file: slave/cernet/tmp-Fdoaqh6a9U: open: permission denied Dec 20 20:15:27 up named[578]: transfer of 'glnc.edu.cn/IN' from 202.193.208.100#53: failed while receiving responses: permission denied Dec 20 20:15:28 up named[578]: zone 209.193.202.in-addr.arpa/IN/view_any: refresh: could not set file modification time of 'slave/telecom/rev.209': permission denied Dec 20 20:20:08 up named[578]: zone glnc.edu.cn/IN/view_any: refresh: could not set file modification time of 'slave/telecom/glnc.edu.cn': permission denied Dec 20 20:20:50 up named[578]: zone 210.193.202.in-addr.arpa/IN/view_any: refresh: could not set file modification time of 'slave/telecom/rev.210': permission denied Dec 20 20:26:56 up named[578]: dumping master file: slave/cernet/tmp-P9uzJ4EFvS: open: permission denied Dec 20 20:26:56 up named[578]: transfer of 'glnc.edu.cn/IN' from 202.193.208.100#53: failed while receiving responses: permission denied gaochong 回复于：2006-12-20 21:22:30 这是slave的logs,master的logs可以帖出来吗？ bsdunix 回复于：2006-12-20 22:52:58 Dec 19 23:31:17 sun0 named[634]: starting BIND 9.3.2-P1 -t /var/named -u bind Dec 19 23:31:17 sun0 named[634]: command channel listening on 127.0.0.1#953 Dec 19 23:31:17 sun0 named[634]: command channel listening on ::1#953 Dec 19 23:31:17 sun0 named[634]: running bsdunix 回复于：2006-12-20 23:25:13 freebsd 6.1 gaochong 回复于：2006-12-20 23:38:23 无语... xing007008 回复于：2006-12-29 15:50:53 首先,要感谢ailms发表了这么优秀的文章. 我估计还有一些朋友(包括我)比较难明白关于这个key(key telecomkey),还有telecom_addr具体是怎么来的?楼上的可以详细说一下吗? ailms 回复于：2006-12-29 17:02:52 key 是用 rndckey 生成的，命令格式如下 ：
然后从生成的 key 文件中抽取出 algorithm 和 secret 两行，放到一个文件，例如 telecom.key ， 并把这个 key 定义为 telecomkey 就可以了。 2）至于 telecom_addr 如何来的，可以搜索一下 abel 兄的精华帖子就知道了。我这里只是举例而已。 xing007008 回复于：2006-12-29 17:19:58 现在明白了许多了.照你这样说telecomkey 和 unicomkey文件的内容是一样的吗? ailms 回复于：2006-12-29 17:27:07 至少名称不一样，内容可以一样。 不过你用上面的命令生成的 key 文件基本上是不可能相同的 xing007008 回复于：2006-12-29 21:01:45 呵呵.遇到问题还会找你. gaochong 回复于：2007-01-15 14:56:18 在此问下 ailms 兄 一个问题。 master用了 chroot,而slave没有用chroot,这样会有影响吗？ 谢谢！ ailms 回复于：2007-01-16 15:59:23 引用：原帖由 gaochong 于 2007-1-15 14:56 发表 在此问下 ailms 兄 一个问题。 master用了 chroot,而slave没有用chroot,这样会有影响吗？ 谢谢！ 这个没有试过。不过我认为不会有影响。 master 只是告诉 slave 要更新数据了，至于 slave 此后把数据写到什么位置，这不是 master 可以控制的。 supereyes 回复于：2007-04-03 18:08:20 加入精华，多谢楼主能提供这样好的实用性强、归纳性强的好文 [ 本帖最后由 supereyes 于 2007-4-3 18:10 编辑 ] gracet3 回复于：2007-10-30 22:40:33 主服务器信息： Oct 30 22:33:41 ns named[5021]: client 10.0.1.1#32932: view ChinaNet: request has invalid signature: TSIG chinanetkey: tsig verify failure (BADKEY) Oct 30 22:33:47 ns named[5021]: client 10.0.1.1#32932: view ChinaNet: request has invalid signature: TSIG cncnetkey: tsig verify failure (BADKEY) 从服务器信息： Oct 30 22:26:19 se named[5539]: zone test.com/IN/ChinaNet: refresh: failure trying master 10.0.1.2#53 (source 0.0.0.0#0): clocks are unsynchronized Oct 30 22:26:25 se named[5539]: zone test.com/IN/CNCNet: refresh: failure trying master 10.0.1.2#53 (source 0.0.0.0#0): clocks are unsynchronized 请问如何解决。。。TSIG key获取方式是在主DNS的机器上运行 dnssec-keygen -a HMAC-MD5 -b 128 -n HOST cncnetkey dnssec-keygen -a HMAC-MD5 -b 128 -n HOST chinanetkey 不知是否正确，然后从服务器配置的key是从这个cp过去的。。。 [ 本帖最后由 gracet3 于 2007-10-30 22:43 编辑 ] ailms 回复于：2007-10-31 12:04:56 请检查时间是否同步 不好意思，很久不碰 DNS 了，只能记得这个 ruochen 回复于：2007-10-31 17:16:49 一般的企业只是需要内部和外部的view吧 再加个default的view就应该够的 这个谁有好经验，共享下. ISP的话应该是分服务商的，也就是电信/联通/铁通/...之分 nicsky 回复于：2008-05-05 16:17:41 谢谢楼主了。 KnightE 回复于：2008-11-24 03:00:38 一个问题搞了我一天，终于弄通了，写出来希望能给和我一样新的新手一点帮助。 问题症状是： N个VIEW，有一个能同步，其他VIEW全部提示“BADKEY”，可任你设置这个KEY，一直提示错误。 查看NOTICE LOG，发现很奇怪的一个地方，主服务器在收到从服务器信息时，一律是能同步的那个VIEW的名字，再配上其他VIEW的KEY，当然一直错误了。 可为什么主服务器“不认”从服务器的VIEW，却又困扰了我好几个小时-__-!! 突然脑子一开窍，发现能同步的VIEW正是内网的VIEW……呵呵，高手们相信已经明白了，在我的VIEW的match-clients中，因为没有排除主、从服务器的IP，导致从服务器始终以内网VIEW向主服务器请求。简单用“！”排除出内网VIEW的范围即可。 其实是个小问题，因为缺乏经验（接触DNS服务器才两三天;P），很容易在小问题上栽跟头。 回头再看了看其他资料，其实也有提到将服务器IP从VIEW中去除的说明，只不过当时看的时候并没有明白用意。 算给本精华帖做个补充吧。Just for newbie:wink: xuxic 回复于：2009-04-22 19:40:22 楼主的配置是正确的，我是通过TSIG处理多view的同步的，我配置过程中不能同步的原因是：主服务器使用电信IP，从服务器使用网通IP, 后来把两台服务器的IP全改成电信的，就可以同步了。 当然解决过程中调了debug等级（rndc trace 5），也抓包分析过，修改了match-client等内容，最后还是没有同步起来，都改成电信IP才解决。 希望我经历能给大家带来一些借鉴，也希望大家帮我分析一下使用不同ISP的IP不成功的原因。 |
|
|
