云网牛站
所在位置:首页 > Linux培训 > 第13章 使用Bind提供域名解析服务

第13章 使用Bind提供域名解析服务

2017-10-26 09:51:02作者:Linux就该这么学稿源:Linux就该这么学

Linux就该这么学第13章 使用Bind提供域名解析服务简述

本章节首先从介绍DNS域名解析服务的原理及作用引入理论知识内容,充分了解DNS域名查询功能中的正向解析及反向解析的作用,并实践操作部署DNS主服务器上的正、反解析工作模式,让读者更能深刻体会到DNS域名查询的便利及强大。

DNS域名解析服务作为互联网基础设施的重要一环,通过学习部署DNS从服务器以及DNS缓存服务器来提高用户的域名查询体验,使用chroot牢笼机制插件来保证bind服务程序的可靠性。实践操作在DNS主服务器与DNS从服务器之间部署TSIG密钥加密验证功能,进一步保证迭代查询中数据的安全性。最后还给读者们加入了DNS分离解析技术的实战讲解,让来源于不同国家的用户都能获得最优的网站访问体验。总之,当您学完本章节内的课程后,一定会对DNS域名解析服务有更深入的认识,了解互联网世界中默默为用户提供服务的重要角色。

 

本章目录结构

13.1.DNS域名解析服务

13.2.安装Bind服务程序

13.2.1.正向解析实验

13.2.2.反向解析实验

13.3.部署从服务器

13.4.安全的加密传输

13.5.部署缓存服务器

13.6.分离解析技术

 

13.1.DNS域名解析服务

域名相比于IP地址来讲更有寓意,因此也更容易被记住,所以用户通常更习惯输入域名来访问网络中的资源,但在互联网中计算机之间只能基于IP地址来识别对方主机,互联网中传输数据也必须是基于外网的IP地址才能完成。因此为了降低网民访问互联网网站等资源的门槛,就出现一项叫做DNS域名解析服务(Domain Name System)的技术,这是一项用于管理和解析域名与IP地址对应关系的服务,简单来说就是能够接受用户输入的域名或IP地址,然后自动查找出匹配的信息,使用这项技术后咱们只需要在浏览器中输入一串域名就能打开想要访问的网站了。

平时同学们使用最多的就是输入某个域名来访问网站了吧,这其实仅仅是DNS域名解析服务功能的一小部分而已。DNS技术能够提供正向解析和反向解析,正向解析就是根据用户输入的某个域名查找到对应的IP地址信息,而反向解析则是根据用户输入的IP地址查找到对应的域名信息。对于互联网庞大的域名和IP地址对应关系数据库,DNS服务协议采用类似目录树的层次结构记录域名与IP地址的映射对应关系,形成一个分布式的数据库系统,如图13-1所示:

第13章 使用Bind提供域名解析服务

图13-1 DNS服务技术结构模型

域名后缀被分为了国际域名、国内域名和国外域名三类,原则上对每个后缀都是有定义的,但实际使用上可以不必严格遵守,目前使用最广泛的后缀就是.com,原意是商业公司(Commercial organizations),其次还有.org(非营利组织)、.gov(政府部门)、.net(网络服务商)、.edu(教研机构)、.pub(公众大众)、.cn(中国国家)等等十几个常见的域名后缀。

当今世界越来越信息化,大数据、云计算、物联网、人工智能等等新鲜技术也不断涌出,全球网民数量据说已经要超过了35亿,而且还在以每年10%的速度飞速增长。假设每个网民每天只访问一个网站,而且只访问一次,那么也会产生出35亿次左右的查询请求,如此庞大的请求数量肯定无法由某一个服务器全部处理掉。DNS技术作为互联网基础设施服务,为了能够为网民提供不间断、稳定、快速的域名查询服务,进而保证互联网的正常运转,按照工作形式上分为有主服务器、从服务器和缓存服务器三种类型:

1.主服务器:在特定区域内具有唯一性、负责维护该区域内的域名与IP地址对应关系。

2.从服务器:从主服务器中获得域名与IP地址对应关系并维护,以防主服务器宕机等情况。

3.缓存服务器:通过向其他域名解析服务器查询获得域名与IP地址对应关系,提高重复查询时的效率。

简单来说,主服务器就是真正管理域名和IP地址关系的。从服务器是帮助主服务器打下手,在各个国家、省市、地区、街道中进行部署,让用户能够就近进行域名查询,进而减轻主服务器负载压力。而缓存服务器是一种不太常用的工作形式,一般是工作在企业内网的网关位置,加速用户域名查询请求。这三种DNS工作形式将会在下面逐一进行讲解,现在仅需要大致了解即可。

DNS域名解析服务采用分布式数据结构保存海量区域数据信息,递归查询是指用于客户机向DNS服务器的查询请求,而迭代查询是指用于DNS服务器向其它DNS服务器的查询请求。根据咱们刚刚学习过的DNS服务器工作形式以及技术服务方式,可以猜想下当用户向就近的一台DNS服务器发起了对某个域名的查询请求之后的事情,用户从互联网中查询过程大致流程如图13-2所示:

