RHEL5.4配置DNS服务(2)

2017-03-27

6892

RHEL5.4配置DNS 服务（2）刚才只是配置了主DNS 服务器，而且主DNS 服务器也工作正常，现在我们来配置一个辅助DNS 服务器。配置辅助DNS 服务器主DNS 的东西和辅助DNS 东西实际上

RHEL5.4配置DNS 服务（2）

刚才只是配置了主DNS 服务器，而且主DNS 服务器也工作正常，现在我们来配置一个辅助DNS 服务器。

配置辅助DNS 服务器

主DNS 的东西和辅助DNS 东西实际上是一模一样的，

第一步，安装软件包

[root@localhost ~]# yum -y install bind bind-chroot caching-nameserver

[root@localhost ~]#

第二步，复制模板文件

[root@localhost etc]#

[root@localhost etc]# cp -p named.caching-nameserver.conf named.conf

[root@localhost etc]#

第三步，编辑named.conf 文件

[root@localhost etc]#

[root@localhost etc]# vim named.conf

[root@localhost etc]#

和主DNS 配置一样就可以了。

前面的都和主DNS 配置一样就可以了

第四步，定义zone 文件。(编辑named.rfc1912.zones 文件)

[root@localhost etc]#

[root@localhost etc]# vim named.rfc1912.zones

zone "example.com" IN {

type slave;

masters { 192.168.0.254; };

file "slaves/example.com";

};

zone "0.168.192.in-addr.arpa" IN {

type slave;

masters { 192.168.0.254; };

file "slaves/named.example";

};

辅助DNS 在定义zone 文件的时候和主DNS 有些不同

在辅助DNS 里面 type 要改为slave

master { 192.168.0.254; }; 而且必须指定主DNS 的IP address

file "slaves/example.com";

file "slaves/named.example";

为什么要指定数据库文件在slaves 目录下面呢

是因为slaves 目录是拥有人和拥有组都是named 用户，在启动DNS 服务的时候，只有named 有权限进行操作，所以我们要把数据库放在这个目录下面。

[root@localhost ~]#

[root@localhost ~]# cd /var/named/chroot/var/named/

[root@localhost named]#

[root@localhost named]# ll | grep slaves

drwxrwx--- 2 named named 4096 Jul 27 2004 slaves

[root@localhost named]# cd slaves/

[root@localhost slaves]# ls

[root@localhost slaves]#

可以看到，slaves 目录的拥有人和拥有组是named ，并且现在的slaves 目录下面是什么东西都没有的。

现在我们重启一下DNS 服务，

[root@localhost ~]#

[root@localhost ~]# service named restart

Stopping named: [ OK ] Starting named: [ OK ]

[root@localhost ~]#

可以看到，服务启动成功了。

在启动服务的同时，我们来查看一下日志信息，看看日志里面有什么提示。

[root@localhost ~]#

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

Feb 21 18:23:00 localhost named[7394]: zone example.com/IN/localhost_resolver: Transfer started.

Feb 21 18:23:00 localhost named[7394]: transfer of 'example.com/IN' from 192.168.0.254#53: connected using 192.168.0.10#55165

Feb 21 18:23:00 localhost named[7394]: zone example.com/IN/localhost_resolver: transferred serial 2010022101

Feb 21 18:23:00 localhost named[7394]: transfer of 'example.com/IN' from 192.168.0.254#53: end of transfer

[root@localhost ~]#

在日志里面可以看到，主DNS 与辅助DNS 正在同步序列号，同步成功，这个日志里面的信息非常的详细。

接下来，我们在到slaves 目录下面去看看，

[root@localhost named]# cd slaves/

[root@localhost slaves]# ll

total 8

-rw-r--r-- 1 named named 461 Feb 21 18:23 example.com

-rw-r--r-- 1 named named 531 Feb 21 18:23 named.example

[root@localhost slaves]#

刚才slaves 目录下面的是什么东西都没有的，现在就多了两个文件，example.com 和named.example 这个两个文件。这个就是我们刚才在定义zone 文件的时候在slaves 目录下面定义的，文件名是随意写的，这个没有关系，但是里面东西是和主DNS 一样的。

