出现错误我们一般通过日志来排查故障：tail /var/log/message
1> 发现从服务器未同步主服务器域信息，从日志中发现如下错误：
zone test.com/IN: loading master file test.com: permission denied
这个错误一般是因为从服务器的区域文件的权限问题：
[root@localhost named] ll slaves/test.salve
-rw-r----- 1 root root 436 05-17 20:54 slaves/test.salve
从这里可以看出所有者和所有组都为root，而从主服务器传送区域文件是named用户，所以我们需要修改下文件权限：
[root@localhost named] chown named.named slaves/test.salve
[root@localhost named] service named restart
这个问题出现的原因是由于我们创建这个文件的时候，没有考虑文件权限，导致出现这个问题。直接复制/var/named/named.local这个文件后再修改的，建议复制过程中使用-p参数。这样就避免了cp后再修改权限的步骤。
从这里可以看出所有者和所有组都为root，而从主服务器传送区域文件是named用户，所以我们需要修改下文件权限：
[root@localhost named] chown named.named slaves/test.salve
[root@localhost named] service named restart
这个问题出现的原因是由于我们创建这个文件的时候，没有考虑文件权限，导致出现这个问题。直接复制/var/named/named.local这个文件后再修改的，建议复制过程中使用-p参数。这样就避免了cp后再修改权限的步骤。
2> 主DNS服务器修改记录或添加区域辅助DNS同步不过去，或者需要很长时间。
这样如果在现实生活中，会造成各地访问的结果不同。所以有必要研究一下主DNS服务器上修改完成后如何快速的同步给其它辅助的DNS。
为了查清故障的原因，这个时候我分别在各个DNS服务器上开启两个终端，在第一个终端输入命令tail -f /var/log/messages动态监控日志；另一个终端中重启DNS服务。发现没有产生任何日志。这个时候，思考了一下主辅DNS的工作原理，每次主DNS修改完成后重启服务会传送notify值，但是这里却没有传送。再次回到配置文件中检查相关字段发现没有定义。这个字段可以在named.conf中options字段中声明。也可以在单个区域文件中声明。
notify yes;
also-notify{ 192.168.2.163;}
also-notify{ 192.168.2.163;}
3> 主服务器更新区域文件后从服务器并能更新，但依旧无法解析
主服务器上更新区域后，但是从服务器却没有更新，但是删除从服务器上区域文件后，重新启动服务器才行，说明丛服务器是可以更新区域文件过来的，但是为什么却无法解析呢？查看日志：
client 192.168.2.164#53319: received notify for zone ‘2.168.192.in-addr.arpa‘
May 15 18:30:37 localhost named[15926]: zone 2.168.192.in-addr.arpa/IN: notify from 192.168.2.164#53319: zone is up to date
May 15 18:30:38 localhost named[15926]: client 192.168.2.164#53319: received notify for zone ‘test.com‘
May 15 18:30:38 localhost named[15926]: zone test.com/IN: notify from 192.168.2.164#53319: zone is up to date
May 15 18:30:37 localhost named[15926]: zone 2.168.192.in-addr.arpa/IN: notify from 192.168.2.164#53319: zone is up to date
May 15 18:30:38 localhost named[15926]: client 192.168.2.164#53319: received notify for zone ‘test.com‘
May 15 18:30:38 localhost named[15926]: zone test.com/IN: notify from 192.168.2.164#53319: zone is up to date
从日志可以看出，更新是可以的，但是每次更新却提示说zone是最新的，但是我明明是修改过区域文件的啊，所以这里需要了解下更新传输的过程，Slave DNS服务器是在对比查询结果中的serial值，如果serial值不大于本机的话将结束数据同步过程，
Serial﹕其格式通常會是“年月日+修改次序” 所以在更新区域文件请同时修改Serial，我们修改后，再查日志：
May 15 18:46:04 localhost named[4820]: client 192.168.2.163#47796: transfer of ‘test.com/IN‘: AXFR-style IXFR started
May 15 18:46:04 localhost named[4820]: client 192.168.2.163#47796: transfer of ‘test.com/IN‘: AXFR-style IXFR ended
May 15 18:46:04 localhost named[4820]: client 192.168.2.163#47796: transfer of ‘test.com/IN‘: AXFR-style IXFR ended
在解决问题的过程中有的朋友说将SOA中的Refresh值修改小一点，没错！但是这个值什么时候生效呢？当我们主DNS服务器上修改完成后重启服务，会主动传送notify值，如果辅助DNS服务器没有收到才参考Refresh，Refresh 不成功,则参考Retry ，Retry 一直不成功, 则参考 Expire，如果Expire也不成功，则选择放弃zone transfer的过程。
- 上一篇:详解BIND日志各种格式
- 下一篇:IP地址子网掩码及其应用