第六章 DNS服务(2)

第六章 DNS服务(2)

6.5 DNS轮询

DNS服务器的区域文件中也支持同一域名对应多个ip,则在解析时,客户端可获得不同排序的多个ip,从而在DNS上实现对服务器其的负载均衡功能,被称为轮询功能。其实若不做特殊指定,DNS默认是把多个ip轮流排序显示给客户的。配置如下:

vi /var/named/rzz_zheng ---写入如下图的www设置。

systemctl restart named

重启后,在客户端多次进程www.rzz.com的解析,可见到每次获得结果排序都不同,而且是依次循环的。

DNS服务器中共有三种轮询方式:cyclic、fixed、random。cyclic是指多ip轮流显示,不做设置默认就是cyclic模式;fixed指不做循环,按区域配置文件中的顺序固定显示;random是指随机轮询显示。

在named.conf配置文件的options{}中写入rrset-order { cyclic; }; 即可设置了,重启服务就可生效。

6.6 配置文件简介

以上,我们搭建了一个基本的dns服务器,了解了各配置文件的功能与格式,其实dns服务安装完毕后,配置文件中原有内容中,还有很多值得介绍的,下面来看:

vi /etc/named.conf ---编辑主配置文件

该文件中可见到有一个根域(.)的区域,如下图:

其中,type hint; 表示本域为根域,file “named.cd”表示根域的区域文件为/var/named/ named.cd。vi /var/named/ named.cd 查看该文件,可见到全球13台根dns服务器的地址,里面A记录表示根服务器的IPv4地址,AAAA记录表示IPv6地址。

另外,named.conf文件的最后,还有两行特殊设置,如下图:

这两行的意思是,导入两个文件,一个是named.rfc1912.zones文件,在这个文件中也可以创建区域,格式与named.conf相同。第二个文件是named.root.key,是导入了root的管理密钥。

6.7 转发配置

6.7.1 全局转发

在企业的局域网内,如果每台主机上网都要访问公网的dns做解析,并且很能访问的目标都集中在某几个最长用的网站上,这样既会浪费网络流量,又影响解析速度。所以在企业内网如果搭建一台缓存器,存放各解析记录,那么,当内部有客户再次请求解析某域名时,即可在内网内完成解析,则无需访问公网了。这样既可以节约公网流量(在以流量计费的企业内最为实用),又可以提升内网的解析速度。

部署缓存服务器的方式即是部署DNS转发服务器,思路是在企业内部部署一台DNS服务器,不设置任何区域,仅配置转发功能,并指向外网某一台DNS服务器。则客户端的DNS可指向该转发服务器,当客户要做解析时,会向转发器发出询问,若转发器缓存中无相关记录,则会向外网的DNS询问,得到结果后,会先放入缓存中,在反馈给客户端,这样有其他客户端询问相同域名时,转发器则可以直接从缓存中提取信息,返回给客户了。所以,简单的说,转发器就是转发+缓存的功能。

下面来看一个转发器的配置实验:

首先主DNS保持不变,再新开一台Linux虚拟机,配置ip为192.168.10.2,关闭防火墙。

安装bind bind-chroot软件包

vi /etc/named.conf

options{}中,改

listen-on port 53 { 192.168.10.2; };

allow-query { any; };

dnssec-enable no; ---关闭dns安全设置

dnssec-validation no;

写入:

forwarders { 192.168.10.1; }; ---指定解析时,询问的DNS服务器

forward first; ---设定缓存的使用顺序

注:first表示,响应客户解析时,先查缓存,若缓存无,则询问指定的DNS,若指定的DNS也解析失败,再去询问网卡上设置的DNS。forward only;表示仅使用指定的DNS,解析失败,也不再询问网卡上的DNS。

forwarder{ ip1; ip2; }; ---也可以设置多个DNS服务器,有主有备

systemctl restart named ---启动服务

systemctl enable named

客户端网卡dns指向10.2,即可验证解析了。解析效果如下:

图中,执行命令后,会有一个报错,读英文可知是报无法查找到服务器10.2的名字(读者可以先思考一下是为什么),原因是10.2上我们没有创建任何区域,没有反向区域,则客户端访问10.2时,想要先获取服务器的名字,但是由于没有反向信息,所以报错。可以在转发器上手动创建反向区域并创建区域文件,写入反向记录即可解决,或者不做改动,因为这并不影响实验的成功。

图中,当我们解析时,解析结果中有一行Non-authoritative answer的提示,中文意义是 非权威应答。即表示解析结果是从缓存中获取的,并未经过真正DNS服务器的验证,不保证准确。

那么,我们会问,缓存中的既然不保证准确,客户端不就会产生上网失败吗?确实,这是不可避免的。但是,一般的应用服务器(如:web、FTP等)搭建好后,是很少更换ip,所以缓存中的信息基本是可以确保准确的。而且,转发器缓存中存放的信息也是有缓存时间的,还记得区域文件中的第一行设置吗($TTL 1D)?就是指该区域文件中的信息被放入缓存后的有效期。所以,记录超期后会自动清理出缓存,则再有客户询问时,便会重新询问公网的DNS了。

转发器上也可以人为的手动清除缓存,用的命令是:rndc flush 。

6.7.2 区域转发

在转发器的named.conf上,forward的两行并不是必须写在options{}中,也可以写在zone中,即仅指定某个区域的解析做转发,如下:

zone "rzz.com" IN {

type forward;

forwarders{ 192.168.10.1; };

forward first;

};

重启服务后可在客户端验证

PS:rndc reload 命令可以实现重新加载配置文件的功能,则无需重启服务了。

6.8 辅助区域

可以想象,当主DNS服务器宕机时,解析工作就会受到影响,甚至宕机的DNS上的区域将无法解析,所以我们就需要为DNS服务器搭建一台辅助机,当主DNS宕机后,辅助即仍可完成解析工作,这也是网卡上允许指定多个DNS的目的。

既然建立辅助DNS的目的是当主DNS不可用时,辅助DNS可完成区域解析。但是若主DNS宕机了,主DNS上的区域记录都无法获取了,所以必须在主DNS正常时,将区域信息复制到辅助DNS上,这称为“区域复制”,但是主DNS上并不是允许给随便一台DNS都发送区域文件的,所以需要做好对辅助DNS的授权。

再者,辅助DNS上的区域信息需要与主DNS上的保持一致,所以辅助DNS就要定期与主DNS通信,同步数据,被称为“数据同步”或“数据更新”。更新时,主辅DNS比较区域文件中的serial序列号,若主DNS的serial高,则进行区域复制,更新到辅助DNS上,但是反之,若辅助DNS区域文件中的serial高,也不会方向更新回主DNS的(毕竟身份有限嘛)。另外,在区域文件中设置的refresh就是主辅的更新周期(可根据需求自定义),但当更新失败时,retry设定了重试的时间,若主辅的某一方彻底崩溃,则expire设定了持续重试的放弃时间,即持续重试多久后放弃重试。最后的minimum功能同TTL。

下面我们就来搭建一台辅助DNS服务器,为了节约虚拟机数量,我们仍使用192.168.10.2这台服务器作为辅助DNS。具体配置如下:

1、配置主DNS

vi /etc/named.conf

options{} 中,改:

dnssec-enable no; ---关闭dns安全设置

dnssec-validation no;

写入:

allow-transfer{ 192.168.10.2; }; ---指定允许给谁做区域复制的传输

systemctl restart named

2、辅助DNS

vi /etc/named.conf

删除原转发器相关设置

改:listen-on allow-query dnssec两行,若已改,则不用动

下侧写入

zone"rzz.com" IN {

type slave; ---设定为辅助区域

file "slaves/fu_rzz_zheng"; ---指定辅助区域文件名,

注:必须在slaves下

masters{ 192.168.10.1; }; ---指定主DNS

};

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

type slave;

file "slaves/fu_163_fan";

masters{ 192.168.10.1; };

};

systemctl restart named ---重启

重启后在/var/named/slaves/ 下可见复制过来的区域文件

注:1)辅助DNS每次重启服务,都会自动更新一次。

2)主DNS发生数据变化后,必须手动提升serial序列号(即serial数字+1即可)后,主辅更新时才会更新到辅DNS上。

3、客户端验证

小结:从上面实验中可见到,其实辅助DNS实质是把区域做成了辅助类型,DNS服务器本身是并不分主辅的,一台DNS上可以有主区域,也可以有辅助区域,只要不是相同的区域名即可。

另外,DNS服务器的通信端口使用的是TCP 53 及 UDP 53。TCP 53 用于主辅通信,及区域复制、数据更新。UDP 53 为客户提供解析服务

6.9 子域解析

若客户端找到父域DNS请求解析子域的FQND,父域是要负责解析的,所以需要在父域的区域文件中做好相关配置。子域解析的配置方式有两种:FQDN直接解析、委派解析。

6.9.1 直接FQDN解析子域

直接解析子域FQDN配置非常简单,只要编辑区域文件,写入子域的FQND的A记录即可,案例如下:

vi /var/named/rzz_zheng ---写入

www.bbs.rzz.com. IN A 192.168.10.200

systemctl restrat named

客户端DNS指向主DNS即可验证

6.9.2 委派解析

在本章开篇,介绍DNS在全球范围解析过程时,已经有所介绍,迭代模式的DNS服务器会先问根域服务器,根域服务器会返回顶级域服务器地址,迭代DNS再询问顶级域服务器,顶级域服务器返回其下子域的服务器地址,迭代DNS再询问子域服务器,最终获得答案,其实这就是委派的过程,即由上一级服务器将解析任务分派给下级服务器完成。下面我们就来模拟一下给子域服务器做委派的过程。

vi /var/named/rzz_zheng ---写入

bbs IN NS ns1.bbs.rzz.com.

ns1.bbs.rzz.com. IN A 192.168.10.2

systemctl restart named

注:这里我们仍使用192.168.10.2作为被委派区域的DNS服务器。

之后再在10.2上新建bbs.rzz.com的主区域并做好区域文件即可,如下图:

客户端dns指向主DNS,然后可以验证解析了。

注:若区域文件中子域的FQDN直接解析与委派并存,则以委派的为准,即委派设置优先级高。

6.10 综合实验

之上,我们把DNS服务的各个细节均做了介绍,但是为了方便,只使用了两台Linux虚拟机做实验,下面大家可以自己试着按照如下拓扑图,自行配置一下综合实验。

原文发布于微信公众号 - 教主小筑(gh_e0879483602d)

原文发表时间:2019-05-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券