Linux基础篇之DNS服务的部署

关于dns的名词解释

域名系统（Domain Name System缩写DNS，Domain Name被译为域名）是因特网的一项核心服务，它作为可以将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。
域名系统(Domain Name System,DNS)是Internet上解决网上机器命名的一种系统。就像拜访朋友要先知道别人家怎么走一样，Internet上当一台主机要访问另外一台主机时，必须首先获知其地址，TCP/IP中的IP地址是由四段以“.”分开的数字组成，记起来总是不如名字那么方便，所以，就采用了域名系统来管理名字和IP的对应关系。

关于客户端：

dns指向文件：/etc/resolv.conf

当做地址解析动作时，系统会访问dns指向文件中的ip完成地址解析这个工作。dns指向文件中的ip就为此主机的dns服务器。

关于服务端

安装包	bind
服务名称	named
主配置文件	/etc/named.conf
数据目录	/var/named
端口	/var/named

host命令

host命令 是常用的分析域名查询工具，可以用来测试域名系统工作是否正常。
host www.baidu.com： 对www.baidu.com地址解析

dig命令

dig命令 是常用的域名查询工具，可以用来测试域名系统工作是否正常。
使用dig www.baidu.com对www.baidu.com进行详细地址解析：

A记录

通俗来说A (Address) 记录就是服务器的IP，域名绑定A记录就是告诉DNS，当输入域名的时候给你引导向设置在DNS的A记录所对应的服务器。

SOA

SOA 授权起始主机

基本解析方式

根DNS服务器：.（全球共13台）
顶级域名DNS：.com .net .edu .org …
被授权的权威dns ：例如baidu.com

当地址解析时如果在被授权的权威dns没有找到记录就会顶级域名DNS.com里查找，顶级域名DNS.com也没有查找到的话会到根DNS服务器.里查找，如果还是没有查找到，就说明此域名是不被公认的。

关于报错信息：

1.no servers could be reached 服务无法访问（服务开启？火墙？网络？端口？）
2.服务启动失败 ##配置文件写错 journalctl -xe查询错误
3.dig 查询状态：
NOERROR---------- 表示查询成功
REFUSED ---------- 服务拒绝访问
SERVFAIL ---------- 查询记录失败,（dns服务器无法到达上级，拒绝缓存） NXDOMAIN--------- 此域名A记录在dns中不存在

dns服务的安装与启用

安装

使用dnf search dnf 找到dnf相关安装包：

找到dns服务：bind.x86_64 进行安装：

 dnf install bind.x86_64 -y

完成安装。

启用

dns服务器主机ip：192.168.0.42

systemctl enable --now named

启动dns服务并使之开机启动。
将named添加进火墙策略：

firewall-cmd --permanent --add-service=dns
firewall-cmd --reload 

添加成功！
查询其53端口是否打开：

所以默认53端口是关闭状态，配置dns配置文件/etc/named.conf，将53端口打开：

默认只在本地回环接口开启53端口，将其改为所有在所有网络接口开启53端口:

修改允许查询A记录的客户端列表 为所有人any：
禁用dns检测使dns能够缓存外部信息到本机：

修改完成后，保存退出，重启named。

测试：在客户主机的dns指向文件/etc/resolv.conf中添加dns服务器ip：

对www.baidu.com进行地址解析：

解析成功。named成功启用。

高速缓存dns

当多台主机同时访问同一个地址时， 各自独立访问114.114.114.114完成地址解析，其解析时间在相同网络环境下相当:

为优化解析时间，将主机4的dns缓存共享，成为高速缓存dns，其他3台主机直接读取主机4的缓存，只要被访问的地址被四台主机之一访问，会使地址信息缓存到高速缓存dns，其他主机再次访问相同地址时直接在高速缓存dns里取用即可获得解析时间上的加速：

将两台客户主机dns指向为高速缓存dnsIP：

