114.114.114.114和8.8.8.8，这两个IP地址都属于公共域名解析服务DNS其中的一部分，而且由于不是用于商业用途的，这两个DNS都很纯净，不用担心因ISP运营商导致的DNS劫持等问题，而且都是免费提供给用户使用的。

114.114.114.114是国内移动、电信和联通通用的DNS，手机和电脑端都可以使用，干净无广告，解析成功率相对来说更高，国内用户使用的比较多，而且速度相对快、稳定，是国内用户上网常用的DNS。

8.8.8.8是GOOGLE公司提供的DNS，该地址是全球通用的，相对来说，更适合国外以及访问国外网站的用户使用。

DNS原理
域名到IP地址的解析过程
IP地址到域名的反向域名解析过程
抓包分析DNS报文和具体解析过程
DNS服务器搭建和配置
这个东东也是今年博主参见校招的时候被很多公司问过的，虽然理论性比较强，但是作为一个程序员，个人认为熟悉DNS是非常重要的，要理解它并能帮助解决一些实际问题。

面试实录
打开一个URL，在网络层面都发生了哪些事情？（当中说到了DNS原理，这个是绕不过的）
用过 Linux 么？你用它平时都做什么事情啊？（首先是在该环境下写代码，搭建过一些集群，当然还有一些服务器的搭建，比如本文内容）
DNS 是基于 TCP 还是 UDP 的？端口号是多少？
具体忘了，说到了负载均衡的请求分发（聊了DNS的分发功能）
什么是DNS劫持？
虽然当时回答了，但是还是感觉得系统总结下，备忘。

DNS原理和理解
DNS的本质是什么？
Domain Name System = DNS（域名系统）其实是一个数据库，是用于 TCP/IP 程序的分布式数据库，同时也是一种重要的网络协议。DNS储存了网络中的 IP 地址与对应主机的信息，邮件路由信息和其他网络应用方面的信息，用户通过询问解决库（解决库发送询问并对DNS回应进行说明）在 DNS 上查询信息。

DNS的作用是什么?
DNS是网络分层里的应用层协议，事实上他是为其他应用层协议工作的，简单说就是把域名，或者说主机名转化为IP地址（同时也提供反向域名查询的功能），类似字典，比如访问 www.baidu.com，实际访问的是它的IP地址，因为机器识别的是拥有固定格式和含义的IP地址，而域名可以千奇百怪，甚至是中文，不利于识别。还有比如公司内部的域验证，通过分配给员工的域账号登录内网就必须通过DNS来找到域名权限服务器，来认证身份，故有些书上说：DNS是因特网世界里不可缺少的东西。

比如，使用host命令进行DNS查询
host

为什么叫域名系统，什么是域名？
人和人要互相识别和记忆，需要名字作为辅助，而对于网络世界，在因特网内也需要一种命名系统来做类似的事情，该系统使用了域来划分，任何一个网络里的主机（或者路由器）都有独一无二的域名（类似国家代码），域又能继续划分为子域（类似每个国家有不同的省份代码），子域还能继续划分（每个省都有自己的各个城市的代码）……在因特网内对应的就是顶级域名（com，net，cn，org等），二级域名……注意这仅仅是一种逻辑的划分。而这些域名系统在形式上组成了一种树结构。

名字（也叫标号）组成只能是英文或者数字，目前中文也支持了，长度不大于63个字符，总共完整域名长度不超过255个字符，英文域名不区分大小写，从右到左，域名级别依次降低。www是表示万维网，不属于域名。

域名空间树结构

域名的名字空间是一个树结构，根没有名字，各个树叶是单台计算机名，不能继续划分。

域名服务器
DNS服务器管理范围的单位是区，不是域，因为区才是DNS服务器管理的实际范围，区是域的子集，同一个区里的主机节点必须互通，它们都有一个统一的访问权限，该访问权限在通过一个权限域名服务器管理。比如，公司a，有两个部门x，y，部门x又有两个分部q和r，a会设立一个区叫a.com（区和域可以同名），这是一个大的权限范围，然后下属再设立一个区，叫x.a.com，那么区a.com和x.a.com都属于域a.com。

DNS服务器也是类似域名空间树一样的树结构，依次分为根域名服务器（知道所有的顶级域名服务器的域名和IP，最重要，它要是瘫痪，整个DNS就完蛋），然后是顶级域名服务器（管理二级域名），其次是权限域名服务器（负责区的域名服务器）。

