BIND_&_DNS服务器配置
Bind_ &_ DNS服务器配置
bind97 安装：
简述：bind ( BerkeleyInternet Name Domain ) 是目前互联网上用得最多的DNS服务器软件之一。
但是目前这个软件已经不再由伯克利大学维护，而是交给了一个叫做“ISC”的组织负责维护。
www.isc.org 。由于ISC官方网站提供给用户的是源代码包，因此用户需要自己编译后才能安装，
但是红帽公司为我们提供了已经编译好的RPM包。所以此处我们先学习如何使用RPM来安装，回头再学习
如何使用编译源代码的方式安装 ( 这种方式让用户可定制其中的某些属性)
Setp-1> CentOS 5.8 和CentOS 5.1的系统中在默认情况下，9.3 和 9.7 的包是并存的。
Setp-2> 我们知道不同的版本会使用与之相应的包，所以需要卸载已经系统默认为我们安装的bind-libs.i386
和 bind-utils.i386 这个2个包。执行：“rpm -e bind-libs bind-utils”卸载之后把bind97、
bind97-libs、bind97-utils 这3个包给装上。执行：“yuminstall bind97”
---在bind97-utils.i386这个包当中为我们提供了很多的DNS客户端工具。
---而bind97-libs.i386这个包用于提供bind97-utils.i386 这个包当中的程序需要用到的库文件。
我们可以看看bind97-utils.i386 p这个包都提供了哪些常用的客户端【工具| 程序】。
---而bind97-devel这个包对于运维人员来说到的可能性不大，主要给开发人员使用的。
---而bind97-chroot 包是干什么用的呢~？它类似于我们之前学习的 chroot 命令【根切换】
默认情况下：bind这个软件运行在真正的根下面，一旦有人攻破了我们服务器，一旦这个人劫持
了named进程，那么就意味这个人他很有可能将取得运行named这个进程的用户的所有权限(通常
运行named 这个进程的用户属于【用户：named| 组：named】。虽然named用户，和named 组
，属于系统用户和系统组，并且它们不能登陆系统。但是一旦named进程被劫持后，named 这个用
户可以到达的地方，这个入侵者也能到达，named这个用户所能看到的文件，这个入侵者也能看得到
了~ ，而事实我们知道通常Linux 下的每一个普通用户通用访问的文件是全局的。那么【根下、etc 下】
的很多文件入侵者也都能看到，所以这样是非常危险的。然而我们把根切换到一个指定的目录就可以
很好的规避这种风险(我们可以把named进程所依赖的文件统统搬到指定目录下)。
例如：
在 /var/named/ 下创建一个假“根”,名为“chroot”,这个目录下存放named所需的所有文件
/var/named/chroot
etc/named.conf
etc/rndc.key
sbin/named
var/named/
---而caching-nameserver 包结合bind可以让我们服务器立马变成一个缓存DNS服务器。
Setp-3 > 安装好bind97后我们可以检查一下安装后的情况：
bind97主要组成部分：
1. 主配置文件 --- /etc/named.conf
---这个文件主要用于定义【bind进程 | DNS】的工作属性
---这个文件中还包含了区域的定义
请注意：在红帽5上如果使用的bind97, 那么/etc/named.conf 这个文件就相当于安装了
caching-nameserver（但是在红帽6上可能并非如此 ,如果还打算使用9.3版本这个包最好装上）
2. 区域数据文件 --- /var/named
bind97还需要提供区域数据文件，但通常这些区域数据文件，需要管理员手动去创建。至于这
些数据文件叫什么，用户可以自定义。
3. 服务控制脚本 --- /etc/rc.d/init.d/named
bind97安装完成之后会创建相应的服务控制脚本。我们之前在学习独立守护进程时说过
/etc/rc.d/init.d这个目录下的脚本有一个共性：那就是支持【 start 、stop、restart
、status、reload 】等选项。有的脚本甚至还支持 configtest 这样的选项。
4. 服务控制脚本的配置文件 --- /etc/sysconfig/named
这个文件是服务控制脚本 /etc/rc.d/init.d/named 的配置文件我们之前学习过，服务脚本也
可以有配置文件，而且它们的配置文件通常都位于 /etc/sysconfig这个目录下。
5. 二进制主程序 ---/usr/sbin/named
6. 主配置文件语法检查工具 ---/usr/sbin/named-checkconf
7. 区域数据文件语法检查工具 --- /usr/sbin/named-checkzone
8. 远程管理工具(RNDC) --- /usr/sbin/rndc
9. RNDC 配置文件生成工具 --- /usr/sbin/rndc-confgen
回顾一下之前的学习内容，rndc是不是与我们学过的ssh-keygen功能很类似啊~
10. RNDC远程管理工具的配置文件 --- 【/etc/rndc.key | /etc/rndc.conf】
rndc: Remote Name Domain Controller远程名称服务控制器
它可以让用户远程控制DNS服务器的【启动 | 关闭 | 重读配置文件及数据文件】
而/etc/rndc.key 只是为了实现rndc命令能够远程工作的一个密钥文件。我们可试想一
下如果每个人都能远程控制我们的DNS服务器，那么显服务器毫无安装性可言，而
有了这密钥文件之后，我们可以保证只让掌握密钥的用户才能远程控制DNS服务器。
然而在红帽当中 /etc/rndc.key 这个文件被命名为“/etc/rndc.conf”，在这个文件中不但
包含密钥的信息，还包含了一些其它的配置信息。
11. 另外，需要注意一点，bind这个包的二进制程序叫“named”而不叫 bind ，这一点大家需要注意
12. 一般而我们搭建一个DNS服务器，只需要提供主配置文件和区域数据文件即可。
vi /etc/named.conf
以下是默认状态下的 named.conf
分解1:options --- 全局【选项 | 参数】
options中的参数对下面的每一个子部分的内容都生效
分解2:logging --- 日志（定义如何【生成 | 保存】日志信息）
分解3:zone--- 区域（zone 是关键字，用途：定义某一个区域）
以下是默认状态下的 /var/named/ 目录的内容
分解1:文件 --- named.ca
请参考附件-1 这个文件存放的是关于根服务器的记录。
如果这个文件丢失，或找不到了，用户可以自己动手(使用dig命令)去生成了个named.ca
dig的详细用法请参考dig_command_study.doc ,下面我们简单dig命令常用参数及用法。
dig
-t: 指定资源记录类型
例如-1：dig -t NS .
例如-2：dig -t NS . @a.root-servers.net.
说明：查找根域的所有NS记录 (可使用@符号指定通过哪台主机来查找，也可以不指定)
分解2:文件 --- named.localhost
请参考附件-2 本地主机的正向解析
分解3:文件 --- named.loopback
请参考附件-3 本地主机的反向解析
13. DNS监听的协议及端口
53/udp
什么时候需要使用UDP 的53号端口呢~？
通常客户端发起查询请求都是使用UDP协议的，因为使用UDP协议速度快很多。
53/tcp
什么时候需要使用 TCP 的53号端口呢~？
而当主DNS服务器向从DNS服务器传送数据的时候，为保持数据的整性，此时会使用TCP协议
953/tcp、rndc
而953端口是RNDC监听的。
为了加深理解我们回顾一下什么是套接字~？
套接字( SOCKET) 所谓套接字= IP : PORT
套接字功能：为了让位于2台不同主机上的进程相互之间能够正常通信，需要使用套接字来实现。
我们以DNS为例来说明：
由此可见：每一个服务器如果想让位于2台不同主机上的进程彼此间能够通信，一般来讲
服务器就必须监听在某个套接字上，作为客户端访问的入口。
主配置文件 ( /etc/named.conf )分解：
请注意named.conf 的权限，以及属主和属组。
listen-on port 53 {127.0.0.1;};
listen-on port 53 {0.0.0.0;};
表示DNS 监听在哪个地址的哪个端口上
以上图为例我们说明一下：
我们假设DNS服务器监听在 172.16.100.1这个IP 的53号端口上，那么当客户端向
192.168.0.12这个地址的53号端口发起查询请求，我们试想一下DNS服务会响应客
户端的请求吗~？虽然客户端能ping通192.168.0.12 这个地址，但是它获得查询结果吗~？
很显然DNS服务器是不会响应客户发送的查询请，因为DNS服务器并没有监听192.168.0.12
这个地址的53号端口，所以客户无法获得查询的结果~。
listen-on port 53 {0.0.0.0;}; 表示对所有地址的53号端口都进行监听
directory “/var/named”;
表示区域数据文件的存放目录
recursion yes;
是否允许递归, yes 表示允许。
那么如何理解DNS服务器的递归~？
以上图为例：我们假设 ns1.mageedu.com. 这台服务器是负责 mageedu.com.
这个域的解析，当有外部用户向n1.mageedu.com. 发起查询请求 (例如: 查询
ftp.mageedu.com. 这台主机)，那么此时是不能把这一类的查询划分到“递归”
这一类，这又是为什么~？很显然 n1.mageedu.com.这个DNS服务器本来就是负责为
mageedu.com.这个域内的所有的主机进行解析的，因此不论是谁来【请求| 查询】
，ns1.mageedu.com.都应该给出答案。不然的话 mageedu.com. 内的主机就没办
法在互联网上被别人访问了~~。那么哪种情况我们可以划分到“递归”这一类呢~？
比如有一台外部的主机向 ns1.mageedu.com. 这台DNS服务器发起一个查询 ( 查询：
www.sohu.com.这台主机)。但这是我们的ns1.mageedu.com. 有没有负责 sohu.com.
这个域的解析呢~？显然不负责sohu.com. 这个域的解析，如果此时ns1.mageedu.com
响应这台主机的请求的话是不是还需要把查询提交给根服务器（因为ns1.mageeedu.com.
本身是不负责 sohu.com. 这个域的解析，刚说过了）当ns1.mageedu.com. 获得了最终
的查询结果，并反馈给发起查询的那台主机时，这个过程就是递归的过程。
我们可以试想一下，如果我们允许 ns1.mageedu.com. 给所有的【人 | 主机】递归的话
，是不是很容易遭到别人的恶意攻击啊~ , 所以可以指定只请允许给给哪些【人 | 主机】递归，
使用：allow-recursion {172.16.0.0/16;};。当我们设定：recursion yes;那么
即给示给所有人递归。但是我们想过没有,即使能给所有人递归，但同时能给多少【人 | 主机】
递归是不是有一定限制的啊~
注意：默认状态下是可以递归的。
题外话：
有时我们在验证DNS服务器是否可以正常解析，需要首先清空一下缓存，如果之前缓存里面有相
应的条目存那很显然，到底有没有成功解析（是不是很难说啊~），所以要清空缓存。
Linux下DNS缓存实现通常有两种方式：
一种是用DNS缓存程序NSCD(name service cache daemon)负责管理DNS缓存。
一种实现DNS缓存则是用Bind来架设Caching Name Server来实现。
如果是清除NSCD上的Cache，可重新启动NSCD服务来达成清除DNS Cache的效果。用这个命令:
# service nscd restart
或是
#/etc/init.d/nscd restart
如果是清除BIND服务器上的CACHE，用这个命令:
# rndc flush
我们使用dig 合作来演示【允许递归 | 不允许递归】时的不同情况
dig + norecurse -t A www.baidu.com @192.168.1.50
dig + recurse -t A www.baidu.com @192.168.1.50
allow-query
允许哪些主机可以查询，默认的是允许所有主机进行查询，allow-query可以在【 options 】
定义也可以在【zone】里面定义。
allow-transfer
这个选项用于定义，哪些主机可以执行区域传送。其实很显然如果: 任意一个用户在任意一台
主机上都执行区域传送的话是不合理，且十分危险的。allow-transfer 可以在【 options 】
或者【 zone 】中定义，如果在【 options 】中定义，那么对所有区域都生效；如果是在
【zone】里面定义，很显然只是针对某个特定的区域生效。
区域zone 的定义：
区域定义通用格式：
zone “ZONE_NAME” IN {
type {master | slave | hint | forward};
file “区域数据文件”
};
根区域
zone “ .” IN {
type hint;
file “named.ca”;
};
主区域
zone “ZONE_NAME” IN {
type master;
file “区域数据文件”;
};
从区域
zone “ZONE_NAME” IN {
type slave;
masters {在从区域中要指明：主DNS服务器地址;};
file “区域数据文件”;
};
缓存DNS服务器 ---> 主DNS服务器--->从DNS服务器
一般而言我们要配置一个主DNS服务器，首先得把它配置成缓存DNS服务器，然后再配置我们需要负责
解析的域（例如：magedu.com.）就成了主DNS服务器。如果我们在配置区域的时候明确指明了它的类型是
Slave类型，那么它就是从DNS服务器（请记住一定是：先有主DNS服务器，再有从DNS服务器---先有主后有从）。
缓存DNS服务器配置
Setp-1 > 配置缓存DNS服务器
options {
directory “/var/named”;
}
zone “ . ” IN {
type hint;
file “named.ca”;
}
zone “localhost” IN {
type master;
file “named.localhost”;
}
zone “0.0.127.in-addr.arpa” IN {
type master;
file “named.loopback”;
}
以上就完成了一个缓存DNS服务器的简单配置。
我们还可以使用：named-checkconf 和named-checkzone来检查主配置文件和区域
数据文件是否存在语法错误。
此外，我们最好把 SELinux给关闭：
临时性的关闭SELinux:
获取SELinux运行状态 ---执行：getenforce
如果结为enforcing 表示处于运行状态
关闭SELinux ---执行：setenfoce 0 【关闭】
---执行：setenfoce 1 【开启】
执行getenforce可以看到结果已经变为【Permissive | disabled】，说明SELinux 已关闭。
永久性的关闭SELinux:
编辑：
/etc/selinux/config
把SELINUX=enforcing 改为：SELINUX=permissive 或SELINUX=disabled 就可以了。
缓存DNS服务器配置完之后我们可以尝试启动它，并查看相关的日志信息（/var/log/messages）
DNS服务器启动以后我们可以查看是否处于监听的状态：
如果我们想让DNS服务器，每次开机的时候都自动启起来，执行：chkconfig named on
主DNS服务器配置
以上是讲得缓存DNS服务器如何配置，那么主DNS服务器又该如何来配置~？
假设我们在互联网上注册了一人域名：mageedu.com.我们又该如何配置这个DNS服务器呢~？
Setp -1> 编辑主配置文件 /etc/named.conf
[root@CentOS58 named]# cat /etc/named.conf
options {
directory"/var/named";
};
zone "." IN {
type hint;
file"named.ca";
};
zone "localhost" IN {
type master;
file"named.localhost";
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file"named.loopback";
};
zone "mageedu.com" IN {
type master;
file"mageedu.com.zone";
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file"1.168.192.in-addr.arpa.zone";
};
[root@CentOS58 named]#
[root@CentOS58 named]#
Setp-2> 编辑区域数据文件
正向区域文件
[root@CentOS58 named]# cat /var/named/mageedu.com.zone
$TTL 600
mageedu.com. IN SOA ns1.mageedu.com. admin.mageedu.com. (
2015071001
1H
5M
2D
6H)
mageedu.com. IN NS ns1.mageedu.com.
ns1.mageedu.com. IN A 192.168.1.50
www.mageedu.com. IN A 192.168.1.50
ftp.mageedu.com. IN CNAME www
反向区域文件
[root@CentOS58 named]# cat/var/named/1.168.192.in-addr.arpa.zone
$TTL 600
1.168.192.in-addr.arpa. IN SOA ns1.mageedu.com. admin.mageedu.com. (
2015071001
1H
5M
2D
6H)
1.168.192.in-addr.arpa. IN NS ns1.mageedu.com.
50.1.168.192.in-addr.arpa. IN PTR www.mageedu.com.
50.1.168.192.in-addr.arpa. IN PTR ftp.mageedu.com.
从上面的配置不难看出：我们在缓存DNS服务器上稍做修改就成了主DNS服务器。
那么我们（使用dig命令）验证一下是否能够正常解析：
---正向查询结果
片段-1 ：QUESTION SECTION
www.mageedu.com. IN A
表示查询 www.magedu.com. 这家伙的A记录
片段-2：ANSWER SECTION
www.mageedu.com. 600 IN A 192.168.1.50
表示查询的结果
片段-3：AUTHORITY SECTION
mageedu.com. 600 IN NS ns1.mageedu.com.
明确告诉查询提交方ns1.mageedu.com. 是【mageedu.com. 这个域| www.mageedu.com.】
的权威DNS服务器。
片段-4：ADDITIONAL SECTION
ns1.mageedu.com. 600 IN A 192.168.1.50
前面既然给出权威DNS服务器是谁，那么【这里| 附加段中】干脆给出其A 记录，即IP 地址。
---反向查询结果
从DNS服务器配置
说明：这个地方我调整了一主DNS服务器的IP地址，添加了一块新的网卡（172.16.0.1），之前的那个IP
192.168.1.50 【禁用了】，从DNS服务器的IP为（172.16.0.10），因为192.168.1.X 这个网段是工作
环境中的物理网磁段，因为IP不够用了，所以只有在【主 | 从】服务器上分别各添加了一张虚拟网卡，启
用 172.16.0这个网段。从服务器的配置相对比较简单，我们只需要配置：主配置文件“/etc/named.conf”
, 连区域数据文件都不用去建立，因为当主DNS服务器与从DNS服务器同步时，会自动创建相应的区域数据文件。
【从DNS服务器 --- 172.16.0.10 】的主配置文件如下：
[root@localhost/]# cat /etc/named.conf
options{
directory "/var/named";
};
zone"." IN {
type hint;
file "named.ca";
};
zone"localhost" IN {
type master;
file "named.localhost";
allow-transfer {none;};
};
zone"0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-transfer {none;};
};
zone"mageedu.com" IN {
type slave;
file"slaves/mageedu.com.zone";
masters {172.16.0.1;};
allow-transfer {none;};
};
zone"0.16.172.in-addr.arpa" IN {
type slave;
file"slaves/0.16.172.in-addr.arpa.zone";
masters {172.16.0.1;};
allow-transfer {none;};
};
【主DNS服务器--- 172.16.0.1】的主配置文件如下：
[root@CentOS58 /]# cat /etc/named.conf
options{
directory "/var/named";
notify yes;
};
zone"." IN {
type hint;
file "named.ca";
};
zone"localhost" IN {
type master;
file "named.localhost";
allow-transfer {none;};
};
zone"0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-transfer {none;};
};
zone"mageedu.com" IN {
type master;
file "mageedu.com.zone";
};
zone"0.16.172.in-addr.arpa" IN {
type master;
file"0.16.172.in-addr.arpa.zone";
};
【主DNS服务器的区域数据文件 ---】的主配置文件如下：
正向区域数据文件：
反向区域数据文件：
【提示:】1. 在搭建测试环境下的DNS服务器时，建议首先把SELinux和iptables关掉。
2. 此外，还需要检查一下 /etc/resolv.conf 的配置是否正确。
3. 如果DNS服务器是主、从结构，还需在从DNS服务器上检查主、从间的同步是否正常。
4. 主服务器可以设定“ notify yes; ”以推送方式通知从DNS服务器进行同步。
5. 从DNS服务器主配置文件中的【区域名称】和主DNS服务器主配置文件中的【区域名称】
要一致。
dig命令：
dig
-t 表示查询的资源记录类型。
例如【查询某台主机】：
dig -t A www.mageedu.com. @192.168.1.50
例如【使用dig命令进行：完全区域传送或者增量区域传送】：
dig -t axfr maggedu.com.
dig -t ixfr mageedu.com.
其实很显然如果: 任意一个用户在任意一台主机上都执行区域传送的话是不合理，且十分危险的。
+ trace : 表示【追踪 | 跟踪】一个【主机 | 域名】的解析过程。
+ [no]recurse: 表示是否启用递归
我们使用dig 合作来演示【允许递归 | 不允许递归】时的不同情况
dig + norecurse -t A www.baidu.com @192.168.1.50
dig + recurse -t A www.baidu.com @192.168.1.50
--- 与dig 命令类似的几个命令（host 、nslookup）：
host -t RRT NAME
以上这条命令也可以查询某个名称的解析结果~ ，但是host 命令后面不能“@”。
nsslookup(这个命令有2种工作模式：交互式模式、命令行模式)
nslookup我们只讲交互模式，此外我们的windows也支持这命令
nslookup>
server IP
set q=RRT
NAME
免费域名申请：我们知道在国内申请一个域名通常都需要注册备案的，但是一个人网站就不需要。
Godaddy.com
什么是泛域名解析
*.mageedu.com. IN A
我们如果期望用户通过域名（例如：mageedu.com.）,就可以访问到我们的web站点。我们就可以
使用泛域名解析的方式来实现。又或者可以这样理解，当用户输入的不是www.mageedu.com.p这
个主机名，而是【任意的 | 或是不存在的】主机名（例如：opppp.mageedu.com.），我们都能把用
户提交的请求定向到www.mageedu.com.这台主机上去。这就是泛域名解析带来的好处。但是对于一个
非常大的组织使用泛域名解析并不是一种可取的做法 (例如：有一台主机“pop3.mageedu.com”但是
用户输入时不小心变成“popp3.mageedu.com”, 我们使用泛域名解析是不是就把它定向到web服务器
www.mageedu.com上去了，这样显然是不合适的，那么有什么方法在用户输入错误的主机名时，给用户
一个提示呢~？可以使用 URL 重定向，给用户一个展示一个错误页面)。
区域传送
主DNS服务器：172.16.0.1
从DNS服务器：172.16.0.10
我们可以执行：【tail /var/log/messages】查看相关的日志信息以判断区域传送是否成功。
172.16.0.1
我们假设在主配置文件上只允许 172.16.0.10 这台主机对 mageedu.com. 这个域，进行区域传送
，那么在从DNS服务器上执行的结果就如下图所示：
我们在主DNS服务器【本机】上执行区域传送，显然也是不可以的，因为在主配置文件中严格了限定了只有
IP 为： 172.16.0.10 这台主机才允许区域传送。
