前面几次我们已经看到了Red Hat5平台下的DHCP、FTP以及Samba服务的搭建，对服务器主机进行访问时也是使用IP地址的形式，而在实际的网络应用中，通常是使用域名的形式访问服务器的。本次将以著名的DNS服务器软件BIND(Berkeley Internet Name Daemon)为例，向大家讲述不同类型域名服务器的搭建。
第一部分：“砍柴前的磨刀”
在动手做DNS之前我们必须先来对DNS相关的软件、服务、配置文件等做一个了解。所谓“磨刀不误砍柴工”。
1.BIND软件介绍
BIND最新的版本我们可通过官方站点（https://www.isc.org/）中下载到。当然Red Hat5已经默认自带了。在RHEL5系统中，与BIND域名服务相关的几个主要软件包和作用如下：
Bind——提供了域名服务的主要程序及相关文件
Bind-utils——提供了对DNS服务器的测试工具程序（如nslookup、dig等）
Bind-chroot——为bind提供一个伪装的根目录以增强安全性
Caching-nameserver——为配置BIND作为缓存域名服务器提供必要的默认配置文件，用以参考。
2.BIND服务控制
BIND软件包安装完毕以后，提供的主程序默认位于“/usr/sbin/named”,系统中会自动增加一个名为named的系统服务，通过脚本文件“/etc/init.d/named”或service命令都可以控制域名服务的运行。下面是常用的关于DNS服务的命令:
启动服务：/etc/init.d/namd start或service named start
重新加载：service named reload
停止服务：service named restart
查看状态：service named status
3.BIND的主配置文件
Named服务的主配置文件为named.conf,一般位于“/etc/”目录中，如果使用了bind-chroot功能，则可能位“/var/named/chroot/etc/”目录中（我们本次的实例讲解以后者为准）。主配置文件中主要包括全局配置和区域配置部分，下面是全局配置部分最常见的配置项及其注解：
|
options {
listen-on port 53 {
directory "/var/named"; //设置区域数据库文件的默认存放位置
allow-query { 192.168.1.0/24; 173.16.16.0/24; }; //允许DNS查询的客户端
recursion yes; //设置允许递归查询
dump-file "/var/named/data/cache_dump.db"; //设置缓存数据库文件位置
statistics-file "/var/named/data/named_stats.txt"; //设置状态统计文件位置
}; |
在以上配置内容中，除了directory项通常保留以外，其他的配置项都可以省略，若不指定listen-on配置项，named默认在所有可用的IP地址上监听服务。服务器处理客户端的DNS解析请求时，如果在named.conf文件中找不到相匹配的区域，将会向根域服务器或者由forwarders项指定的其他DNS服务器提交查询。
以下是区域配置部分常见的配置项：
|
zone "." IN { //设置根区域
type hint; //设置区域类型（hint表示根域、masters表示主域、slave表示从域）
file "named.ca"; //设置对应的根域地址数据库文件
};
zone "zpp.com" IN { //设置正向DNS区域
type master;
file "zpp.zone"; //设置对应的正向区域地址数据库文件
allow-transfer { 200.200.200.1; }; //设置允许下载区域数据库信息的从名服务器
allow-update { none; }; //设置允许动态更新的客户端地址（none为禁止）
};
zone "1.168.192.in-addr.arpa" IN { //设置反向DNS区域名称
type master;
file "192.168.1.arpa"; //设置对应的反向区域地址数据库文件
}; |
在以上配置中，需要注意的地方如下：
每个zone区域都是可选的，具体根据实际需要而定； zone配置部分的“IN”关键字可以省略； 反向区域的名称由倒序的网络地址和“.in-addr.arpa”组合而成，例如对于192.168.1.0/24网段，其反向域名为“1.168.192.in-addr.arpa”； 区域设置中的一部分配置内容（如allow-transfer、allow-update等）也可发放在全局配置中。4.区域数据库配置文件
区域数据库配置文件位于“/var/named/”目录中，如果使用了bind-chroot功能，则可能位于“/var/named/chroot/var/named”目录中。
全局TTL配置项及SOA记录
|
$TTL 86400
@ IN SOA zpp.com. admin.zpp.com. ( //设置SOA标记、域名、域管理邮箱
1997022700 ; Serial //更新序列号，用于标记地址数据库的变化
28800 ; Refresh //刷新时间，从域名服务器更新该地址数据库文件的间隔时间
14400 ; Retry //重试延时，是刷新时间的补充
3600000 ; Expire //失效时间，超过此时间仍无法更新，则放弃
86400 ) ; Minimum //设置无效地址解析记录的默认缓存时间
@ IN NS ns1.zpp.com.
IN MX 10 mail.zpp.com.
ns
mail IN A 173.16.16.1
www IN A 173.16.16.1
ftp IN CNAME www |
在上述配置项中，时间参数的默认单位为秒，也可以使用以下单位：M（分）、H（时）、W（周）、D（天）；从域名服务器根据更新序列号决定是否需要重新下载地址数据库，如果发现序列号与上一次的相同，则不会下载地址数据库，文件中的@表示当前的DNS区域名，相当于“zpp.com”,“admin.zpp.com.”表示管理员的电子邮件地址（由于“@”符号已有其他含义，因此将邮件地址中的“@”用“.”代替。
从上面可以看到在区域数据配置文件中有以下几种常用的地址解析记录：
NS域名服务器(name server)记录，用于设置当前域的DNS服务器的域名地址。 MX邮件交换（Mail Exchange）记录，用于设置当前域的邮件服务器域名地址。 CNAME别名（Canonical Name）记录，用于设置别名5.地址数据库文件的特殊应用
1>.基于DNS解析的负载均衡
当同一个域名对应有多个不同IP地址的服务器时，可以通过DNS区域数据库文件实现简单的轮询负载均衡，只需要在地址数据库中添加相应的多条A记录即可。
例如：movie.zpp.com对应有五台互为镜像的流媒体服务器，在DNS区域“zpp.com”的地址数据库中添加设置该域名解析的负载均衡记录。如下：
|
movie IN A 192.168.1.1
movie IN A 192.168.1.2
movie IN A 192.168.1.3
movie IN A 192.168.1.4
movie IN A 192.168.1.5 |
2>.泛域名解析
当同一个IP地址的服务器对应有相同域内大量不同的域名时（如：51cto的博客域名解析服务），可以通过DNS区域数据文件使用泛域名解析，只需要添加一条主机地址为“*”的A地址记录即可（作用类似于通配符）。
例如：51cto博客使用同一台Web服务器提供虚拟主机服务，IP地址为173.16.16.173，对应的各虚拟主机名均属于51cto.com域，如zpp2009.blog.51cto、xxx..blog.51cto等，在DNS区域“51cto.com”的地址数据库最后一行可添加如下图的泛域名解析记录。
|
* IN A 192.168.1.1 |
3>.子域授权（或委派）
当DNS区域内层次较多，域名数量巨大时，就可以使用子域授权，将某个子域内各域名的解析工作交给另外一台服务器来完成。
例如：在DNS区域“.zpp.com”的地址数据库文件中设置子域授权，将“abc.zpp.com”子域授权给abc公司的DNS服务器（IP地址为192.168.1.1）如下面的设置即可.
|
abc IN A 192.168.1.1
IN NS ns.abc.zpp.com.
ns.abc.zpp.com IN A 192.168.1.1 |
第二部分：构建带分离解析的主域名服务器
说了这么多，我想大家对DNS的配置应该也有了进一步的了解，下面我们通过具体的实例，来看一下DNS在实际工作中的具体应用，下面是准备的拓扑图，以下的实例就是通过下面的拓扑图展开。
首先我们来做一个分离解析的域名服务器，分离解析的域名服务器实际也还是主域名服务器，这里所说的分离解析（Split DNS）,主要是指根据不同客户端提供不同的域名解析记录。例如，当DNS服务器面向Internet和企业内部局域网络同时提供服务时，可能需要将局域网用户访问公司公共域名（www.zpp.com、mail.zpp.com）的数据，直接发往位于内网中的网站、邮件服务器，以减轻网关服务器的地址转换负担。
在本实例中，基本的系统网络环境如上图所示：
域名服务架设在企业网关服务器中，IP地址为173.16.16.1 所负责的DNS域为“zpp.com”，在Internet中的公共哉名“www.zpp.com”和“mail.zpp.com”均解析为网关的公网IP地址“173.16. 公司的网站、邮件服务器均位于局域网内，两台主机的IP地址分别为“192.168. 局域网192.168.1.0/24内的主机均将DNS服务器地址设为192.168.1.1，当内网用户访问地址“www.zpp.com”和“mail.zpp.com”时，分别解析为内部服务器的IP地址“192.168.下面是具体的实现步骤：
1. 建立主配置文件named.conf
在named.conf文件中，主要使用“view”配置语句和“match-clients”配置项，根据不同的客户端地址将对“zpp.com”域的查询对应到不同的地址数据库文件，从而由不同的数据库文件提供不同的解析结果。
说明：使用“view “LAN””配置项设置面向内网用户的视图；
使用“match-clients { 192.168.1.0/24; };”配置项匹配条件为来自内网的客户端地址；
使用“file “zpp.com.zone.lan”;”配置项指定面向内网用户的地址数据库文件；
使用“view “WAN””配置项设置面向外网用户的视图；
使用“match-clients { any; };”配置项匹配条件为任意地址；
使用“file “zpp.com.zone.lan”;”配置项指定面向内网用户的地址数据库文件；
注意：将包含“match-clients { any; };”的“view”配置段放在文件中的最后一部分，否则会导致其后的“view”配置段失效。也就是说找到一个匹配结果后即不再向下匹配。
2. 分别建立对外、对内解析的区域数据库文件
建立“zpp.com”域面向内网客户端的地址数据库文件（文件名为：zpp.com.zone.lan）。
建立“zpp.com”域面向外网客户端的地址数据库文件(文件名为：zpp.com.zone.wan)。
3. 重新启动named服务
4. 验证分离解析域名服务器
1>.在内网客户机lan-pc1上的测试。
说明：可以看到从内网主机“lan-pc1” 上通过DNS测试工具nslookup可以正常解析。此时内网用户在IE中输入www.zpp.com实际上是直接访问了内网中的Web服务器（IP为192.168.1.5）。
2>.在外网客户机wan-pc1上的测试。
说明：可以看到从外网主机“wan-pc1” 上通过DNS测试工具nslookup可以正常解析。此时外网用户在IE中输入www.zpp.com访问的是公司外网接口。
第二部分：构建从域名服务器
从域名服务器作为主服务器的冗余备份，可与主域名服务器一起，同时提供本域内主机名与IP地址的解析，从域名服务器的地址数据库需要从主域名服务器中定期更新。下面我们还是以上面的拓扑为例来看一下从域名服务器是如何构建的。
先说一下我们的要求，主域名服务器已经在网关服务器上构建完毕，同时面向Internet和内部网络提供“zpp.com”域内主机的解析服务。现需要构建一台从域名服务器，只面向Internet提供域名解析服务（不提供分离解析），区域地址数据库从主域名服务器中自动更新。
接下来是我们的具体配置步骤：
1．建立主配置文件named.conf
在从域名服务器的named.conf配置文件中，将zone的类型设置为“slave”,并使用“masters {};”语句指定主域名服务器的地址即可。
说明：可以看到从域名服务器上的设置其实地很简单的，只需要开个从域就可以了。
2.启动named服务
3.验证从域服务器
成功启动之后我们就可以从目录/var/named/slaves/中看到区域配置文件zpp.com.zone.wan已经被同步过来了，如图：
现在我们可以在外网的PC机wan-pc1上进行测试，可以看到DNS服务器173.16.16.2可发正常为客户机提供域名解析服务。
现在我们就实现了DNS服务器的分离解析及备份，最后再补充说明一下转发器的配置。
有时侯为了提高解析效率，可以不向根域查询，而是将用户端的解析请求转发给特定的DNS服务器，收到返回的结果后再传递给客户机，配置的方法极为简单，只要去掉“zone “.” IN {… … };”的设置，并在全局配置中正确设置forwarders参数即可，下面举例说明。
例如：在named.conf文件中设置转发DNS服务器地址，将解析请求转发给61.134.1.4、218.16.1.9.
|
forwarder { 61.134.1.4 218.16.19; }; |
此时，来自客户端的域名解析请求都将会被转发到我们在“forwarder”配置项中指定的DNS服务器上。
本文出自 “zpp” 博客，请务必保留此出处http://zpp2009.blog.51cto.com/730423/269518
