【51CTO.com独家特稿】笔者在公司的工作之一是负责维护公司的CDN，基本上是天天打bind打交道；在用源码安装完一台新的bind9.4后准备做主从复制时，惊奇的发现居然出现了问题(主DNS是bind9.1):
这是在从DNS上出现的问题一：
- Mar 26 16:04:17 gdst named[18464]: client
- 115.207.47.199#20601: view any: query (cache) '112.2.5.221.in-
- addr.arpa/PTR/IN' denied
- Mar 26 16:04:17 gdst named[18464]: client
- 115.207.47.199#20602: view any: query (cache)
- 'dx.3158.com.domain/A/IN' denied
- Mar 26 16:04:17 gdst named[18464]: client
- 115.207.47.199#20603: view any: query (cache)
- 'dx.3158.com.domain/AAAA/IN' denied
- Mar 26 16:04:17 gdst named[18464]: client
- 115.207.47.199#20604: view any: query (cache) 'y163.net/A/IN'
- denied
- Mar 26 16:04:17 gdst named[18464]: client
- 115.207.47.199#20605: view any: query (cache)
- 'y163.net/AAAA/IN' denied
- Mar 26 16:04:18 gdst named[18464]: client
- 115.207.47.199#20606: view any: query (cache) '112.2.5.221.in-
- addr.arpa/PTR/IN' denied
- Mar 26 16:04:18 gdst named[18464]: client
- 115.207.47.199#20607: view any: query (cache)
- 'dx.3158.com.domain/A/IN' denied
- Mar 26 16:04:18 gdst named[18464]: client
- 115.207.47.199#20608: view any: query (cache)
- 'dx.3158.com.domain/AAAA/IN' denied
- Mar 26 16:04:18 gdst named[18464]: client
- 115.207.47.199#20609: view any: query (cache) 'y163.net/A/IN'
- denied
- Mar 26 16:04:19 gdst named[18464]: client
- 115.207.47.199#20610: view any: query (cache)
- 'y163.net/AAAA/IN' denied
- Mar 26 16:04:19 gdst named[18464]: client
- 115.207.47.199#20611: view any: query (cache) '112.2.5.221.in-
- addr.arpa/PTR/IN' denied
- Mar 26 16:04:19 gdst named[18464]: client
- 115.207.47.199#20612: view any: query (cache)
- 'dx.3158.com.domain/A/IN' denied
- Mar 26 16:04:19 gdst named[18464]: client
- 115.207.47.199#20613: view any: query (cache)
- 'dx.3158.com.domain/AAAA/IN' denied
- Mar 26 16:04:19 gdst named[18464]: client
- 115.207.47.199#20614: view any: query (cache) 'y163.net/A/IN'
- denied
- Mar 26 16:04:20 gdst named[18464]: client
- 115.207.47.199#20615: view any: query (cache)
- 'y163.net/AAAA/IN' denied
- Mar 26 16:04:21 gdst named[18464]: client
- 60.215.129.103#53455: view any: query (cache)
- 'www.google.com/A/IN' denied
- Mar 26 16:04:49 gdst named[18464]: client
- 121.14.128.68#53455: view CHINANET: query (cache)
- 'www.google.com/A/IN' denied
- Mar 26 16:04:59 gdst named[18464]: client
- 221.171.1.147#53455: view CHINANET: query (cache)
- 'www.google.com/A/IN' denied
发现新版的对cache的处理有所改变
新版本的BIND对 allow-query 有着不同的处理，新增加了一个allow-query-cache 的选项。
- QUOTE:allow-query Specifies which hosts are allowed to ask
- ordinary DNS questions. allow-query may also
- be specified in the zone statement, in which case it overrides the
- options allow-query statement.
- If not specified, the default is to allow queries from all hosts.
- QUOTE:allow-query-cache Specifies which hosts are allowed to
- get answers from the cache. The default is the
- builtin acls localnets and localhost.
- The way to set query access to the cache is now via allow-query-
- cache. This differs from earlier
- versions which used allow-query.
BIND 9.4 的手册上还特别注释了
QUOTE:allow-query-cache is now used to specify access to the
cache.
解决方法如下：即在从DNS的options里添加一条：
- key "rndc-key" {
- algorithm hmac-md5;
- secret "Rox3q+3f0gp8MKyQXx2zWw==";
- };
- controls {
- inet 127.0.0.1 port 953
- allow { localhost; } keys { "rndc-key"; };
- };
- options {
- version "9.8.12";
- directory "/var/named";
- pid-file "named.pid";
- allow-query { any; }; //此处为添加
- };
另一个关于主从复制的问题就是，如果bind采用了智能view功能的话，如果主DNS是电信的IP的话，从DNS非电信线路(即铁通或其它)，如果均采用单IP是不能进行主从复制的，除非是双IP；如果只有单IP的话可采取bind的TSIG key来解决此问题。在处理上述问题时，得到了linuxtone站长netseek帮助，这里表示感谢。
维护的DNS服务器主要有三个:一主一从一备，由于公司的架构采用了CDN方案，所以namd.conf针对"okspace.com"的出现位置就有三处:即电信、网通及其它，加上三个服务器，每次手动用vim删除okspace.com时就必须修改九处，维护起来很麻烦；更为不爽的是，有些zone经常需要删除，特别的麻烦，所以特地写了个shell以减清自己的负担，达到安全删除的目的。变量domain中的文件内容自己可以定义，签于生产环境下bind都是源码安装，这里就以named.conf文件为主。
- vim /root/delzone.sh
- #!/bin/bash
- domain='zone\ "okspace.cn"'
- if [ -e /var/named/chroot/etc/named.conf ];then
- sed -i "/$domain/,/};/d" /var/named/chroot/etc/named.conf
- else
- sed -i "/$domain/,/};/d" /var/named/chroot/var/named/named.rfc1912.zones
- fi
用sftp将此脚本传到其它DNS服务器，很轻松的完成工作，用此语法结合grep -rl可写出更强大的删除脚本；用shell脚本已经很长时间了，越来越喜欢它。
关于DNS主从复制，这里说明下：
①如果主DNS和从DNS都是用root用户的，不需要考虑权限问题，即/var/named写权限不需要更改任何地方，即不需要更改为named或给7权限。
②多使用rndc,这命令强大无比;配置时多用tail -f /var/log/messages，我就是系统日志来排错的
③如果测试结果中出现Non-authoritative answer: //非授权的回答,说明来自其他DNS服务器或缓存.
④启动区域传输的机制有以下3种:一是辅DNS服务器刚启动;二是SOA记录中的刷新间隔到达;三是master DNS设置了主动通知辅DNS数据有变化。监于生产服务器的严谨性，如果有问题，麻烦通知下抚琴煮酒——yuhongchun027@163.com，我会***时间改正。
【51CTO独家特稿，非经授权谢绝转载，合作媒体转载请注明原文出处及！】