第13章 使用Bind提供域名解析服务

图13-2 DNS查询流程图

当用户向就近的DNS服务器请求一个域名时,正常情况会由本地DNS服务器向指定的DNS服务器主机发送迭代查询请求,而如果该DNS服务器中也没有要查询的数据,则会进一步向上级DNS服务器进行多次迭代查询,其中最高级、最权威的根DNS服务器主机总共有13台,分布在世界各地:

第13章 使用Bind提供域名解析服务

 

13.2.安装Bind服务程序

BIND伯克利互联网域名服务(Berkeley Internet Name Daemon)是一款全球互联网使用最广泛、能够提供安全可靠、快捷高效的域名解析的服务程序。DNS域名解析服务作为互联网的基础设施服务,其责任之重同学们可想而知,因此刘遄老师推荐您在安装bind服务程序的时候加上chroot扩展包,chroot俗称为监牢安全机制,能够有效的限制bind服务程序仅能对自身配置文件进行操作,从而保证了整个服务器的安全,在生产环境中一直力荐使用的功能~

[root@linuxprobe ~]# yum install bind-chroot

Loaded plugins: langpacks, product-id, subscription-manager

………………省略部分输出信息………………

Installing:

bind-chroot x86_64 32:9.9.4-14.el7 rhel 81 k

Installing for dependencies:

bind x86_64 32:9.9.4-14.el7 rhel 1.8 M

Transaction Summary

Install 1 Package (+1 Dependent package)

Total download size: 1.8 M

Installed size: 4.3 M

Is this ok [y/d/N]: y

Downloading packages:

Total 28 MB/s | 1.8 MB 00:00 

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

Installing : 32:bind-9.9.4-14.el7.x86_64 1/2 

Installing : 32:bind-chroot-9.9.4-14.el7.x86_64 2/2 

Verifying : 32:bind-9.9.4-14.el7.x86_64 1/2 

Verifying : 32:bind-chroot-9.9.4-14.el7.x86_64 2/2 

Installed:

bind-chroot.x86_64 32:9.9.4-14.el7 

Dependency Installed:

bind.x86_64 32:9.9.4-14.el7 

Complete!

Bind服务程序的配置并不简单,因为要想为用户提供健全的DNS查询服务,首先就要在本地保存有相关的域名数据库,而如果把所有域名和IP地址对应关系都写入到某个配置文件中,那估计要有上千万条的参数了,这样既不利于程序的执行效率,也不方便今后修改维护数据。因此在bind服务程序中有三个比较关键的地方,首先区域配置文件(/etc/named.rfc1912.zones)是用来保存域名和IP地址对应关系所在位置的文件,也就是说像是咱们书籍的目录一样,对应着每个域和IP地址段具体所在的位置,当需要查看或修改的时候根据里面的位置找到相关文件即可。其次数据配置文件目录(/var/named)是用来保存域名和IP地址真实对应关系的目录,咱们把需要为用户解析的域、IP地址段关系文件放置在该目录中即可,最后与往常不同的是主配置文件(/etc/named.conf),bind服务程序的主配置文件只有58行,其中除去注释信息和空行后实际有效参数才仅仅30行左右,仅用于定义bind服务程序的运行参数而已。

BIND伯克利互联网域名服务的服务程序名称叫做named,首先需要在/etc目录中找到对应的主配置文件,然后把第11、17行的地址均修改为any,分别代表着服务器上所有IP地址均可提供DNS查询服务,以及允许所有人对本机进行DNS查询请求,这两个要修改的地方请同学们一定要留心修改好:

[root@linuxprobe ~]# vim /etc/named.conf

1 //

2 // named.conf

3 //

4 // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

5 // server as a caching only nameserver (as a localhost DNS resolver only).

6 //

7 // See /usr/share/doc/bind*/sample/ for example named configuration files.

8 //

10 options {

11 listen-on port 53 { any; };

12 listen-on-v6 port 53 { ::1; };

13 directory "/var/named";

14 dump-file "/var/named/data/cache_dump.db";

15 statistics-file "/var/named/data/named_stats.txt";

16 memstatistics-file "/var/named/data/named_mem_stats.txt";

17 allow-query { any; };

18 

19 /* 

20 - If you are building an AUTHORITATIVE DNS server, do NOT enable re cursion.

1,1 Top

21 - If you are building a RECURSIVE (caching) DNS server, you need to enable 

22 recursion. 

23 - If your recursive DNS server has a public IP address, you MUST en able access 

24 control to limit queries to your legitimate users. Failing to do so will

25 cause your server to become part of large scale DNS amplification 

26 attacks. Implementing BCP38 within your network would greatly

27 reduce such attack surface 

28 */

29 recursion yes;

30 

31 dnssec-enable yes;

32 dnssec-validation yes;

33 dnssec-lookaside auto;

34 

35 /* Path to ISC DLV key */

36 bindkeys-file "/etc/named.iscdlv.key";

37 

38 managed-keys-directory "/var/named/dynamic";

39 

40 pid-file "/run/named/named.pid";

41 session-keyfile "/run/named/session.key";

42 };