最后是本地域名服务器（也叫默认域名服务器），本地域名服务器离主机很近（书上说不超过几个路由器），速度很快，其实本地域名服务器本质不属于域名服务器架构。

如图就是Linux的本地域名服务器配置

如图是Windows下本地DNS服务器配置

分布式域名系统
因为因特网规模很大，所以整个因特网只使用一个域名服务器是不行的。为了可靠，使用了分布式的域名系统，即使单个计算机除了故障，也不会妨碍整个DNS系统的正常运行。并采用c/s方式。DNS使大多数名字都在本地解析(resolve)，仅有少量解析需要在因特网上通信，因此分布式DNS系统借助分布式的主机备份和缓存机制，非常强壮和有足够的性能。

DNS劫持及解决办法
DNS劫持又称域名劫持，说白了就是当用户请求DNS解析的时候，对正常的DNS请求报文进行拦截，偷到请求的域名，然后就可以做手脚，比如常常遇到访问某个健康的网址的时候，明明输入的网址是xxxx.com，结果却跳转到了不可描述的网站……即把审查范围，或者权限范围以外的请求放行，否则返回假的IP地址或者什么都不做使请求失去响应，效果就是让人误以为断网（360网络诊断里经常说的，打的开QQ，但是无法浏览网页的现象），或者得到了假网址，黑客们经常利用漏洞或者程序的缺陷对用户的DNS进行篡改，进行钓鱼网站的欺诈活动。

解决办法可以手动修改本地DNS域名服务器地址，首选DNS服务器：114.114.114.114，是国内第一个、全球第三个开放的DNS服务地址，又称114DNS，或8.8.8.8（google提供的DNS服务器）等，然后修改宽带密码，路由器密码，主机密码。

域名到IP地址的解析过程
当一个应用需要把主机名解析为IP地址时，该应用进程就调用地址解析程序，它自己就变为了DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP方式先发给本地域名服务器，本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回，应用程序获得目的主机的IP地址后即可进行通信。若本地域名服务器不能回答该请求，则此域名服务器就暂时称为DNS的另一个客户，并向其他域名服务器发出查询请求。这种过程直至找到能够回答该请求的域名服务器为止。

域名的解析过程
主机向本地域名服务器的查询一般都是采用递归查询

如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户端的身份（递归思想），向根域名服务器继续发出查询报文(替主机查询)，不让主机自己进行查询。递归查询返回的结果或者是IP，或者报错。这是从上到下的递归查询过程。

本地域名服务器向根域名服务器查询一般采用迭代查询
当根域名服务器收到本地域名服务器的查询请求，要么给出ip，要么通知本地域名服务器下一步应该去请求哪一个顶级域名服务器查询（并告知本地域名服务器自己知道的顶级域名的IP），让本地域名服务器继续查询，而不是替他查询。同理，顶级域名服务器无法返回IP的时候，也会通知本地域名服务器下一步向谁查询（查询哪一个权限域名服务器）……这是一个迭代过程。

到底采用哪种查询，取决于原始查询报文的设置，不绝对。

DNS缓存
DNS中使用了高速缓存，因为域名到地址的映射不常变，故为提高效率而设，主机在启动时从本地服务器下载名和地址的全部数据，并维护存放自己最近使用的域名的缓存，并且只在从缓存中找不到名字时才使用根域名服务器发起查询。实际中，当一个 DNS 服务器接收到一个 DNS 回答后，会将其信息缓存一段时间，当再有一个对相同域名的查询时，便可直接回复。通过 DNS 缓存，大部分查询都只需要本地 DNS 服务器便可完成解析。

DNS缓存污染
本地域名服务器在接收到DNS请求时，先查找DNS缓存，如果缓存命中直接返回结果，如果黑客攻入路由器，对部分域名的缓存进行了更改，比如将缓存的结果指向不可描述的页面，那么即导致用户的正常请求被转移……，此时可以清除各级缓存（浏览器，系统，路由器，DNS缓存）。貌似无法避免，只能是提高安全意识，即使使用了 HTTPS也不行，因为DNS解析过程发生在HTTPS请求交互前。

FQ方法之——hosts 文件
Hosts是一个没有扩展名的系统文件，作用是将一些常用的网址域名与其对应的IP地址建立一个关联“数据库”， 其实 hosts 文件可以看作是一个小型的本地 DNS 服务器。