我们打开这个两个文件来看一下

[root@localhost slaves]#

[root@localhost slaves]# vim example.com

$ORIGIN .

$TTL 86400 ; 1 day

example.com IN SOA s erver1.example.com. root.exmaple.com. ( 2010022101 ; serial

10800 ; refresh (3 hours) 900 ; retry (15 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) )

NS server1.example.com.

$ORIGIN example.com.

server1 A 192.168.0.254

station10 A 192.168.0.10

station20 A 192.168.0.20

station30 A 192.168.0.30

station40 A 192.168.0.40

station50 A 192.168.0.50

[root@localhost slaves]#

[root@localhost slaves]# vim example.com

$ORIGIN .

$TTL 86400 ; 1 day

0.168.192.in-addr.arpa IN SOA server1.example.com. root.example.com. ( 2010022101 ; serial

28800 ; refresh (8 hours) 14400 ; retry (4 hours)

3600000 ; expire (5 weeks 6 days 16 hours)

86400 ; minimum (1 day) )

NS server1.example.com.

$ORIGIN 0.168.192.in-addr.arpa.

10 PTR station10.example.com.

20 PTR station20.example.com.

254 PTR server1.example.com.

30 PTR station30.example.com.

40 PTR station40.example.com.

50 PTR station50.example.com.

这两个文件里面的内容和我们的主DNS 的内容都是一样的。而且还帮我们整理的非常的漂亮。这些都是系统自动生成的。

现在我们来测试一下主DNS 和辅助DNS 可不可以正常的工作呢，

[root@localhost ~]#

[root@localhost ~]# vim /etc/resolv.conf

search example.com

nameserver 192.168.0.254

nameserver 192.168.0.10

现在我们将主DNS 和辅助DNS 都设置一下。

然后在使用nslookup 工具来测试

[root@localhost ~]# nslookup

> 192.168.0.254

Server: 192.168.0.254

Address: 192.168.0.254#53

254.0.168.192.in-addr.arpa name = server1.example.com.

> station10.example.com.

Server: 192.168.0.254

Address: 192.168.0.254#53

Name: station10.example.com

Address: 192.168.0.10

现在解析没有问题，还是有192.168.0.254这台主DNS 来解析的。

接下来，我们将192.168.0.254这台主DNS 给down ，看下192.168.0.10这台辅助DNS 能否正常工作。

[root@localhost ~]# service named stop

Stopping named: [ OK ]

[root@localhost ~]#

192.168.0.254这台主DNS 已经被我们停止了。

在用nslookup 来测试一下，

[root@localhost ~]# nslookup

> 192.168.0.254

Server: 192.168.0.10

Address: 192.168.0.10#53

254.0.168.192.in-addr.arpa name = server1.example.com.

> station20.example.com.

Server: 192.168.0.10

Address: 192.168.0.10#53

Name: station20.example.com

Address: 192.168.0.20

现在解析照样成功了，现在并不是通过192.168.0.254这台主DNS 来解析出来的，而是通过我们的192.168.0.10这台辅助DNS 来解析出来的。当我们网络中的主DNSdown 掉的时候，我们的辅助DNS 照样能够正常的工作。

我们还可以实现负载均衡，可以在网络中的一半客户端的主DNS 指向

192.168.0.254，辅助DNS 指向192.168.0.10。将网络中的另一半客户端的主DNS 指向192.168.0.10，辅助DNS 指向192.168.0.254。这样两台服务器都可以正常的工作，正常的为客户端解析，当其中的一台DNSdown 掉后，另一台DNS 也会继续的工作，这样就实现了简单的负载均衡。

到目前为止，我们的主DNS Server 和我们的辅助DNS Server都已经设置成功了，并且都可以正常的工作了。

接下来，我们在做一个试验，我们在主DNS 添加一笔记录，看下辅助DNS 能否学习到这笔记录，不能够在辅助DNS 上面添加记录，这样没有意义，我们的主DNS 一样是学习不到这笔记录的。

