天天看点

一次关于DNS服务器的故障排错记录——RNDC故障

说明:这是一篇对DNS排错的文章,因为在网上(包括RedHat知识库)几乎没有对文中提到的错误进行直接描述和提出最好最快的解决方案的报告,经过长达近一个小时的排错和资料查阅才有了这篇文章的脱稿。

昨天我刚刚在非生产环境中的Red Hat Enterprise Linux Server上配置了一台DNS服务器,以做测试使用。但是很快遇到了一个奇怪的错误。

我在执行“service named status”后,其中第一行显示如下内容:

一般大家都知道,rndc 主要是用来控制named进程及其配置文件的,可以用来连接DNS服务器并对配置进行重新载入,其端口号就是953。那么导致这个错误的原因可能是什么呢?

我的解决思路:

首先,发现问题,仔细阅读查看命令的回显信息。例如我详细的查看service的状态信息。

很显然,上面的显示中的第97行显示的

rndc: connect failed: 127.0.0.1#953: connection refused 

named is stopped

是错误的信息。

然后我开始查看系统日志,显示结果如下:

很明显,根据上面的结果第35,37,46行的提示很可能是权限或者配置文件的错误造成的。所以下面一一检查即可。

首先不是权限的问题。我查看了所有DNS相关的所有配置文件,展示如下,也为大家以后出错作为参考。因为使用root登录终端对文件或目录执行移动或创建工作很容易导致权限问题。

通过比对之前的备份,发现在权限上没有问题。

PS:如果大家遇到这方面的问题请使用如下的命令进行修改。

那么既然不是权限的问题,是不是iptables给设定的规则不正确呢?

查看iptables配置信息,显示如下:

显然,不是iptables的配置有问题。再者,iptables如果有策略在阻止访问,其错误信息也不是如上面所示。

最终我诊断为可能是/etc/named.conf 配置文件存在问题。

因此进行检查配置文件,操作和显示如下:

说明,在参数上没有问题。因此我开始怀疑,是不是/etc/named.conf或者/etc/rndc.conf存在配置错误?但是,作为新配置安装的DNS不会在密钥上出现问题,因此我检查了/etc/named.conf,确实没发现什么错误。然后我检查了/etc/rndc.conf这个文件,终于发现问题的所在。

结果如下:

显然,最后的注释说的很清楚,要想使用rndc就必须在/etc/named.conf中进行配置。

所以将显示如下的/etc/named.conf第一段代码更改为第二段代码。

第一段代码:

第二段代码:

最后,重新启动named守护进程

结果显示如下,就表示可以了。

最后总结:

        其实问题的出现不一定就是存在硬错误,还可能存在软错误。就像C编程一样,有的语法错误,编译器或语法检查器能帮你识别并找出错误,但是在算法上的逻辑错误只能由编程人员自己发现和纠正。在配置Linux网络服务器时同样也可能遇到这类问题,只要管理员仔细查看问题,检查日志就很快发现问题的所在。希望在今后的工作中能更多的总结和发现、解决问题的思路,大胆的却有根据的自己去发现和解决问题。

继续阅读