DNS主备不一致的原因

DNS主备不一致的原因:

1DNS主备服务器时间不能相差太久

2、序列号必须是主配置文件中zone序列号必须大于原序列号,否则导致DNS同步不成功。

Linux主辅dns数据不同步故障排除

在互联网中,我们知道任何一台提供应用服务的主机(例如:HTTPFTP等)都有它一个便于记忆DomainName,这些名称给用户带来了许多便利。但是,有些时候这些服务却对我们这些维护人员显得有些不“厚道”。本文将介绍DNS主辅配置过程中常遇到的配置问题以及排除方法。

我们有必要了解一下主辅DNS区域复制原理:如下图3所示主辅DNS服务器数据同步的过程,首先masterDNS服务器每次修改完成并重启服务后,将传送notify给所有的slaveDNS服务器。slave DNS服务器将查询master服务器的SOA记录,master DNS服务器收到请求后将SOA记录发送给Slave DNS服务器,Slave DNS服务器收到后同时对比查询结果中的serial值,如果serial值不大于本机的话将结束数据同步过程;但是如果serial值大于本机的话,slave DNS将发送zonetransfer请求要求(AXFR/IXFR)。Master响应zone transfer请求并传送结果,直到整个slave更新完成。

整体的同步过程如上所述,但是如何将这些原理体现在相关的配置文件中,这里以创建域名[url]www.qiuri.com[/url]记录为例:

测试平台:RedHatEnterprise Linux 5 Server update 2

所需软件包列表:

软件包名称

作用

bind-libs

包含DNS的库文件

Bind-9

DNS服务器软件,安装此软件前需要安装libs

caching-nameserver

配置文件模板

bind-utils

DNS查询工具软件

bind-chroot

使DNSchroot模式下运行,增强安全性(选择性安装)

根据你使用的安装包安装相应的软件,这里我使用系统自带的rpm包,配置yum本地更新源后,使用命令yuminstall bind*进行安装。使用yum安装的好处是能够自动处理安装过程中包的连带性,但是有时候也安装了一些不必要的程序到你的系统。

安装完成后第一件需要注意的事情是“查看你是否安装了bind-chroot这个包”这个程序的主要功能是:将DNS服务器在chroot模式下运行,在这种模式下运行的话,它会将所有和DNS相关的文件都锁定到/var/named/chroot目录下,就是说bind的访问范围仅仅定位于这个目录中,无法进一步提升到系统中的其它目录。这样可以提高系统的安全性。这样听起来很美,但是配置起来会出现许多的问题,建议不要使用。如果你使用了的话,所有配置修改需要到/var/named/chroot下,例如配置文件在/var/named/chroot/etc/named.conf

[root@master ~]#rpm q bind-chroot

由于RedHat AS 5安装后默认的配置文件名称named.caching-nameserver.conf/etc/named.caching .zones组成。修改配置文件名称:

[root@master ~]#mv /etc/named.caching-nameserver.conf/etc/named.conf

[root@master ~]#mv /etc/named. caching .zones /etc/named. zones

修改主DNS服务器上的配置文件,修改结果如下:

[root@master~ ]# vi /etc/named.conf

//

// named.caching-nameserver.conf

省略若干注释