43 

44 logging {

45 channel default_debug {

46 file "data/named.run";

47 severity dynamic;

48 };

49 };

50 

51 zone "." IN {

52 type hint;

53 file "named.ca";

54 };

55 

56 include "/etc/named.rfc1912.zones";

57 include "/etc/named.root.key";

58 

如前面所讲到的,在bind服务程序中的区域配置文件(/etc/named.rfc1912.zones)是用来保存域名和IP地址对应关系所在位置的文件,切记这个文件用于定义域名与IP地址解析规则保存的文件位置以及区域服务类型等内容,而不是往里面写入具体的域名、IP地址对应关系等等信息。服务类型包括有三种,分别为hint(根区域)、master(主区域)、slave(辅助区域),其中常用的master和slave就是主服务器和从服务器的意思。如图13-3与图13-4所示,分别为域名转换为IP地址的正向解析参数与IP地址转换成域名的反向解析参数:

第13章 使用Bind提供域名解析服务

图13-3 正向解析参数

第13章 使用Bind提供域名解析服务

图13-4 反向解析参数

接下来的实验中会分别对主配置文件、区域信息文件与数据文件做修改,如果实践操作中服务启动失败,您怀疑是参数写错导致的话,可以执行下named-checkconf命令或named-checkzone命令来分别用于检查主配置与区域数据文件中语法或参数的错误。

 

13.2.1.正向解析实验

DNS域名解析服务的正向解析是根据主机名(域名)查找到对应的IP地址,这是平时最常用的工作模式,也就是说当用户输入了一个域名后bind服务程序会进行自动匹配,然后把查询到对应的IP地址返回给用户。

第1步:编辑区域配置文件,该文件内默认已经有了一些无关紧要的解析参数,主要目的是为了让用户有个参考而已,同学们可以把下面参数添加至区域配置文件内容的最下面即可,当然也可以把原有信息全部清空,只保留自己的域名解析信息:

[root@linuxprobe ~]# vim /etc/named.rfc1912.zones

zone "linuxprobe.com" IN {

type master;

file "linuxprobe.com.zone";

allow-update {none;};

};

第2步:编辑域名数据文件,咱们可以从/var/named目录中复制一份正向解析的模板文件(named.localhost),然后把域名和IP地址的对应数据填写到文件后保存即可,复制的时候请加上-a参数,意在保留原始文件的所有者、所有组、权限属性等信息,这样让bind服务程序能顺利的读取该文件的内容:

[root@linuxprobe ~]# cd /var/named/

[root@linuxprobe named]# ls -al named.localhost

-rw-r-----. 1 root named 152 Jun 21 2007 named.localhost

[root@linuxprobe named]# cp -a named.localhost linuxprobe.com.zone

然后编辑域名数据文件,记得编写后要重启一下named服务才能让新的解析数据生效哦~另外由于正向解析文件中的参数较多、而且相对都比较重要,所以刘遄老师在每个参数后面都做了简要说明:

[root@linuxprobe named]# vim linuxprobe.com.zone

[root@linuxprobe named]# systemctl restart named

第13章 使用Bind提供域名解析服务

第3步:检验解析结果,同学们是不是还意犹未尽?但到此就已经完整部署好了DNS正向解析功能啦,为了检验解析结果,请您一定要先把Linux系统网卡中的DNS地址参数修改成本机IP地址,这样服务器就会使用由本机提供的DNS查询服务啦~nslookup命令用于检测能否从网络DNS服务器中查询到域名与IP地址的解析记录,进而更准确的检查DNS服务是否已经能够为用户提供服务。

[root@linuxprobe ~]# systemctl restart network

[root@linuxprobe ~]# nslookup

> www.linuxprobe.com

Server: 127.0.0.1

Address: 127.0.0.1#53

Name: www.linuxprobe.com

Address: 192.168.10.10

> bbs.linuxprobe.com

Server: 127.0.0.1

Address: 127.0.0.1#53

Name: bbs.linuxprobe.com

Address: 192.168.10.20

 

13.2.2.反向解析实验

DNS域名解析服务的反向解析作用是根据用户提交的IP地址查找到对应的域名信息,这种解析方式相比于正向解析来讲确实很少被使用。一般的作用就是对某个IP地址上所有绑定的域名进行整体屏蔽,屏蔽由这些域名发送出来的垃圾邮件,也可以针对某个IP地址进行域名反向解析,能够大致判断出有多少个网站正在运行在上面,对于购买虚拟主机时判断有无严重超售问题很有参考价值。