当本地dns192.168.0.22查询不到时使高速缓存dns使用国内知名dns服务器114.114.114.114进行解析
编辑配置文件/etc/name.conf:

编辑完成后保存退出，重启named。返回两台客户主机做dig测试：
使用高速缓存dns主机dig www.cctv.com：
第一台主机解析时间：453ms

第二台主机解析时间：43ms

第三台主机解析时间：1ms

可以看到，解析时间大幅度减少。

dns的正向解析

正向解析：根据域名查询IP地址，是DNS最基本也是最常用的功能。
编辑配置文件：/etc/named.cof

我们可以在根域的设定下添加我们自己维护的域的设定,但是若我们维护的域太多，都写在/etc/named.cof 文件中的话，就会造成主配置文件冗长，所以，系统将zone（域）的管理放在子文件/etc/named.rfc1912.zones中。
所以，首先编辑/etc/named.rfc1912.zones

文件里有模板，复制粘贴一份进行设定：

编辑完成后，保存退出。

接着配置域数据配置文件：
在/var/named里可以看到文件named.localhost

此文件为域数据配置文件的模板，也就是A记录模板，将其复制（注意也将权限进行复制）成为刚才所指定的域数据配置文件：

cp -p named.localhost xng.com.zone

编辑此文件：

编辑完成后爆粗不i出，重启namd。回客户端进行测试：
dig www.xng.com：

dig news.xng.com:

dig bbs.xng.com:

某些时候，同一域名对应多台主机，查询时，多个地址做简单轮回：

邮件发送原理：
比如qq邮箱给163发送邮件时，qq邮箱必须知道163.com域负责邮件的主机MX，在发送时，qq邮箱首先会询问163.com的XM（邮件记录）查询到163.com负责邮件的主机，再通过smtp（电子邮件传输的协议）25端口将邮件发出。

dns的反向解析

反向解析：根据IP地址查询域名
编辑zone（域）的管理子文件/etc/named.rfc1912.zones：
文件里有模板，复制粘贴一份进行设定：

注意ip反着写。

复制/var/named/named.loopback模板生成192.168.0.per：

cp -p named.loopback 192.168.0.ptr

配置方法同正向解析配置类似。
编辑完成后，保存退出。重启named，在客户主机进行dig 测试：
dig -x IP 为反向解析
dig -x 192.168.0.10:

成功解析到news.xng.com

dig -x 192.168.0.11:

成功解析到www.xng.com

dig -x 192.168.0.13：

成功解析到bbs.xng.com

dns的双向解析

实验环境的设定：
客户端2台： 192.168.0网段 和172.25.254网段
服务端1台2个网段的ip：192.168.0.20 和172.25.254.20
使用ifconfg ：0给网卡的子接口添加新的ip：
客户端：

ifconfig ens160:0 172.25.254.42 netmask 255.255.255.0

在客户端192.168.0网段主机编辑/etc/resolv.conf:
将192.168.0.42设为192.168.0网段客户机的公网地址。

将172.25.254.42设为172.25.254网段客户机的公网地址。

目前两台主机dig www.xng.com都显示192.168.0网段：


实验预期效果：
当使用172.25.254网段的客户主机解析www.xng.com时，得到的ip为172.25.254.80。
当使用192.168.0网段的客户主机解析www.xng.com时，得到的ip为192.168.0.80。

实验思路及实验过程：
我们解析所看到的信息为域数据配置文件/var/named/xng.com.zone所提供的信息，所以可以将xng.com.zone复制一份单独做172.25.254网段

[root@rhel8_node1 named]# cp -p xng.com.zone xng.com.zone.inter

编辑 xng.com.zone.inter，将192.168.0网段换为172.25.254网段：

而 xng.com.zone能被系统读取的原因为zone（域）的管理的子文件/etc/named.rfc1912.zones中所指定。所以，将named.rfc1912.zones复制一份指定xng.com.zone.inter：

cp -p /etc/named.rfc1912.zones /etc/named.rfc1912.zones.inter