options {

listen-on port 53 { 10.1.1.1; };

listen-on-v6 port 53 { ::1; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt";

query-source port 53;

query-source-v6 port 53;

allow-query { any; };

};

include "/etc/named.zones";

[root@master ~]#

修改/etc/named.zones文件,添加相关字段创建正向区域,添加内容如下:

[root@master~]# vi /etc/named.zones

// named.rfc1912.zones:

省略若干注释和若干默认区域

zone "qiuri.com" IN {

type master;

file "qiuri.com";

allow-transfer { 10.1.1.2; };

allow-update { none; };

};

[root@master~]#

在/var/named创建相关区域文件qiuri.com内容如下所示:

[root@master~ ]# cat /var/named/qiuri.com

$TTL 86400

@ IN SOA master.qiuri.com. root.master.qiuri.com. (

2008111305 ; Serial

28800 ; Refresh

14400 ; Retry

3600000 ; Expire

86400 ) ; Minimum

IN NS master.qiuri.com.

IN NS slaves.qiuri.com.

www IN A 10.1.1.1

ftp IN A 3 10.1.1.1

[root@master~ ]#

由于是测试我这里就不建立许多的区域了,在辅助DNS上的配置几乎一样,只需要将named.conf配置文件中的listen-on port 53 中的IP地址字段修改为辅助DNS服务器即可。

[root@ slave~ ]# vi /etc/named.conf

//

// named.caching-nameserver.conf

省略若干注释

options {

listen-on port 53 { 10.1.1.2; };

省略其它和主DNS服务器相同字段

include "/etc/named.zones";

[root@ slave~ ]#

/etc/named.zones配置文件中将区域类型修改为slave,并指定主DNS服务器IP即可:

[root@ slave~]# vi /etc/named.zones

// named.rfc1912.zones:

省略若干字段。。。。。。

zone "qiuri.com" IN {

type slave;

file "slaves/qiuri.com";

masters { 10.1.1.1; };

allow-update { none; };

};

[root@ slave~]#

注意:修改每台DNS服务器自己为DNS服务器,相关配置文件为/etc/resolv.conf。

将所有配置完成后我们分别在主辅DNS上执行命令servicenamed start启动服务。

故障一:

DNS上使用ping命令测试,发现了第一个故障:启动服务过程中没有任何的错误提示,ping域名的时候却显示没有这个域名。

故障分析:通过ping域名的时候,我们得知没有这个域名的回应值,这表明这个区域没有生效,但是到底是什么原因导致区域没有生效呢?这个时候不要茫然,去看看日志吧!

[root@master~]# tail /var/log/messages

省略若干…

Nov 21 20:55:57 localhost named[7113]: zone qiuri.com/IN: loadingmaster file qiuri.com: permission denied

Nov 21 20:55:57 localhost named[7113]: zone localdomain/IN: loadedserial 42

Nov 21 20:55:57 localhost named[7113]: zone localhost/IN: loadedserial 42

Nov 21 20:55:57 localhost named[7113]: running

[root@master~]#

黎明前的黑暗终于度过,一行行的日志终于看完,发现在加载qiuri.com的时候出现了permission denied的提示,就是说加载文件时被拒绝了。为什么会拒绝呢?我们先查看一下这个文件的属性吧?

[root@master~]# ll /var/named/qiuri.com

-rw-r----- 1 root root 436 11-21 20:54 /var/named/qiuri.com

[root@master~]#

发现这个文件的所有者是root,属组也是root,但是由于DNS服务使用named这个用户启动服务,难怪会拒绝了呢。那修改一下吧!

[root@master~]#chown named.named /var/named/qiuri.com

修改完成后重启dns服务,使配置生效。

[root@master~]#service named restart

再次查看日志,发现已经成功加载。

[root@master~]# tail -5 /var/log/messages

省略若干... ...

Nov 21 21:11:46 localhost named[7217]: zone qiuri.com/IN: loadedserial 2008111305

Nov 21 21:11:46 localhost named[7217]: zone localdomain/IN: loadedserial 42

Nov 21 21:11:46 localhost named[7217]: zone localhost/IN: loadedserial 42

Nov 21 21:11:46 localhost named[7217]: running

[root@master~]#

总结:这个问题出现的原因是由于我们创建这个文件的时候,没有考虑文件权限,导致出现这个问题。如果有的朋友不是手工编辑的这个文件,而是直接复制/var/named/named.local这个文件后再修改的,建议复制过程中使用-p参数。这样就避免了cp后再修改权限的步骤。

接着迫不及待的去启动了辅助DNS的服务,之后去查看/var/named/slaves中是否存在qiuri.com这个区域文件。发现成功复制过来。

[root@ slave ]# ls /var/named/slaves/

qiuri.com

[root@ slave ]#

到这个时候我们的测试还没有结束,继续进行中,首先我们再次回到主DNS服务器上编辑qiuri.com区域文件,增加主机记录,修改serial值。

[root@master ]# cat /var/named/qiuri.com

$TTL 86400

@ IN SOA master.qiuri.com. root.master.qiuri.com. (

2008111306 ; Serial

28800 ; Refresh

14400 ; Retry

3600000 ; Expire

86400 ) ; Minimum

IN NS master.qiuri.com.

IN NS slaves.qiuri.com.

www IN A 10.1.1.1

ftp IN A 10.1.1.1

down IN A 10.1.1.1

[root@master~]#

修改完成后,使用servicenamed reload重新加载配置文件,到辅助dns上验证我们添加的记录是否同步过来。但是再次失望了,故障又发生了。

故障二:

主DNS服务器修改记录或添加区域辅助DNS同步不过去,或者需要很长时间。这样如果在现实生活中,会造成各地访问的结果不同。我们有必要研究一下主DNS服务器上修改完成后如何快速的同步给其它辅助的DNS。

故障分析:

为了查清故障的原因,这个时候我分别在各个DNS服务器上开启两个终端,在第一个终端输入命令tail -f/var/log/messages动态监控日志;另一个终端中重启DNS服务。发现没有产生任何日志。这个时候,思考了一下主辅DNS的工作原理,每次主DNS修改完成后重启服务会传送notify值,但是这里却没有传送。再次回到配置文件中检查相关字段发现没有定义。这个字段可以在named.conf中options字段中声明。也可以在单个区域文件中声明。

这里在qiuri.com的zone中添加also-notify {10.1.1.2; };值。

[root@master~]#

zone "qiuri.com" IN {

type master;

file "qiuri.com";

also-notify { 10.1.1.2; };

allow-transfer { 10.1.1.2; };

allow-update { none; };

};

[root@master~]#

注意:如果要在options中声明,可以使用notify yes;即可。

再次加载服务,发现监控的日志开始有相应的请求和发送的字段出现。主DNS服务器的日志如下:

[root@master ~]#tail -f /var/log/messages

Nov 13 16:17:38 master named[3159]: zone qiuri.com/IN: sendingnotifies (serial 2008111306)

Nov 13 16:18:57 master named[3159]: client 10.1.1.2#45757: transferof 'qiuri.com/IN': AXFR-style IXFR started

Nov 13 16:18:57 master named[3159]: client 10.1.1.2#45757: transferof 'qiuri.com/IN': AXFR-style IXFR ended

[root@master ~]#

辅助DNS服务器上日志显示如下:

[root@ slave~ ]#tail -f /var/log/messages

Nov 14 08:12:55 ns named[6014]: running

Nov 14 08:12:55 ns named[6014]: zone qiuri.com/IN: sending notifies(serial 2008111306)

Nov 14 08:15:10 ns named[6014]: client 10.1.1.1#1106: receivednotify for zone 'qiuri.com'

Nov 14 08:15:10 ns named[6014]: zone qiuri.com/IN: Transfer started.

[root@ slave~ ]#

这个时候问题解决,其实还有配置主辅DNS服务器的时候还会见到类似failed while receiving responses: REFUSED错误提示,一般是由于主DNS服务器上未授权或者是相关的目录没有权限造成。只要耐心查看日志和思考问题,相信问题均可解决。

相关原理:

在解决问题的过程中有的朋友说将SOA中的Refresh值修改小一点,没错!但是这个值什么时候生效呢?当我们主DNS服务器上修改完成后重启服务,会主动传送notify值,如果辅助DNS服务器没有收到才参考RefreshRefresh 不成功,则参考Retry Retry 一直不成功, 则参考 Expire,如果Expire也不成功,则选择放弃zone transfer的过程。


你可能感兴趣的:(linux,redhat)