定义自己的名字服务
缓冲形式的名字服务只能用于名字查询，但没有定义任何名字数据。如果要想让自己 的网络有一个域名，并为其他计算机都提供服务，就必须使用完整配置的名字服务器。
- 正向解析zone
第一步要为自己的子域在/etc/namedb/named.conf文件中定义zone，并修改设置文件 named.conf。在named.conf文件中，首先要删除forward的相关设置，使服务器不仅用于转发 请求，也能拥有自己的名字解析数据库。然后再增加一项新zone的定义：
zone "bsdgroup.example.org.cn" {
type master;
file "db.bsdgroup";
}; |
这一项描述了bsdgroup.example.org.cn的zone对应的配置文件为db.bsdgroup。其中 type master表示这台DNS服务器为这个zone的主服务器，对于一个zone来讲，可以由多个DNS 服务器提供服务，以提供一定的备份能力。当为一个zone使用多个DNS服务器的时候，通常可 以设置一个主服务器，而其他服务器为辅服务器，辅服务器将从主服务器上获得zone的解析 数据，而本地文件只是用于万一主服务器出现故障的情况。
更改过named.conf中的zone设置项，就能创建zone的解析数据文件db.bsdgroup，用于 保存zone内的解析数据。
@ IN SOA ns.bsdgroup.example.org.cn. admin.example.org.cn. (
1999010801 ; Serial (date, 2 digits version of day)
86400 ; refresh (1 day)
7200 ; retry (2 hours)
8640000 ; expire (100 days)
86400 ) ; minimum (1 day)
IN NS ns.bsdgroup.example.org.cn.
IN NS ns1.bsdgroup.example.org.cn.
IN MX 10 ns
IN MX 20 ns1
ns IN A 192.168.4.21
ns1 IN A 192.168.4.22
www IN CNAME FreeBSD.example.org.cn. |
这个设置文件中首先为这个zone定义了SOA记录，接下来定义了服务于这个zone的两个 名字服务器。当为一个zone定义名字服务器时，有的管理员以为将名字服务器设置的越多越能 提供备份，其实并不是这样。如果定义的一台名字服务器，其named.conf（或named.boot）设 置文件中并没有设置它为这个zone服务，那么该名字服务器上就没有这个zone的解析数据，这 就导致一些客户从这个名字服务器中查询这个zone的数据失败。这个配置错误就是Internet中 经常发生的Lame Server错误，一些老版本的named不能检测并纠正这个错误，就会导致网络上 部分客户计算机不能解析这个zone。同样，多个名字服务器之间还应该保持zone数据一致，正 确划分好主/辅服务器可以很好的解决这个问题。
然后又针对这个zone定义了两个MX记录，表示对应于这个zone的邮件服务器为ns和ns1， 这样在电子邮件中的地址中，就不需要使用具体的计算机名字ns.bsdgroup.example.org.cn， 而可以直接使用bsdgroup.example.org.cn。其中ns的参数为10，ns1的参数为20，用于标识不 同邮件服务器的优先级，一个邮件总是首先向低优先级的邮件服务器发送，只有当这个服务器 出现故障时，才会尝试其他的邮件服务器。
这个文件中还定义了几个A记录，这个记录具体定义ns和ns1的IP地址，然后定义了一个 www的计算机，但这只是freebsd.example.org.cn的一个别名。
这个zone是对该zone中的计算机进行正向名字查询，从名字返回相应的IP地址，进一步 可以配置反向查询zone，输入要查询的IP地址，返回正确的主机名字。
- 反向解析zone
前面提到的localhost.rev就是一个反向查询zone文件。因此要定义其他反向解析zone， 就与它相似。首先在named.conf中增加一个设置语句：
zone "4.168.192.in-addr.arpa" {
type master;
file "bsdgroup.rev";
}; |
网络地址以反方向的方式写出，并使用in-addr.arpa后缀，表示一个反向查询zone为192.168.4。 然后创建反向解析数据bsdgroup.rev：
@ IN SOA ns.bsdgroup.example.org.cn. admin.example.org.cn. ( 1998012314 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ns.bsdgroup.example.org.cn. 21 IN PTR ns.bsdgroup.example.org.cn. 22 IN PTR ns1.bsdgroup.example.org.cn. |
注意，这里正向解析和反向解析位于同一台服务器上，这只是一种较简单的情况，但对 Internet上更广泛的复杂情况，并不总是如此。
- 维护名字服务器
当完成了这一步之后，就可以把本网络上所有计算机的解析数据，使用A记录增加到 db.bsdgroup中，使用PTR记录增加到bsdgroup.rev文件中去，并重新启动named守护进程，或者 向named发送SIGHUP信号（使用kill或killall），使其重新读取设置文件。那么所有使用这台计 算机作名字服务器的计算机将能正确查询相应的名字和IP。
但是，外部的计算机并不知道有这个名字服务器的存在，因此外部计算机还无法查找到 正确的结果。因此就需要将这个名字服务器，及其提供服务器的域，登记到Internet上的正式名 字服务器上，以便这个名字服务器上的zone数据通过正式服务器发布到整个Internet。最方便的 做法是将这个名字服务器登记到其上一级名字服务器上，如在example.org.cn的名字服务器中可 以指定bsdgroup.example.org.cn子域的zone设置及名字服务器。
bsdgroup.example.org.cn. IN NS 192.168.4.21 |
此后，外部计算机才能查找bsdgroup这个域的内容。
这个例子中使用了两个名字服务器ns和ns1，为了保持两个服务器中的数据一致，两个服务器 一个需要作为主服务器，另一个必须作为辅服务器。主服务器ns在配置文件named.conf中使用 type master来说明，而辅服务器ns1使用type slave来说明：
zone "bsdgroup.example.org.cn" {
type slave;
file "db.bsdgroup";
}; |
这使得ns1首先尝试从ns（192.168.4.21）中获得zone的配置数据，如果不能成功再从本 机配置文件中获得。这样既能起到备份作用，又能保持解析数据尽量一致。
named在启动和运行的过程中将不断向控制台打印信息，这些信息也被写入/var/log/messages 文件中。查看这些文件可以判断是否有错误发生。
Feb 15 01:26:17 roke named[6091]: starting. named 8.1.1 Sat Feb 14
00:18:20 MET 1998 ^Iwb@example.org.cn:/var/tmp/bind-8.1.1/src/bin/named
Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0)
Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa"
(IN) loaded (serial 1)
Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo)
Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ppp0)
Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040
Feb 15 01:26:17 roke named[6092]: Ready to answer querIEs. |
此外，随着Internet的发展，根DNS服务器也会不断更新，因此保持自己的DNS服务器中 root.hints（或named.root）文件与Internet上的真实根文件服务器同步也是非常重要。通常可 以使用dig来从一个根文件服务器上取得这个文件：
# cd /etc/namedb # dig @rs.internic.net . ns >root.hints.new |
如果一切正常，就可以将root.hints.new复制为named.root，并重新启动named。此外还 有一些常用的工具程序有nslookup，dig，dnswalk，named-xfer等，能用来分析DNS设置，帮助解 决设置问题。
未完，待续。。。
标签：
