仍是出于项目的须要,把Bind比较高级的功能作一个梳理,这其中包含:DNS递归迭代查询、DNS子域受权、DNS转发、DNS主从区域传输、DNS数据加密,每个内容不只记录了它的实现原理,也相应的配上了我一行一行代码的实践测试及结果。html
全部的测试都是基于我原来的文章:Bind服务搭建及测试上的代码来进行的,因此下面的代码若是有不理解的,请去看看我以前写的文章。ios
为何要把DNS的查询称之为递归迭代查询:算法
递归是由于:shell
用户端向个人服务端发起一次查询请求,那么服务端若是有结果就返回,若是没有结果就像上一级服务器再发一次请求,直到找到用户须要的IP或者域名,这个过程能够称之为递归。缓存
迭代是由于:安全
当服务端向上一级服务器法请求的时候,它并非一次请求就结束了,先是根域,再是二级域名这样了,有屡次的请求跟返回动做,这个过程能够称之为迭代。服务器
我在Bind搭建及测试这篇博文里面,对它们的流程作了更详细的叙述,这里就很少写了。app
Bind既然有一个复杂的查询流程,那么与之相对应的就会有一系列的配置项来控制这个流程。下面讲的参数都是基于Bind的主配置文件named.conf。测试
named.conf配置文件的内容以下所示:加密
options {
directory "/var/named";
recursion yes;
};复制代码
zone "." {
type hint;
file "named.ca";
};复制代码
zone "liumapp.com" {
type master;
file "liumapp.com.zone";
};复制代码
zone "cnametest.com" {
type master;
file "cnametest.com.zone";
};复制代码
zone "32.29.115.in-addr.arpa" {
type master;
file "115.29.32.zone";
};
能够看到,我默认是把递归查询开启的复制代码
随便查询一个域名,好比“www.qqq.com”
能够发现,Bind为了找到www.qqq.com对应的IP地址,往上层域名服务器迭代了7次才找到最终结果。
如今咱们将配置文件的recursion改成no,重启Bind以后再查询一个新的域名,好比"www.qqqq.com"(www.qqq.com已经作了缓存)
能够看到,关闭递归后咱们是查不到新域名的解析记录的。
在DNS迭代查询的状况下,常常会用到NS记录,一样的,在DNS子域受权下面,NS记录也会常常被用到。
子域受权:
好比个人一台服务器A负责liumapp.com的权威域名解析,它再受权服务器B对liumapp.com的子域名:child.liumapp.com进行解析,这就叫作子域受权。
DNS迭代查询利用的就是子域受权:经过根域,到二级域再依次往下迭代查询。
个人父服务器IP为115.29.32.62,其解析的域名为www.liumapp.com,子服务器IP为106.14.212.41,其解析的域名为www.test.liumapp.com
首先在父服务器上,咱们要对子服务器进行受权,具体配置liumapp.com.zone文件,添加以下内容:
test.liumapp.com. IN NS ns1.test
ns1.test IN A 106.14.212.41复制代码
大意就是给liumapp.com的子域名test.liumapp.com分配权限给ns1.test,而后指定ns1.test的IP为106.14.212.41
重启父服务器,而后进入子服务器的shell命令面板
首先咱们对named.conf作一个备份,而后把它的内容修改成:
options {
directory "/var/named";
};复制代码
zone "test.liumapp.com" {
type master;
file "test.liumapp.com.zone";
};
复制代码
而后在/var/named/目录下添加一个test.liumapp.com.zone文件,其内容为:
$TTL 7200
@ IN SOA test.liumapp.com. liumapp.com.gmail.com. (222 1H 15M 1W 1D)
@ IN NS dns1.liumapp.com.
dns1.liumapp.com. IN A 106.14.212.41
www.test.liumapp.com. IN A 106.14.212.42
复制代码
接下来重启Bind。而后咱们进行测试,首先对父服务器进行解析:
dig @115.29.32.62 www.test.liumapp.com复制代码
结果为:
而后咱们对子服务器进行解析:
dig @106.14.212.41 www.test.liumapp.com复制代码
结果为:
假设有一个局域网,内部有两台DNS服务器,命名为A和B,局域网经过防火墙对外开放,可是只有A可以直接对外提供DNS解析服务,B只能在局域网内的内网进行访问,那当须要用到B的DNS解析的时候,就是经过A的forwarding转发来实现。
首先看一下关于转发的配置项
一样是父服务器115.29.32.62和子服务器106.14.212.41,咱们如今把父服务器用来负责DNS的某一个域做为转发,子服务器用来负责某一个域的权威解析。
如今咱们先配置子服务器的权威解析:
首先进入/var/named目录,新建一个文件dnstest.com.zone(这个域名我并无拥有它,只是为了测试方便随便写的),其内容为:
$TTL 7200
@ IN SOA dnstest.com. liumapp.com.gmail.com. (222 1H 15M 1W 1D)
@ IN NS dns.dnstest.com.
dns.dnstest.com. IN A 106.14.212.41
www.dnstest.com. IN A 6.6.6.6
复制代码
而后修改named.conf,添加下列内容:
zone "dnstest.com" {
type master;
file "dnstest.com.zone";
};复制代码
同时删除原来的
zone "test.liumapp.com" {
type master;
file "test.liumapp.com.zone";
};复制代码
重启Bind。
而后进入父服务器的shell操做面板,在开始以前,咱们要注意一点,就是Bind的DNS转发只有在Bind9版本以上才支持,因此在开始以前,咱们先使用命令查看一下Bind的版本:
nslookup -q=txt -class=CHAOS version.bind复制代码
个人服务器上出来的结果是:
[root@iZ28vhwdq63Z ~]# nslookup -q=txt -class=CHAOS version.bind.复制代码
Server: 10.202.72.116复制代码
Address: 10.202.72.116#53复制代码
version.bind text = "9.9.9-P3-RedHat-9.9.9-2.1.alios6"复制代码
而后修改named.conf,添加如下内容:
zone "dnstest.com" {
type forward;
forwarders {106.14.212.41;};
}复制代码
接下来咱们在父服务器上使用dig命令:
dig @127.0.0.1 www.dnstest.com复制代码
请求解析www.dnstest.com域名,结果以下:
同时要注意,forward的正常使用须要递归查询recursion开启。
区域是DNS服务器的管辖范围, 是由DNS名称空间中的单个区域或由具备上下隶属关系的紧密相邻的多个子域组成的一个管理单位。 所以, DNS名称服务器是经过区域来管理名称空间的,而并不是以域为单位来管理名称空间,但区域的名称与其管理的DNS名称空间的域的名称是一一对应的。或者说,一个区域对应一系列域名的解析。
假设咱们有两台服务器,分别为dns主服务器Master和dns从服务器slave,那么他们之间的dns主从同步步骤是这样的:
在开始配置以前,先要注意几个事项:
Master服务器
zone "liumapp.com" {
type master;
notify yes;
also-notify{106.14.212.41;};
file "liumapp.com.zone";
}复制代码
上面的notify yes表示开启notify这个功能,also-notify{}里面放的是slave服务器的IP列表。
Slave服务器
options{复制代码
directory "/var/named";复制代码
allow-query { any; };复制代码
recursion yes;复制代码
};
zone "liumapp.com" {复制代码
type slave;复制代码
file "slaves/liumapp.com.zone";复制代码
masters {115.29.32.62;};复制代码
};复制代码
上面的file表示从主服务器同步过来的信息存放地址,我这里就表示存放在/var/named/slaves/liumapp.com.zone
我把IP为115.29.32.62的dns server做为个人master,IP为106.14.212.41的dns server做为个人slave。
首先咱们按照上面两段代码进行主从服务器的配置。
而后重启两台服务器的Bind,重启以后,应该就可以在从服务器的/var/named/slaves/下找到一个liumapp.com.zone文件,它的内容应该跟主服务器的/var/named/liumapp.com.zone一致。
因此,这个时候咱们无论使用命令
dig @115.29.32.62 www.liumapp.com复制代码
向主服务器请求www.liumapp.com的解析仍是
dig @106.14.212.41 www.liumapp.com复制代码
向从服务器请求www.liumapp.com的解析,获得的结果最终都是同样的。
如今咱们按照上面的配置走完了一遍以后,来测试一下主从服务器之间的同步。
在Master服务器的/var/named/liumapp.com.zone文件上,咱们添加一条解析记录:
liumei.liumapp.com. IN A 8.8.5.6复制代码
而后添加一下它的serial number值,也就是:
liumapp.com. IN SOA liumapp.com. liumapp.com.gmail.com8 (225 1H 15M 1W 1D)复制代码
这条记录里面的倒数第5个数“225”,咱们把它改成226便可。
重启服务器以后,敲命令:
dig @106.14.212.41 liumei.liumapp.com复制代码
便可成功在子服务器上解析到liumei.liumapp.com的记录为8.8.5.6
首先,咱们在本地一台电脑上使用一个命令:
dig @115.29.32.62 axfr liumapp.com复制代码
不出意外,应该可以获得liumapp.com在115.29.32.62这台DNS server上的全部解析记录
可是从安全角度来说,我确定不但愿这样的事情发生,因此就要用到传输限制。
经过主机IP来限制访问。复制代码
* allow-transfer : {address_list | none} , 容许域传输的机器列表
复制代码
经过密钥对数据进行加密。
事务签名的测试我会放在后面的DNS数据加密里面来作。
复制代码
咱们在主服务器上的named.conf配置文件中进行修改:
zone "liumapp.com" {复制代码
type master;复制代码
notify yes;复制代码
also-notify {106.14.212.41;};复制代码
allow-transfer{106.14.212.41;};复制代码
file "liumapp.com.zone";复制代码
};复制代码
重启Bind以后,回到本地电脑上,继续使用命令:
dig @115.29.32.62 axfr liumapp.com复制代码
结果以下,请求已被拒绝。
可是经过106.14.212.41是能够获取数据的:
dig @106.14.212.41 axfr liumapp.com复制代码
结果以下:
* 概述:文件加密和解密使用相同的密钥,简单快捷。
* 流程:假定有发送方A和接收方B,A和B有相同的密钥,A发送明文给B以前,经过密钥和加密算法,将明文加密成密文,发送给B,B再经过密钥和解密算法,将密文解密成明文。复制代码
* 概述:密钥包括公钥和私钥,安全性较DES方式高。
* 流程:假定有发送方A和接收方B,B有本身的私钥和公钥,A须要获取B的公钥,获取以后,A首先本身生成一个会话密钥,而后这个会话密钥经过B的公钥进行加密,加密后发送给B,B再经过本身的私钥对它进行解密,从而获得A生成的会话密钥。以后,A经过本身的会话密钥将要发送的明文进行加密,发送给B,B经过事先获得的会话密钥对发送过来的密文进行解密从而获得明文。复制代码
事务签名能够经过两种加密方式来实现,分别是:
如今比较经常使用的是TSIG这种方法。
参数:
首先咱们进入主服务器,而后生成key:
在主服务器的/usr/key目录下,注意赋予key目录named用户的读权限
输入如下命令:
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST liumapp-key复制代码
我生成的公钥文件和私钥文件其内容以下所示:
而后咱们复制私钥里面的那段key的内容,再进入/var/named/chroot/etc目录,新建一个liumapp-key文件
其内容为:
key "liumapp-key" {复制代码
Algorithm hmac-md5;复制代码
secret "ghWgud4mhN11PKBIITgxbg==";复制代码
};复制代码
上面的secret的值是从生成的私钥文件中复制来的。
而后编写named.conf文件,添加如下内容:
include "/var/named/chroot/etc/liumapp-key";复制代码
注意,这段内容要放在zone "liumapp.com"以前。
而后修改zone "liumapp.com"的配置,最终配置结果以下:
include "/var/named/chroot/etc/liumapp-key";复制代码
zone "liumapp.com" {
type master;
notify yes;
also-notify {106.14.212.41;};
allow-transfer{key "liumapp-key";};
file "liumapp.com.zone";
};复制代码
上面的allow-transfer的key的值是我命名的那个值。
而后咱们重启Bind,接下来是配置slave从服务器,不过在配置以前,须要先把咱们的配置文件liumapp-key拷贝过去:
使用命令:
scp liumapp-key root@106.14.212.41:`pwd`复制代码
结果以下所示:
而后在从服务器的named.conf中进行配置,一个是把liumapp-key包含进去,而后配置key,最终结果以下所示:
options{复制代码
directory "/var/named";复制代码
allow-query { any; };复制代码
recursion yes;复制代码
};复制代码
include "/var/named/chroot/etc/liumapp-key";复制代码
server 115.29.32.62 {复制代码
keys {"liumapp-key";};复制代码
};复制代码
zone "dnstest.com" {复制代码
type master;复制代码
file "dnstest.com.zone";复制代码
};复制代码
zone "liumapp.com" {复制代码
type slave;复制代码
file "slaves/liumapp.com.zone";复制代码
masters {115.29.32.62;};复制代码
};复制代码
重启从服务器的Bind服务,而后咱们再回到主服务器:
添加一条liumapp.com.zone下的A记录,固然还须要递增一下serial number也不知道加了多少,总之最后个人这个ZONE的内容以下所示:
$TTL 7200复制代码
liumapp.com. IN SOA liumapp.com. liumapp.com.gmail.com8 (226 1H 15M 1W 1D)复制代码
liumapp.com. IN NS dns1.liumapp.com.复制代码
dns1.liumapp.com. IN A 115.29.32.62复制代码
www.liumapp.com. IN A 106.14.212.41复制代码
liumei.liumapp.com. IN A 8.8.5.6复制代码
heiheihei.liumapp.com. IN A 9.9.9.9复制代码
@ IN MX 10 mail复制代码
mail IN A 115.29.32.63复制代码
test.liumapp.com. IN NS ns1.test复制代码
ns1.test IN A 106.14.212.41复制代码
而后重启bind,再使用命令:
tail -f /var/log/messages复制代码
获得的信息以下所示:
能够看到,我修改了liumapp.com.zone以后,主服务器立刻同步到了从服务器上,而他们之间的交流,就是用到了TSIG事务签名。