定义自己的名字服务缓冲形式的名字服务只能用于名字查询，但没有定义任何名字数据。如果要想让自己的网络有一个域名，并为其他计算机都提供服务，就必须使用完整配置的名字服务器。
正向解析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 ns1ns IN A 192.168.4.21ns1 IN A 192.168.4.22www 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：@INSOAns.bsdgroup.example.org.cn. admin.example.org.cn. (1998012314; Serial3600; Refresh900; Retry3600000; Expire3600 ); MinimumINNSns.bsdgroup.example.org.cn.21INPTRns.bsdgroup.example.org.cn.22INPTRns1.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.INNS192.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/namedFeb 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].1040Feb 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设置，帮助解决设置问题。
未完，待续。。。