实际上网时域名的解析过程
优先顺序是：当用户在地址栏输入一个URL之后，浏览器首先查询浏览器的缓存，找不到就去查询Hosts文件和本地DNS缓存，如果hosts和本地DNS缓存都没有找到域名对应的IP，则自动进入路由器的缓存中检查，以上均为客服端DNS缓存，若在客户端DNS缓存还是没找到，则进入ISP DNS缓存中查询，还是找不到，最终才向 根DNS 服务器发出 DNS 查询报文，再找不到就报错……

IP地址到域名的反向域名查询
先了解下DNS报文，稍后会分析
+———————+
| 报文头 |
+———————+
| 问题　 | 向服务器提出的查询记录
+———————+
| 回答　 | 服务器回复的资源记录
+———————+
| 授权 | 权威的资源记录
+———————+
| 格外的 | 格外的资源记录
+———————+

哎，这个报文格式和名字也是醉了，不过不碍事，当在浏览器内输入URL时，便开始了DNS解析过程，最后会把找到后的IP地址告知浏览器客户端，方便它继续发出 HTTP（s）请求，该过程中，浏览器提出的查询记录类型叫A记录（address）查询，其他查询记录类型常见的有A（地址）记录、CNAME（别名）记录、MX（邮件交换）记录等。

比如问：www.baidu.com的A记录是什么？

是 220.181.110.181

这个A记录意思是从域名解析得到IP地址。那么反过来，从IP地址得到域名的解析过程也需要一个记录，叫PTR记录（和A记录功能相反），可以使用nslookup命令查询，可以通过查询IP地址的PTR记录来得到该IP地址指向的域名，达到反查的目的。

反向域名查询和垃圾邮件过滤
IP反向解析主要应用到邮件服务器中来阻拦垃圾邮件，比如用 xxx@xxx.com 给邮箱 xxxxx@qq.com 发了一封信。qq邮件服务器会查看信头文件，信头文件显示信是由哪个IP地址发出的，然后根据IP地址反向解析，如反向解析到这个IP所对应的域名是xxx.com （不在黑名单）那么就接受，否则拒绝。

了解反向域名-arpa
域名系统中，一个IP地址可对应多个域名，在Internet上是不会去傻傻的遍历整个域名树的。故DNS的顶级域名提供了一个特别的顶级域——arpa 用来做反向域名解析，也称为反向域名。当一个主机加入网络，获得DNS授权，它的IP地址假设为192.168.1.1，它也顺便获得了对应IP地址的 in-addr.arpa （逆向解析域in-addr.arpa）空间的授权，注意DNS名由树底部向上组织，故它的DNS名字为192.168 .1.1.in-addr.arpa。IP地址的第一字节一定位于in-addr的下一级。这样欲解析的IP地址就会被表达成一种像域名一样的形式，后缀以反向解析域名”in-addr.arpa”结尾。

本质上：反向域名解析是将IP地址表达成了一个域名，这样反向解析的很大部分可以纳入正向解析中。

抓包分析具体解析过程

如上是通常情况下的DNS报文，基于UDP数据报封装（同时DNS也支持TCP），并且要知道DNS服务器的默认端口是53

ping一个主机，开始抓包

观察出现的数据包

如图，第一行是DNS查询报文，第二行是DNS回答报文。

先看整个数据包的结构

证实了DNS确实为应用层的协议,目的端口号确实是53,传输层一般情况下采用UDP也是ok的,网络层是IP协议,数据链路层有以太网帧。

查看DNS数据包

对应的抽象报文格式图

+———————+
| 报文头 |
+———————+
| 问题　 | 向服务器提出的查询记录
+———————+
| 回答　 | 服务器回复的资源记录
+———————+
| 授权 | 权威的资源记录
+———————+
| 格外的 | 格外的资源记录
+———————+

先看查询报文头

首部12字节

标识ID，两个字节，对应DNS查询和DNS响应报文的id，目的是可以辨别DNS应答报文是哪个请求报文的响应，如下是响应报文的ID，两个一样

标志flags（不同于标识）字段又单独划分了

然后是查询的问题数

以上是12字节的DNS包头

然后是DNS的报文身体部分（问题or回答部分）
+———————+
| 报文头 |
+———————+
| 问题　 | 向服务器提出的查询记录
+———————+
| 回答　 | 服务器回复的资源记录
+———————+
| 授权 | 权威的资源记录
+———————+
| 格外的 | 格外的资源记录
+———————+