第1步:编辑区域配置文件,除了格式不要写错以外,同学们还需要记住此处定义的数据文件名称,一会要再/var/named目录中建立与其同名对应的文件才算配置妥当,反向解析是把IP地址解析成域名格式,因此定义的zone(区域)应该要把IP地址反写,原先是192.168.10.0,那么反写后就是10.168.192啦,只写IP地址的网络位,把下列参数添加至正向解析参数后面吧:

[root@linuxprobe ~]# vim /etc/named.rfc1912.zones

zone "linuxprobe.com" IN {

type master;

file "linuxprobe.com.zone";

allow-update {none;};

};

zone "10.168.192.in-addr.arpa" IN {

type master;

file "192.168.10.arpa";

};

第2步:编辑域名数据文件,首先在/var/named目录中复制一份反向解析的模板文件(named.loopback),然后把下面参数填写至文件中即可,IP地址仅需要写主机位,如图13-5所示:

第13章 使用Bind提供域名解析服务

图13-5 反向解析文件IP地址参数规范

[root@linuxprobe named]# cp -a named.loopback 192.168.10.arpa

[root@linuxprobe named]# vim 192.168.10.arpa

[root@linuxprobe named]# systemctl restart named

第13章 使用Bind提供域名解析服务

第3步:检验解析结果,刚刚正向解析实验中已经把系统网卡中DNS地址参数修改成了本机IP地址,因此可以直接使用nslookup命令来检验解析结果,仅需输入IP地址即可查询到对应的域名信息:

[root@linuxprobe ~]# nslookup

> 192.168.10.10

Server: 127.0.0.1

Address: 127.0.0.1#53

10.10.168.192.in-addr.arpa name = ns.linuxprobe.com.

10.10.168.192.in-addr.arpa name = www.linuxprobe.com.

10.10.168.192.in-addr.arpa name = mail.linuxprobe.com.

> 192.168.10.20

Server: 127.0.0.1

Address: 127.0.0.1#53

20.10.168.192.in-addr.arpa name = bbs.linuxprobe.com.

 

13.3.部署从服务器

作为互联网的基础设施服务,咱们有必要保证DNS域名解析服务的正常运转,为网民提供不间断、稳定、快速的域名查询服务。从服务器是DNS工作模式的一种类型,部署从服务器主要就是为了减轻主服务器的负载压力,以及当网民访问就近的本地DNS服务器时还能提升查询效率,也就是说从服务器可以从主服务器上抓取指定的区域数据文件,起到备份解析记录与负载均衡的作用,实验中主服务器与从服务器的IP地址如下对应关系:

主机名称-操作系统-IP地址

主服务器-红帽RHEL7操作系统-192.168.10.10

从服务器-红帽RHEL7操作系统-192.168.10.20

第1步:在主服务器的区域信息文件中允许该从服务器的更新请求,即修改allow-update { 允许更新区域信息的主机地址;};参数,然后记得重启下主服务器的DNS服务程序哦。

[root@linuxprobe ~]# vim /etc/named.rfc1912.zones

zone "linuxprobe.com" IN {

type master;

file "linuxprobe.com.zone";

allow-update { 192.168.10.20; };

};

zone "10.168.192.in-addr.arpa" IN {

type master;

file "192.168.10.arpa";

allow-update { 192.168.10.20; };

};

[root@linuxprobe ~]# systemctl restart named

第2步:在从服务器中填写主服务器地址与要抓取的区域信息,然后重启服务即可。注意此时的服务类型应该是slave(从),而不再是master(主),masters参数后面应该为主服务器的IP地址,以及file参数后面定义的是同步文件后要保存到的位置,稍后可以在该目录内看到同步的文件:

[root@linuxprobe ~]# vim /etc/named.rfc1912.zones

zone "linuxprobe.com" IN {

type slave;

masters { 192.168.10.10; };

file "slaves/linuxprobe.com.zone";

};

zone "10.168.192.in-addr.arpa" IN {

type slave;

masters { 192.168.10.10; };

file "slaves/192.168.10.arpa";

};

[root@linuxprobe ~]# systemctl restart named

第3步:检验解析结果,当重启从服务器的DNS服务程序后,一般就已经自动从主服务器上面同步了域名数据文件,默认会放置在区域配置文件中所定义的目录位置中。随后修改下从服务器的网卡参数,把DNS地址参数修改成192.168.10.20,这样即使用从服务器自身提供的DNS域名解析服务,最后就能用nslookup命令顺利的看到解析结果了:

[root@linuxprobe ~]# cd /var/named/slaves

[root@linuxprobe slaves]# ls 

192.168.10.arpa linuxprobe.com.zone

[root@linuxprobe slaves]# nslookup

> www.linuxprobe.com

Server: 192.168.10.20

Address: 192.168.10.20#53

Name: www.linuxprobe.com

Address: 192.168.10.10

> 192.168.10.10

Server: 192.168.10.20

Address: 192.168.10.20#53

10.10.168.192.in-addr.arpa name = www.linuxprobe.com.

10.10.168.192.in-addr.arpa name = ns.linuxprobe.com.