下面我们开始，

www IN A 192.168.0.254

我们已经在主DNS 里面添加了一笔记录，在主DNS 里面做了新的操作以后，一定要将主DNS 的序列号加一。否则辅助DNS 是不会来同步我们的主DNS 的。 2010022102 ; serial (d. adams)

我们已经将主DNS 的序列号加一了，但是默认情况下，主DNS 与辅助DNS 的同步时间是3H ，这样我们很难看到效果，我们将它改为2M 。

2M ; refresh 然后在将重试时间改为2M

2M ; retry

这样就代表每隔两分钟主DNS 和辅助DNS 进行同步，如果同步不成功，在隔两分钟同步一次。接下来我们将反向解析里面的也来修改一下。

2010022102 ; Serial

120 ; Refresh 120 ; Retry 254 IN PTR www.example.com.

这样，反向解析里面也已经修改完成了。现在将DNS 服务重启下，

[root@localhost ~]#

[root@localhost ~]# service named restart

Stopping named: [ OK ] Starting named: [ OK ]

[root@localhost ~]#

重启成功，等几分钟之后在来看下效果。

现在我们到辅助DNS 的正向解析数据库文件里面看一下，

[root@localhost slaves]# cat example.com

$ORIGIN .

$TTL 86400 ; 1 day

example.com IN SOA server1.example.com. root.exmaple.com. ( 2010022102 ; serial

120 ; refresh (2 minutes) 120 ; retry (2 minutes) 604800 ; expire (1 week)

86400 ; minimum (1 day)

)

NS server1.example.com.

$ORIGIN example.com.

server1 A 192.168.0.254

station10 A 192.168.0.10

station20 A 192.168.0.20

station30 A 192.168.0.30

station40 A 192.168.0.40

station50 A 192.168.0.50

www A 192.168.0.254

[root@localhost slaves]#

OK ，可以看到，我们刚才在主DNS 里面添加的一条新的记录现在已经被辅助DNS 同步过去了，而且辅助DNS 的序列号和刷新时间，重试时间都同步了。下来我们在到辅助DNS 的反向解析数据库文件里面看一下，

[root@localhost slaves]# cat named.example

$ORIGIN .

$TTL 86400 ; 1 day

0.168.192.in-addr.arpa IN SOA server1.example.com. root.example.com. ( 2010022102 ; serial

120 ; refresh (8 hours) 120 ; retry (4 hours)

3600000 ; expire (5 weeks 6 days 16 hours)

86400 ; minimum (1 day) )

NS server1.example.com.

$ORIGIN 0.168.192.in-addr.arpa.

10 PTR station10.example.com.

20 PTR station20.example.com.

254 PTR server1.example.com.

30 PTR station30.example.com.

40 PTR station40.example.com.

50 PTR station50.example.com.

254 PTR www.example.com.

[root@localhost slaves]#

OK ，也可以看到，辅助DNS 也已经同步成功了。

下面在来介绍DNS 其他资源记录

1. CNAME 别名解析记录

现在我们在数据库文件里面配置CNAME 记录

web IN CNAME www.example.com.

别名解析记录就是将www.example.com. 这个域名添加一个别名，通过这个别名我们也可以访问。但是前提是www.example.com. 这个域名在DNS 要解析的到。

现在我们来测试一下，CNAME 记录有没有生效。

先将DNS 服务重启一下

[root@localhost ~]#

[root@localhost ~]# service named restart

Stopping named: [ OK ] Starting named: [ OK ]

[root@localhost ~]#

重启成功，同样的使用nslookup 工具来解析一下。

[root@localhost ~]# nslookup

> www.example.com

Server: 192.168.0.254

Address: 192.168.0.254#53

Name: www.example.com

Address: 192.168.0.254

> web.example.com

Server: 192.168.0.254

Address: 192.168.0.254#53

web.example.com canonical name = www.example.com.

Name: www.example.com

Address: 192.168.0.254