Queries为查询或者响应的正文，如下是请求报文里的问题部分

每个问题对应一个查询类型，响应报文里的资源记录部分里每个响应（资源记录）也对应一个资源类型。PS：资源记录也叫响应，如下

下面看DNS响应报文

大体和查询报文一致，响应包就是多出了一个Answers字段

响应报文的answer字段，第一个是请求的域名，然后cname记录表示出别名为www.a.shifen.com，这个别名的地址看下面具体的回答

DNS使用的网络层协议
DNS同时支持UDP和TCP访问，当名字解析器发出一个查询请求，并且返回响应报文中的TC位设置为1时，名字解析器通常使用TCP重发原来的查询请求，TCP能将用户的数据流分为一些报文段，用多个报文段来传送任意长度的用户数据，即允许返回的响应超过512个字节。

此外，为了减轻单台DNS服务器的负载，有时要将同一DNS区域的内容保存在多个DNS服务器中（主从备份，分布式存储），这时，就要用到DNS的“区域传输”功能。在分布式的DNS数据库中，当一个域的辅助名字服务器在启动时，将从该域的主名字服务器执行区域传送。辅助服务器将定时（通常是3小时）向主服务器进行查询以便了解主服务器数据是否发生变动，如果有变动，为了数据一致性，将执行一次区域传送，区域传送将使用TCP，因为传送的数据远比一个查询或响应多。

故DNS主要使用UDP，TCP为辅，如果是UDP，那么无论是名字解析器还是名字服务器都必须自己处理超时和重传。此外，DNS不像其他的使用UDP的应用一样，大部分操作集中在局域网上，DNS查询和响应通常经过广域网。分组丢失率和往返时间的不确定性在广域网上比局域网上更大。这样对于DNS客户程序，一个好的重传和超时程序就显得更重要。

DNS熟知的端口号
DNS服务器使用的熟知端口号无论对UDP还是TCP都是53

本地私有 DNS 服务器搭建
BIND (Berkeley Internet Name Domain)是DNS协议的一个实现，提供了DNS主要功能的开放实现，包括

域名服务器 (named)
DNS 解析库函数
DNS 服务器运行调试所用的工具
Bind 是一款开源的 DNS 服务器软件，由美国加州大学 Berkeley 分校开发和维护的，按照 ISC 的调查报告，BIND 是世界上使用最多最广泛的域名服务系统，通过搭建私有的 DNS 服务器，可以把国外的一些不可描述的 ip 地址放到自己的 DNS 服务器中畅快浏览。

安装环境本地ubuntu，客户端和服务器都是使用的一台机器

安装配置BIND

配置 DNS 主服务器（最好是设置主备）

ACL_百度百科

服务器环境测试

重启 BIND

配置 DNS 客户端
找一台机器作为DNS客户端，将客户端的 DNS 修改为刚刚搭建的DNS服务器的 ip 地址

使用nslookup验证
使用nslookup来查询服务器（若使用其他的客户端， ip 地址 需要加入到 “trusted” ACL 里面）。

DNS的基本配置
1 .DNS（域名服务器）
DNS(Domain Name Server，域名服务器)是进行域名和与之对应的IP地址转化的服务器。DNS中保存了一张域名和与之对应的IP地址的表，以解析消息的域名。

2.DNS高速缓存的作用
当某一个访问请求解析过一个域名以后，该解析记录就放在缓存中，以后在有同样的解析请求，就直接从缓存中提供结果，加快了访问者的应答速度。

3.配置DNS服务
在配置DNS缓存之前，最好关闭掉防火墙

systemctl stop firewalld.server
1.高速缓存DNS
<1>用yum search DNS找到软件
这里写图片描述
<2>用yum install bind.x86_64 -y 安装bind软件
这里写图片描述
<3>用rpm -qc bind.x86_64 查找配置文件
bind软件的配置文件时/etc/named.conf
这里写图片描述
<4>编辑配置文件
用cat /etc/services | grep name 查看name端口，DNS对应的端口为53号端口，在本地回环接口和本地IP都开放53号端口。如果之开放本地回环接口的53号端口，则其他主机无法访问。
这里写图片描述
默认情况下，本地回环端口开放了53号端口。
这里写图片描述
因此还需打开本地IP的53号端口提供访问服务。
编辑/etc/named.conf 将listen-on port 53 { 127.0.0.1; };
修改为 这里写图片描述
再次查看name端口就可以看到已经开放了本地IP53号端口
这里写图片描述
继续编辑/etc/named.conf
允许所有网络访问，设置上一级DNS
这里写图片描述
DNS不验证
这里写图片描述
编辑/etc/resolv.conf 添加 这里写图片描述
最后 systemctl restart named.server 重启服务
就配置完成高速缓存DNS了。