10.10.168.192.in-addr.arpa name = mail.linuxprobe.com.

 

13.4.安全的加密传输

DNS域名解析服务是互联网的基础建设设施,几乎所有的网络应用都依赖于DNS解析服务做出的查询结果,如果互联网中的DNS解析服务不能正常运转,那么即使Web网站或Email邮局服务都运行正常,用户也无法找到并使用它们了。

13台全球根DNS服务器以及互联网中的DNS服务器绝大多数(超过95%)是基于BIND服务程序搭建的,BIND服务程序为了能够安全的提供解析服务,目前已经支持了TSIG(TSIGRFC 2845)加密机制,TSIG主要是利用密码编码方式保护区域信息的传送(Zone Transfer),也就是说TSIG加密机制保证了DNS服务器之间传送域名区域信息的安全性,咱们接下来的实验依然使用前面那两台服务器:

主机名称-操作系统-IP地址

主服务器-红帽RHEL7操作系统-192.168.10.10

从服务器-红帽RHEL7操作系统-192.168.10.20

书接上回,刚刚在从服务器上面配置妥当bind服务程序后,重启服务后即可看到从主服务器中获取到的域名数据文件,为了验证TSIG加密的效果,此时把这两个文件全部删除掉:

[root@linuxprobe ~]# ls -al /var/named/slaves/

total 12

drwxrwx---. 2 named named 54 Jun 7 16:02 .

drwxr-x---. 6 root named 4096 Jun 7 15:58 ..

-rw-r--r--. 1 named named 432 Jun 7 16:02 192.168.10.arpa

-rw-r--r--. 1 named named 439 Jun 7 16:02 linuxprobe.com.zone

[root@linuxprobe ~]# rm -rf /var/named/slaves/*

第1步:在主服务器中生成密钥,dnssec-keygen命令用于生成安全的DNS服务密钥,常用参数如下表,命令参数格式为:"dnssec-keygen [参数] ",生成一个主机名称为master-slave的128位HMAC-MD5算法的密钥文件,执行命令后默认会在当前目录中生成公钥和私钥文件,咱们需要把私钥文件中的Key参数后面的值记录下来,待会要写入到配置文件中。

参数 - 作用

-a - 指定加密算法(包括:RSAMD5 (RSA)、RSASHA1、DSA、NSEC3RSASHA1、NSEC3DSA等)

-b - 密钥长度(HMAC-MD5长度在1-512位之间)

-n - 密钥的类型(HOST为与主机相关的)

[root@linuxprobe ~]# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST master-slave

Kmaster-slave.+157+46845

[root@linuxprobe ~]# ls -al Kmaster-slave.+157+46845.*

-rw-------. 1 root root 56 Jun 7 16:06 Kmaster-slave.+157+46845.key

-rw-------. 1 root root 165 Jun 7 16:06 Kmaster-slave.+157+46845.private

[root@linuxprobe ~]# cat Kmaster-slave.+157+46845.private

Private-key-format: v1.3

Algorithm: 157 (HMAC_MD5)

Key: 1XEEL3tG5DNLOw+1WHfE3Q==

Bits: AAA=

Created: 20170607080621

Publish: 20170607080621

Activate: 20170607080621

第2步:在主服务器中创建密钥验证文件,首先应进入到bind服务程序目录中,然后把刚刚生成出的密钥名称、加密算法和私钥加密字符串按照下面格式写入到文件中,最后为了安全起见,咱们把文件的所有组修改成named,权限设置的要小一点并把该文件在/etc目录中做一个硬链接文件:

[root@linuxprobe ~]# cd /var/named/chroot/etc/

[root@linuxprobe etc]# vim transfer.key

key "master-slave" {

algorithm hmac-md5;

secret "1XEEL3tG5DNLOw+1WHfE3Q==";

};

[root@linuxprobe etc]# chown root:named transfer.key

[root@linuxprobe etc]# chmod 640 transfer.key

[root@linuxprobe etc]# ln transfer.key /etc/transfer.key

第3步:开启并加载bind服务的密钥验证功能,首先需要在主服务器的主配置文件中加载密钥验证文件,然后设置只对有master-slave密钥认证的DNS服务器允许同步域名区域数据文件:

[root@linuxprobe ~]# vim /etc/named.conf

//

// named.conf

//

// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

// server as a caching only nameserver (as a localhost DNS resolver only).

//

// See /usr/share/doc/bind*/sample/ for example named configuration files.

//

include "/etc/transfer.key";