可以看到，CNAME 记录解析没有问题，www.example.com. 有一个别名记录是web.example.com. 。

2. 泛域名解析记录

现在我们在数据库文件里面配置泛域名解析记录，

* IN A 192.168.0.254

泛域名解析就是匹配所有，但是这个解析最好要放在数据库文件的最后面，因为读取数据库文件的时候是从上往下开始读取的，当上面全部都不匹配的时候，才会去读取泛域名解析记录。

现在我们就来测试一下，泛域名解析有没有生效。

先将DNS 服务重启一下，

[root@localhost ~]#

[root@localhost ~]# service named restart

Stopping named: [ OK ] Starting named: [ OK ]

[root@localhost ~]#

重启成功，同样的使用nslookup 工具来解析一下。

[root@localhost named]# nslookup

> dfdsfsdfsdf.example.com.

Server: 192.168.0.254

Address: 192.168.0.254#53

Name: dfdsfsdfsdf.example.com

Address: 192.168.0.254

dfdsfsdfsdf.example.com. 这个域名都能够被解析成功，也就是说example.com 的所有域名都可以被解析到。

3. MX 记录邮件交换记录

现在我们在数据库文件中文件邮件交换记录，

@ IN MX 10 mail.example.com.

当有客户端向example.com 这个域发邮件，那么客户端怎么会指定将邮件发给example.com 域下面的mail.example.com. ，就是因为这个MX 记录定义的。Mail.example.com 就是example.com 这个域的邮件服务器。

现在我们就来测试一下，MX 记录有没有生效。

先将DNS 服务重启一下，

[root@localhost ~]#

[root@localhost ~]# service named restart

Stopping named: [ OK ] Starting named: [ OK ]

[root@localhost ~]#

重启成功，使用dig 工具来查询一下。

[root@localhost ~]#

[root@localhost ~]# dig -t MX example.com.

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> -t MX example.com.

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23948

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:

;example.com. IN MX

;; ANSWER SECTION:

example.com. 86400 IN MX 10

mail.example.com.

;; AUTHORITY SECTION:

example.com. 86400 IN NS server1.example.com.

;; ADDITIONAL SECTION:

mail.example.com. 86400 IN A 192.168.0.254 server1.example.com. 86400 IN A 192.168.0.254

;; Query time: 2 msec

;; SERVER: 192.168.0.254#53(192.168.0.254)

;; WHEN: Mon Feb 22 13:02:08 2010

;; MSG SIZE rcvd: 104

[root@localhost ~]#

Dig 命令显示的很详细，MX 也查询到了。

总结：

在DNS 中的资源记录类型有那些

(1) SOA 资源记录

每个数据库文件按的开始处都包含了一个起始授权记录（Start of Authority Rec ord ）, 简称SOA 记录。SOA 定义了域的全局参数，进行整个域的管理设置。一个区域文件只允许存在唯一的SOA 记录。

(2) NS 资源记录

名称服务器（NS ）资源记录表示该区的授权服务器，它们表示SOA 资源记录中指定的该区的主和辅助服务器，也表示了任何授权区的服务器。每个区在区根处至少包含一个NS 记录。

(3) A 资源记录

地址（A ）资源记录把FQDN 映射到IP 地址，因而解析器能查询FQDN 对应的IP 地址。

(4) PTR 资源记录

相对于A 资源记录，指针（PTR ）记录把IP 地址映射到FQDN 。

(5) CNAME 资源记录

规范名字（CNAME ）资源记录创建特定FQDN 的别名。用户可以通过定义的C ANME 记录中的别名来访问

(6) MX 资源记录

邮件交换（MX ）资源记录为DNS 域名指定邮件交换服务器。邮件交换服务器是为DNS 域名处理或转发邮件的主机。处理邮件指把邮件投递到目的地或转交另一不同类型的邮件传送者。转发邮件指把邮件发送到最终目的服务器。

(7) 泛域名解析记录

除了在数据库文件中定义的资源记录以为，其他的所有域名都可以被DNS 所解析出来。

相关推荐