首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >第六章 DNS服务(2)

第六章 DNS服务(2)

作者头像
晓天
发布2019-07-04 14:28:09
3K0
发布2019-07-04 14:28:09
举报

第六章 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虚拟机做实验,下面大家可以自己试着按照如下拓扑图,自行配置一下综合实验。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-05-20,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 教主小筑 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档