options {

listen-on port 53 { any; };

listen-on-v6 port 53 { ::1; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt";

allow-query { any; };

allow-transfer { key master-slave; };

………………省略部分输出信息………………

[root@linuxprobe ~]# systemctl restart named

至此DNS主服务器的TSIG密钥加密传输功能就已经完成了,这样清空下DNS从服务器的区域数据同步目录,然后再次重启一下bind服务程序,但此时就已经不能像刚刚那样自动获取到域名区域数据文件,不禁让刘遄老师想起来了在00后小学生贴吧里看到过的搞笑段子——“我喜欢上了班花,但她是QQ会员,总感觉自己配不上她”。

[root@linuxprobe ~]# rm -rf /var/named/slaves/*

[root@linuxprobe ~]# systemctl restart named

[root@linuxprobe ~]# ls  /var/named/slaves/

第4步:配置从服务器支持密钥验证,配置DNS从服务器和主服务器的方法其实大致相同,需要在bind服务程序的目录中创建密钥认证文件,设置相应权限后做链接文件到/etc/目录:

[root@linuxprobe ~]# cd /var/named/chroot/etc

[root@linuxprobe etc]# vim transfer.key

key "master-slave" {

algorithm hmac-md5;

secret "1XEEL3tG5DNLOw+1WHfE3Q==";

};

[root@linuxprobe etc]# chown root:named transfer.key

[root@linuxprobe etc]# chmod 640 transfer.key

[root@linuxprobe etc]# ln transfer.key /etc/transfer.key

第5步:开启并加载从服务器的密钥验证功能,操作步骤也同样是在主配置文件中加载密钥认证文件,然后按照指定格式写上主服务器的IP地址和密钥名称,但注意参数位置不要太靠前,大约在43行左右比较合适,否则bind服务程序会因为没有加载完预设参数而报错:

[root@linuxprobe etc]# vim /etc/named.conf

1 //

2 // named.conf

3 //

4 // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

5 // server as a caching only nameserver (as a localhost DNS resolver only).

6 //

7 // See /usr/share/doc/bind*/sample/ for example named configuration files.

8 //

9 include "/etc/transfer.key";

10 options {

11 listen-on port 53 { 127.0.0.1; };

12 listen-on-v6 port 53 { ::1; };

13 directory "/var/named";

14 dump-file "/var/named/data/cache_dump.db";

15 statistics-file "/var/named/data/named_stats.txt";

16 memstatistics-file "/var/named/data/named_mem_stats.txt";

17 allow-query { localhost; };

18 

19 /* 

20 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.

21 - If you are building a RECURSIVE (caching) DNS server, you need to enable 

22 recursion. 

23 - If your recursive DNS server has a public IP address, you MUST enable access 

24 control to limit queries to your legitimate users. Failing to do so will

25 cause your server to become part of large scale DNS amplification 

26 attacks. Implementing BCP38 within your network would greatly

27 reduce such attack surface 

28 */

29 recursion yes;

30 

31 dnssec-enable yes;

32 dnssec-validation yes;

33 dnssec-lookaside auto;

34 

35 /* Path to ISC DLV key */

36 bindkeys-file "/etc/named.iscdlv.key";

37 

38 managed-keys-directory "/var/named/dynamic";

39 

40 pid-file "/run/named/named.pid";

41 session-keyfile "/run/named/session.key";

42 };

43 server 192.168.10.10

44 {

45 keys { master-slave; };

46 }; 

47 logging {

48 channel default_debug {

49 file "data/named.run";

50 severity dynamic;

51 };

52 };

53 

54 zone "." IN {

55 type hint;

56 file "named.ca";

57 };

58 

59 include "/etc/named.rfc1912.zones";

60 include "/etc/named.root.key";

61

第6步:DNS从服务器同步域名区域数据,双方两台服务器的bind服务程序都已经配置妥当,并设置匹配到了相同的密钥文件,接下来在从服务器上面重启下bind服务程序,就又能顺利的同步到区域文件啦:

[root@linuxprobe ~]# systemctl restart named

[root@linuxprobe ~]# ls /var/named/slaves/

192.168.10.arpa  linuxprobe.com.zone

 

13.5.部署缓存服务器

DNS缓存服务器(Caching DNS Server)是一种不负责域名数据维护、也不负责域名解析的DNS服务类型,简单来说缓存服务器就是把用户经常使用到的域名与IP地址解析记录保存在主机本地中,提升下次解析的效率。DNS缓存服务器一般用于对高品质上网有需求的企业内网之中,但实际的应用并不广泛,而且缓存服务器解析成功与否还与指定的上级DNS服务器允许策略相关,因此同学们当前仅需了解下即可。

第1步:配置系统的双网卡参数,如前面介绍的缓存服务器一般用于企业内网中,起到减少内网用户查询DNS的消耗,那么为了更加的贴近实际网络环境、实现外网查询功能,需要为缓存服务器中再添加一块网卡,可参考下表所示配置出两台Linux虚拟机系统,而对于新添加进入的网卡请在虚拟机软件中设置成“桥接模式”,然后设置成与真机上网相同的配置即可(此处请读者们按照实际上网环境来配置,如图13-6所示为DHCP自动获取模式,重启网卡服务后效果如图13-7所示):

主机名称-操作系统-IP地址

缓存服务器-红帽RHEL7操作系统-网卡(外网):根据实际情况DHCP或手工指定IP地址与网关等信息。网卡(内网):192.168.10.10

客户端-红帽RHEL7操作系统-192.168.10.20

第13章 使用Bind提供域名解析服务

图13-6 配置网卡参数为DHCP模式

第13章 使用Bind提供域名解析服务

图13-7 查看网卡状态

第2步:在bind服务程序的主配置文件中添加缓存转发参数,在默认参数下方添加一行参数"forwarders { 上游DNS服务器地址; };",上游DNS服务器地址指的是从何处取得区域数据文件,主要考虑查询速度、稳定性、安全性等因素,刘遄老师使用的是北京市公共DNS服务器:210.73.64.1,请读者选择前先Ping下能否通信,否则可能会导致解析失败!!

[root@linuxprobe ~]# vim /etc/named.conf

//

// named.conf

//

// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS

// server as a caching only nameserver (as a localhost DNS resolver only).

//

// See /usr/share/doc/bind*/sample/ for example named configuration files.

//

options {

listen-on port 53 { any; };

listen-on-v6 port 53 { ::1; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt";

allow-query { any; };

forwarders { 210.73.64.1; };

………………省略部分输出信息………………

[root@linuxprobe ~]# systemctl restart named

第3步:重启DNS服务后验证成果,把客户端主机网卡的DNS地址参数指向为DNS缓存服务器(192.168.10.10),如图13-8所示。这样即可让客户端使用由本地DNS服务器提供的域名查询解析服务,验证DNS缓存服务器是否可以正常解析域名:

第13章 使用Bind提供域名解析服务

图13-8 设置客户端主机网卡DNS服务器地址参数

客户端主机网卡参数设置妥当后重启网络服务,即可使用nslookup命令来验证实验成果(如果解析不成功,请读者多留意下是不是上游DNS选择的问题),其中Server参数为域名解析记录提供的主机地址,因此可见是由本地DNS缓存服务器提供的解析内容:

[root@linuxprobe ~]# nslookup

> www.linuxprobe.com

Server: 192.168.10.10

Address: 192.168.10.10#53

Non-authoritative answer:

Name: www.linuxprobe.com

Address: 113.207.76.73

Name: www.linuxprobe.com

Address: 116.211.121.154

> 8.8.8.8

Server: 192.168.10.10

Address: 192.168.10.10#53

Non-authoritative answer:

8.8.8.8.in-addr.arpa name = google-public-dns-a.google.com.

Authoritative answers can be found from:

in-addr.arpa nameserver = f.in-addr-servers.arpa.

in-addr.arpa nameserver = b.in-addr-servers.arpa.

in-addr.arpa nameserver = a.in-addr-servers.arpa.

in-addr.arpa nameserver = e.in-addr-servers.arpa.

in-addr.arpa nameserver = d.in-addr-servers.arpa.

in-addr.arpa nameserver = c.in-addr-servers.arpa.

a.in-addr-servers.arpa internet address = 199.212.0.73

a.in-addr-servers.arpa has AAAA address 2001:500:13::73

b.in-addr-servers.arpa internet address = 199.253.183.183

b.in-addr-servers.arpa has AAAA address 2001:500:87::87

c.in-addr-servers.arpa internet address = 196.216.169.10

c.in-addr-servers.arpa has AAAA address 2001:43f8:110::10

d.in-addr-servers.arpa internet address = 200.10.60.53

d.in-addr-servers.arpa has AAAA address 2001:13c7:7010::53

e.in-addr-servers.arpa internet address = 203.119.86.101

e.in-addr-servers.arpa has AAAA address 2001:dd8:6::101

f.in-addr-servers.arpa internet address = 193.0.9.1

f.in-addr-servers.arpa has AAAA address 2001:67c:e0::1

 

13.6.分离解析技术

现在喜欢看《Linux就该这么学》书籍的海外留学生也越来越多,如果继续把网站服务器架设在北京市机房内,那么国外读者访问起来速度必然会很慢,若把网站服务器架设在美国机房的话,那又会让国内读者访问变得很麻烦。既然读者有需求,刘遄老师也不差钱,于是便可以购买多台服务器部署在全球各地,然后采用DNS服务的分离解析功能,即可让不同来源的读者即便访问的是相同的网址,最终获取网站数据的服务器也是不同的。简单来说,就像如图13-9所示,让国内用户自动匹配到北京服务器,而海外留学生自动匹配到美国服务器。

主机名称-操作系统-IP地址

DNS服务器-红帽RHEL7操作系统-北京网络:122.71.115.10。美国网络:106.185.25.10

北京用户-Windows7-122.71.115.1

海外用户-Windows7-106.185.25.1

第13章 使用Bind提供域名解析服务

图13-9 DNS分离解析技术

那么为了解决《Linux就该这么学》访问速度的问题,站务管理员已经在美国机房购买并架设好了书籍网站服务器,咱们需要动手部署DNS服务器并实现分离解析功能,让北京用户与美国用户访问相同域名时也能解析出不同的IP地址。建议同学们还原虚拟机到最初始状态后重启安装bind服务程序,避免多个实验之间产生冲突。

第1步:修改bind服务程序的主配置文件,把监听端口与允许查询主机修改为any,由于自己配置的DNS分离解析功能与DNS根域服务器配置参数有冲突,所以需要把51-54行左右的根域信息删除掉:

[root@linuxprobe ~]# vim /etc/named.conf

………………省略部分输出信息………………

44 logging {

45 channel default_debug {

46 file "data/named.run";

47 severity dynamic;

48 };

49 };

50 

51 zone "." IN {

52 type hint;

53 file "named.ca";

54 };

55 

56 include "/etc/named.rfc1912.zones";

57 include "/etc/named.root.key";

58

………………省略部分输出信息………………

第2步:编辑域名区域配置文件,把区域配置文件中原有默认的数据清空,然后按照以下格式写入参数。首先用acl参数分别定义了两个变量名称(china与american),这样当下面再需要匹配IP地址的时候,就只需输入变量名称即可,这样不仅更容易阅读识别,而且也利于今后修改维护。主要难点是理解view参数框内的作用,通过匹配用户到底来源于中国还是美国的IP地址,然后去分别加载不同的区域数据文件(linuxprobe.com.china与linuxprobe.com.american),这样当把对应的IP地址分别写入到区域数据文件后,即可实现DNS的分离解析功能,也就是说比如中国的用户访问linuxprobe.com域的时候,会去按照linuxprobe.com.china区域数据文件内的IP地址找到对应的服务器。

[root@linuxprobe ~]# vim /etc/named.rfc1912.zones

acl "china" { 122.71.115.0/24; };

acl "american" { 106.185.25.0/24;};

view "china"{

match-clients { "china"; };

zone "linuxprobe.com" {

type master;

file "linuxprobe.com.china";

};

};

view "american" {

match-clients { "american"; };

zone "linuxprobe.com" {

type master;

file "linuxprobe.com.american";

};

};

第3步:建立区域数据文件,分别通过模板文件创建出两份不同名称的区域数据文件,名称应与上面区域配置文件中的参数对应:

[root@linuxprobe ~]# cd /var/named

[root@linuxprobe named]# cp -a named.localhost linuxprobe.com.china

[root@linuxprobe named]# cp -a named.localhost linuxprobe.com.american

[root@linuxprobe named]# vim linuxprobe.com.china

第13章 使用Bind提供域名解析服务

[root@linuxprobe named]# vim linuxprobe.com.american

第13章 使用Bind提供域名解析服务

第4步:重新启动named服务程序后验证结果,设置客户端主机(Windows系统或Linux系统均可)的IP网卡地址分别为122.71.115.1与106.185.25.1,DNS地址分别为服务器主机的两个IP地址,这样当咱们尝试用nslookup命令解析域名的时候就会很清晰的看到解析结果,分别如图13-10与图13-11所示,让不同来源的用户访问到不同的服务器:

第13章 使用Bind提供域名解析服务

图13-10 模拟中国用户的域名解析操作

第13章 使用Bind提供域名解析服务

图13-11 模拟美国用户的域名解析

 

本章节的复习作业

1:简述DNS服务有那三种服务形式?

答案:DNS主服务器、DNS从服务器与DNS缓存服务器。

2:DNS服务器之间传输区域数据文件时,使用的是递归查询还是迭代查询?

答案:DNS服务器之间是迭代查询,用户与DNS服务器之间是递归查询,此为理论知识,了解即可,无需硬背。

3:在Linux系统中使用bind服务程序部署DNS服务时,为什么会推荐安装chroot插件?

答案:能够有效的限制bind服务程序仅能对自身配置文件进行操作,从而保证了整个服务器的安全。

4:简述DNS服务的正向解析和反向解析。

答案:正向解析是日常广泛使用的DNS服务模式,把指定的域名转换成IP地址,而反向解析是把IP地址反查出对应绑定的域名。

5:DNS主服务器可以设置允许查询的主机名或限制仅某一部分主机可以查询?

答案:是的,修改主配置文件中的allow-query参数即可。

6:简述DNS从服务器的作用。

答案:部署从服务器主要就是为了减轻主服务器的负载压力,以及当网民访问就近的本地DNS服务器时还能提升查询效率。

7:使用TSIG加密机制可以实现DNS服务器与用户间传输区域数据文件内容不被篡改吗?

答案:不能,TSIG加密保证的是DNS服务器与DNS服务器之间迭代查询的安全。

8:简述DNS缓存服务器的作用。

答案:把用户经常使用到的域名与IP地址解析记录保存在主机本地中,提升下次解析的效率,一般用于对高品质上网有需求的企业内网之中,但实际的应用并不广泛。

9:简述DNS分离解析技术的作用。

答案:可让不同来源的读者即便访问的是相同的网址,最终获取网站数据的服务器也是不同的,加快访问效率。

精选文章
热门文章