2.配置正向解析DNS
编辑/etc/named.conf 删除刚才配置的上一层DNS
“forwarders { 172.25.254.254; };”
在配置文件最后我们可以看到配置“域”文件
这里写图片描述
编辑/etc/named.rfc1912.zones文件添加域名为“redhat.com”域
这里写图片描述
(可以复制本地域(zone“localhost”IN的结构体)的配置加以修改)
“redhat.com”为我新添加的域,他会读取”redhat.com.zone文件”
cd /var/named/下创建文件。
cd /var/named/ 可以复制本身提供的模版文件，复制时一定要加参数-p，将文件的信息也复制。
这里写图片描述
编辑redhat.com.zone 区域数据文件
这里写图片描述
蓝色部分最后面有一个“.” 如果不写点系统会自动补齐在配置域文件中新加的域名,所以要么只写“dns”,要么写“dns.redhat.com.”
验证正向解析DNS是否配置成功，文件配置完成要重启服务
systemctl restart named.server
这里用IP为172.25.14.11的客户机验证，编辑客户机的
/etc/resolv.conf 添加 这里写图片描述
然后 dig www.redhat.com 这个刚刚设置的域名
如果ANSWER SECTION 是我们设置的172.25.254.14 ，就说明我们这个正向解析DNS配置成功
这里写图片描述
在dig dns.redhat.com试试，回答的IP正是刚才配置的IP
这里写图片描述
因此说明我们正向解析DNS配置成功！

3反向解析DNS
配置反向解析与正向解析方法基本相同
编辑/etc/named.rfc1912.zones文件添加反解的域
这里写图片描述
14.25.172时反着写的172.25.14网段
这里写图片描述
cd /var/named/下创建文件。
cd /var/named/ 可以复制本身提供的模版文件，复制时一定要加参数-p，将文件的信息也复制。
这里写图片描述
这里写图片描述
这里的加点“.”规则和正向解析一样。橙色的100加上刚才在配置域文件中反着写的网段就时我们要反向解析的IP
重启DNS服务。systemctl restart named.server
利用刚才的客户机验证服务配置是否正确
反向解析dig -x 172.25.14.100 （不要忘记参数-x）
这里写图片描述
ANSWER SECTION成功解析出www.redhat.com

4.CNAME更名
CNAME资源记录，规范名字(CNAME)资源记录创建特定FQDN的别名。用户可以通过定义的CANME记录中的别名来访问。
在之前正向解析的基础上，编辑正向解析区域数据文件
vim /var/named/redhat.com.zone
这里写图片描述
利用客户机验证
这里写图片描述
此时，www.redhat.com.相当于bbs.redhat.com.的别名。

5.MX邮件服务器
MX资源记录
邮件交换(MX)资源记录为DNS域名指定邮件交换服务器。邮件交换服务器是为DNS域名处理或转发邮件的主机。处理邮 件指把邮件投递到目的地或转交另一不同类型的邮件传送者。转发邮件指把邮件发送到最终目的服务器。编辑正向解析区域数据文件vim /var/named/redhat.com.zone
这里写图片描述
注意写点”.” 重启服务
客户机验证，向redhat.com发送邮件
这里写图片描述
发送成功就不会被退回，所以邮箱为空
这里写图片描述
172.25.14.10：25端口连接被拒绝，
但是MX邮件服务器配置成功
这里写图片描述