编辑/etc/named.rfc1912.zones.inter：
将指定的文件换成xng.com.zone.inter

所以：

named.rfc1912.zones------读取------->xng.com.zone
named.rfc1912.zones.inter-------读取------>xng.com.zone.inter
dns服务器里就有两套解析环境。

下来对dns的配置文件/etc/name.conf进行设定，使其对地址的解析具有选择性：
首先 man 5 named.conf查看此配置文件的相关帮助：

vim /etc/name.conf

编辑完成后，保存退出。重启named，返回两台客户主机进行dig测试：

172.25.254网段客户主机dig www.xng.com：

解析的ip为172.25.254.80

192.168.0网段客户主机dig www.xng.com：

解析的ip为192.168.0.80。
dns的双向解析成功！

dns集群

实验环境：
主dns：192.168.0.42
辅助dns：192.168.0.43
客户主机：192.168.0.40

在使用DNS的时候，为了缓解服务器的压力，会使用多个辅助DNS服务器来分担主DNS的工作。这些DNS就叫做DNS集群。
首先将另外一台主机上（192.168.0.43）安装bind，启动服务并进行配置：
编辑配置文件：/etc/named.cof

编辑域的管理子文件/etc/named.rfc1912.zones：

配置完成后保存退出，重启named。可以看到在/var/named/slaves下已经生成同步数据的文件：xng.com.zone

将此主机的dns添加进火墙策略：

此时将客户主机的dns指向为辅助dns192.168.0.43：

辅助dns192.168.0.43 dns指向为主dns：192.168.0.42：

此时在客户主机做dig测试:
dig www.xng.com:

可以看到，成功解析到www.xng.com的地址。

但是！此时当我们主dns里的文件a记录发生变化时，辅助dns里的a记录并没有进行更新：

实验：修改主dns里的www.xng.com的A记录：

在主dns主机（192.168.0.42）编辑/var/named/xng.com.zone将www.xng.com的地址进行修改:

编辑完成后，保存退出。
systemctl restart named进行重启named。
在辅助dns主机dig www.xng.com：

可以看到，解析到的地址已经发生了变化，说明在主dns里的a记录已经发生变化。
在客户主机里dig www.xng.com:

可以看到解析到的地址没有发生变化，说明辅助dns的a记录没有发生变化。

为解决问题，在主dns主机编辑/etc/named.rfc1912.zones.inter

给我们维护的xng.com域加上参数also-notify {192.168.0.43；}‘当主dns数据发生变化时，将主动通知192.168.0.43（辅助dns）变化信息。
但是/var/named/xng.com.zone 里的A记录非常多的情况下一个一个对比更新速度是非常慢的，所以在dns同步时，对比/var/named/xng.com.zone里的serial（增量）值，只能增大，最大10位。
所以主dns的a记录文件发生变化时，修改serial值即可（否则不生效）。
修改serial值：

编辑完成后，保存退出，重启dns主机named。

返回客户主机进行dig测试：
继续digwww.xng.com:

可以看到，解析到的www.xng.com ip成功变为192.168.0.85。

dns的更新

dns基于ip地址的更新：

在dns服务器上打开更新:
编辑文件/etc/name.rfc1912.zones:

allow-update { 192.168.0.10; }; 允许192.168.0.40客户端更新xng域。
编辑完成后，保存退出。重启named。

测试：
在192.168.0.10客户主机执行更新命令：
添加A记录：

[root@localhost ~]# nsupdate 
> server 192.168.0.42
> update add cool.xng.com 86400 A 192.168.0.100
> send

更新完成后dig cool.xng.com:

成功解析到cool.xng.com 说明更新成功！

删除A记录：

[root@localhost ~]# nsupdate 
> server 192.168.0.42
> update delete cool.xng.com
> send

dig cool.xng.com:

此时已经不能解析到cool.xng.com 说明更新成功！
但是基于ip地址的更新存在最大的弊端就是客户端可以将自己的ip更改为dns允许更新的客户主机ip，进行dns的更新。

dns基于key的更新：

使用命令dnssec-keygen 生成key字符
查看dnssec-keygen 的帮助：

-a 指定加密类型
dns的key：在 /etc下有rndc.key 文件：

其加密方式为hmac-sha256，所以加密方式也应该选择hmac-sha256。

-b 加密长度

-n 名称类型
专用解析，所以名称类型为HOST

生成key字符：

dnssec-keygen -a HMAC-SHA256 -b 128 -n HOST xng

key字符生成：

接着将key字符添加到dns的配置中：

首先复制 /etc/rndc.key作为key加密文件模板：

cp -p /etc/rndc.key /etc/xng.key

编辑/etc/xng.key：

这样，key文件就生成：

将key文件指定到/etc/name.conf中
编辑/etc/name.conf：

编辑完成后，保存退出。

编辑/etc/named.rfc1912.zones:

编辑完成后，保存退出。重启named。

测试：
当没有key时：

更新被拒绝。

持有key时：

nsupdate -k key文件

dig cool.xng.com:

成功解析到cool.xng.com,更新成功！

ddns（dhcp+dns）

DDNS（Dynamic Domain Name Server，动态域名服务）是将用户的动态IP地址映射到一个固定的域名解析服务上，用户每次连接网络的时候客户端程序就会通过信息传递把该主机的动态IP地址传送给位于服务商主机上的服务器程序，服务器程序负责提供DNS服务并实现动态域名解析。

当某台主机使用的是动态ip，那么当ip发生变化时，dns服务器就接收不到a记录变化的信息，导致访问失败，所以

首先在dns服务器上安装dhcp-server，使其也成为一台dhcp服务器：

[root@rhel8node1 Desktop]# dnf install dhcp-server

对其进行配置：
编辑配置文件：/etc/dhcp/dhcpd.conf:详细配置见<网络的部署>博客


编辑完成会，重启dhcpd[root@rhel8node1 dhcp]# systemctl restart dhcpd

将客户主机的网络设置为dhcp动态ip：

nmcli connection down westos 
 nmcli connection up westos 
systemctl restart NetworkManager

重启网络和网卡，使设置生效：
查看其ip：ifconfig：

可以看到ip为192.168.0.20 是在dhcp设置的192.168.0.20~192.168.0.30之间
dns为192.168.0.42：

ip分配成功！

下来需要解决的事情就是使dhcp去更新dns，以解决dns服务器 动态ip的a记录

使用man 5 dhcpd.conf查看dhcp更新dns的设置：

ddns开关： ddns-update-style
ddns-update-style 的值分别有：standard, interim ， none.
none为不更新，interim表示dhcpd更新dns

且需要在dhcpd.conf添加key。

添加需要dhcp更新的域。

所以编辑/etc/dhcpd.conf

，将 ddns-update-style 参数打开，并设置值为 interim：

将key添加到/etc/dhcpd.conf：
key文件：
（在做基于key更新时生成）
添加：

此时dhcp就有了key可以对dns进行更新。

添加更新的域：

至此，设定完成。保存退出，重启dhcpd。重启named。

注意，dhcp分配ip的主机必须为xng.com的主机，修改其hostname：

hostnamectl set-hostname test.xng.com

关闭其火墙。
重启网卡后进行dig test.xng.com测试：

成功解析到test.xng.com的地址。

修改dhcp 的IP地址池：

修改完成后保存退出，systemctl restart dhcpd重启dhcpd
在dhcp分配IP的主机，

 nmcli connection down westos 
 nmcli connection up westos 

重启网卡使dhcpip重新分配。
ifconfig查看新分配的ip：
新分配的ip为：192.168.0.25
再次dig test.xng.com:

解析出的地址成功由192.168.0.20变为192.168.0.25
ddhcp设置成功！