6.双线解析DNS
依不同接口给予不同的DNS主机名：view功能的应用
现在服务其有两个IP，一个是172.25.254.114/24，另一个是172.25.14.10/24。当我们从服务器解析一个域名时，得到的是对内的172.25.254.114，当客户机解析同一个域名是，仍然得到对内的172.25.254.114，而不是172.25.14.10，因此会为客户带来诸多不便，所以我们配置一个双向解析的DNS当只要不是内网来源的客户端，得到的是对外网段的IP。
因为当我们解析域名是，不同来源的主机会得到不同的结果，所以，我们就需要创建两份域。
cd /var/named
这里写图片描述
配置这个外网的域文件，将网段改为外网的172.25.14.0/24网段
这里写图片描述
还需要一个外网的named.rfc1912.zones.inter文件，用他来引出刚才的配置的域文件redhat.com.inter
这里写图片描述
编辑这个文件，让从外网解析到redhat.com.inter文件
这里写图片描述
有了这些文件，接下来就配置/etc/name.conf文件
将原来的引导语句注释起来或者删除
这里写图片描述
添加两个view，一个是内网(localnet)是172.25.254.0/24网段，引导到.zones文件，另一个就是外网(internet)任何网段都可以访问，引导到.zones.inter文件。
这里写图片描述
重启服务验证服务
从服务器（内网）dig www.redhat.com 解析到172.25.254网段
这里写图片描述
从客户机（外网）dig www.redhat.com 解析到172.25.14网段
这里写图片描述
验证双线解析DNS配置成功

7.主从（同级，同层）DNS
主从服务器的架构：主服务器含有域名的数据文件（zone），这个配置文件就是设置正解或者反解的“数据库”，包含各种记录。所以他本身就具有提供查询INTERNET查询所需要的数据。
假设主DNS服务器down掉了，那么他负责解析的域，主机名，IP都会失效，所以就有了从服务器存在的理由。但是当数据更新时，管理员需要手动更新两台服务器的内容，因此，Master/Slave架构解决了这个问题，一主一从，两台服务器数据的内容一样，当主服务器数据改变，自动同步到从服务器。

Master(主)： 172.25.14.10
Slave(从)：172.25.14.11
«主DNS服务器»：
这里写图片描述

允许转移 { 从服务器IP; };
并且通知 { 从服务器IP; };
这里写图片描述
«从DNS服务器»：
编辑DNS服务器区域数据文件
这里写图片描述
编辑域名为redhat.com的结构体
这里写图片描述
重启服务，cd /var/named/slaves ，在slaves目录中出现从服务器区域数据文件。
这里写图片描述
在从服务器上dig bbs.redhat.com，解析到IP如下：
此时解析到的IP是之前配置的IP
这里写图片描述
此时我们更改主服务器上DNS的域文件配置，更改IP：
更该主机名为bbs的IP；
第三行serial 改为10位数号码，当这个号码更改是，主服务器就会通知从服务器更新。
这里写图片描述
然后重启服务systemctl restart named.server
在从服务器中的/var/named/slaves/目录中的文件会自动更新
直接在从服务器中dig bbs.redhat.com，解析出的IP 已经改变为主服务器中配置的IP。
这里写图片描述
在主服务器的/var/log/messages日志中,也能看到更新成功通知
这里写图片描述

8.动态更新DNS服务
<1>编辑/etc/named.rfc1912.zones文件，在redhat.com域名的结构体设置允许更新主机的IP，并且重启服务。
这里写图片描述
<2>设置SElinnux防火墙
setsebool -P named_write_master_zones 1
<3>设置目录权限
既然需要其他主机更改主服务器上的数据，所以就要设置/var/named/目录的权限。这个目录的所有组时named
chmod g+w /var/named
这里写图片描述
然后我们就可以在设置的那台主机上更新区域数据了
这里写图片描述
删除掉www.redhat.com这个域，如果在dig www.redhat.com
就会没有解析结果
这里写图片描述
然后在添加一个域名
这里写图片描述
在去解析dig www.redhat.com 就会得到正确解析
这里写图片描述
但是还存在一个问题，被授权的服务器可以随意更改数据
因此，我们可以配置一个加密文件，只有被授权的服务器拥有密钥时，才能允许修改主服务器数据。
编辑/etc/named.rfc1912.zones文件，在redhat.com域名设置
允许密钥连接。
这里写图片描述
生成密钥，名字叫redhat
这里写图片描述
生成.key文件（可以复制模板文件，加参数-p）
通过cat 刚才生成的密钥，得到密码然后设置.key文件
这里写图片描述
密码一定要一致，名字时刚起的redhat
这里写图片描述
此时当别的服务器想更新主服务器的数据时，则会被拒绝
这里写图片描述
然后给这台主机发送“密钥”
这里写图片描述
通过私钥来更新主服务器数据
nsupdate -k *.private
这里写图片描述
正确解析出了结果，说明动态更新DNS配置正确。
这里写图片描述

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