本章学习 DNS 域名解析服务的原理以及作用，介绍域名查询功能中正向解析与反向解析的作用，并通过实验的方式演示如何在 DNS 主服务器上部署正、反解析工作模式； 然后部署 DNS 从服务器以及 DNS 缓存服务器来提升用户的域名查询体验，以及如何使用 chroot 牢笼机制插件来保障 bind 服务程序的可靠性。
还会演示如何在主服务器与从服务器之间部署 TSIG 密钥加密功能，来进一步保障迭代查询中数据的安全性；最后从实战层面讲解了 DNS 分离解析技术，让来自不同国家、不同地区的用户都能获得最优的网站访问体验。
13.1 DNS 域名解析服务
相较于由数字构成的 IP 地址，域名更容易被理解和记忆，所以我们通常更习惯通过域名的方式来访问网络中的资源。但是计算机之间只能基于 IP 地址来相互识别对方的身份，而且要想在互联网中传输数据，也必须基于外网的 IP 地址来完成。
那么怎么才能让域名可以使用呢？域名系统（Domain Name System，DNS）技术应运而生，这是一项用于解析域名与 IP 地址对应关系的技术，即将域名解析为 IP 地址（正向解析），或将 IP 地址解析为域名（反向解析）；只需要在浏览器中输入域名就能打开想要访问的网站了，这种 DNS 域名正向解析也是我们最常使用的一种工作模式。
鉴于互联网中的域名和 IP 地址对应关系数据库太过庞大，DNS 域名解析服务采用了类似目录树的层次结构来记录域名与 IP 地址之间的对应关系，从而形成了一个分布式的数据库系统如图。
域名后缀一般分为国际域名和国内域名，原则上域名后缀都有严格的定义，但在实际使用时可以不必严格遵守；目前最常见的域名后缀有.com（商业组织）、.org（非营利组织）、.gov（政府部门）、.net（网络服务商）、.edu（教育机构）、.pub（公共大众）、.cn（中国国家顶级域名）等。
如今世界的信息化程度越来越高，大数据、云计算、物联网、人工智能等新技术不断涌现，全球网民的数量据说超过了 53 亿，而且每年还在以 7%的速度迅速增长，这些因素导致互联网中的域名数量进一步激增，被访问的频率也进一步加大。DNS 技术作为互联网基础设施中重要的一环，为网民提供不间断、稳定且快速的域名查询服务，提供了下面 3 种类型的服务器。
➢ 主服务器：在特定区域内具有唯一性，负责维护该区域内的域名与 IP 地址之间的对应关系。
➢ 从服务器：从主服务器中获得域名与 IP 地址的对应关系并进行维护，以防主服务器宕机等情况。
➢ 缓存服务器：通过向其他域名解析服务器查询获得域名与 IP 地址的对应关系，并将经常查询的域名信息保存到服务器本地，以此来提高重复查询时的效率。
通俗来讲主服务器是用于管理域名和 IP 地址对应关系的真正服务器，从服务器帮助主服务器“打下手”，分散部署在各个国家、省市或地区，以便让用户就近查询域名，从而减轻主服务器的负载压力；缓存服务器不太常用，一般部署在企业内网的网关位置，用于加速用户的域名查询请求。 DNS 域名解析服务采用分布式数据结构来存放海量的“区域数据”信息，在响应用户发起的域名查询请求时，有递归查询和迭代查询两种方式。
递归查询指 DNS 服务器在收到用户发起的请求时，必须向用户返回一个准确的查询结果。如果 DNS 服务器本地没有存储与之对应的信息，则该服务器会询问其他服务器，并将返回的查询结果提交给用户。
迭代查询则是指 DNS 服务器在收到用户发起的请求时，并不直接回复查询结果，而是提供另一台DNS 服务器的地址，用户再向这台 DNS 服务器提交请求这样依次反复，直到返回查询结果。 其查询流程大致如图 。
当用户向网络指定的 DNS 服务器发起一个域名请求时，通常情况下会有本地 DNS 服务器向上级的 DNS 服务器发送迭代查询请求；如果该 DNS 服务器没有要查询的信息，则会进一步向上级 DNS 服务器发送迭代查询请求，直到获得准确的查询结果为止。其中最高级、最权威的根 DNS 服务器总共有 13 台，分布在世界各地；详细信息如图。
注意！
这里提到的 13 台根域服务器并非真的只有 13 台服务器，没有哪台服务器能独立承受住如此大的请求量；实际上用于根域名的服务器总共有 504 台，它们从 A 到 M 进行了排序，并共用 13 个 IP 地址进行负载均衡，以此抵抗分布式拒绝服务（DDoS）的攻J。
随着互联网设备数量的增长，原有的 IPv4 体系已经不能满足需求，IPv6 协议在全球开始普及。基于 IPv6 的新型地址结构为新增根服务器提供了契机，我国的“下一代互联网国家工程中心”于 2013 年联合日本、美国相关运营机构和专业人士发起“雪人计划”，提出以 IPv6 为基础、面向新兴应用、自主可控的一整套根服务器解决方案和技术体系，并于 2017 年 11 月在全球完成 25 台 IPv6 根服务器的架设（我国部署了其中的 4 台，打破了我国过去没有根服务器的困境）。
13.2 安装 bind 服务程序
BIND（Berkeley Internet Name Domain，伯克利因特网名称域）服务是全球范围内使用最广泛、最安全高效的域名解析服务程序。建议大家在生产环境中部署 bind 服务程序时加上 chroot（俗称牢笼机制）扩展包，以便有效地限制 bind 服务程序仅能对自身的配置文件进行操作，以确保整个服务器的安全。
要想为用户提供健全的 DNS 查询服务，就要在本地保存相关的域名数据库，如果把所有域名和 IP 地址的对应关系都写入到某个配置文件中，估计要有上千万条的参数，这样既不利于程序的执行效率，也不方便日后的修改和维护；因此在 bind 服务程序中有下面这 3 个比较关键的文件。
➢ 主配置文件（/etc/named.conf）：只有 59 行，而且在去除注释信息和空行之后，实际有效的参数仅有 30 行左右，这些参数用来定义 bind 服务程序的运行。
➢ 区域配置文件（/etc/named.rfc1912.zones）：用来保存域名和 IP 地址对应关系的具体位置，类似于图书的目录，对应着每个域和相应 IP 地址所在的具体位置，当需要查看或修改时根据这个位置找到相关文件。
➢ 数据配置文件目录（/var/named）：该目录用来保存域名和 IP 地址真实对应关系的数据配置文件。
bind 服务程序的名称为 named，首先在主配置文件 /etc/named.conf 中把第 11 行和 19 行的地址均修改为 any，分别表示服务器上的所有 IP 地址均可提供 DNS 域名解析服务，及允许所有人对本服务器发送 DNS 查询请求。
bind 服务程序的区域配置文件（/etc/named.rfc1912.zones）用来保存域名和 IP 地址对应关系的所在位置；定义了域名与 IP 地址解析规则保存的文件位置以及服务类型等内容，而没有包含具体的域名与IP 地址对应关系的信息。服务类型有 3 种，分别为 hint（根区域）、master（主区域）、slave（辅助区域），其中常用的 master 和 slave 指的就是主服务器和从服务器。
13.2.1 正向解析实验
在 DNS 域名解析服务中，正向解析是指根据域名（主机名）查找到对应的 IP 地址；当用户输入了一个域名后，bind 服务程序会自动进行查找，并将匹配到的 IP 地址返给用户，这也是最常用的 DNS 工作模式。
下面的实验会分别修改 bind 服务程序的主配置文件、区域配置文件与数据配置文件。如果在实验中遇到了 bind 服务程序启动失败的情况，则可以执行 named-checkconf 命令和 named-checkzone 命令，分别检查主配置文件与数据配置文件中语法或参数的错误。
编辑区域配置文件 /etc/named.rfc1912.zones ；该文件中默认已经有了一些无关紧要的解析参数可供参考；其中 file “ ” 后面的名称是有对应关系的，此文件真实的数据在 /var/named 目录中；可以按下面的参数添加到区域配置文件的最下面，或者将该文件中的原有信息全部清空，只保留自己的域名解析信息。
编辑数据配置文件；可以从 /var/named 目录中复制一份正向解析的模板文件 named.localhost，然后把域名和 IP 地址的对应数据填写进配置文件中保存。在复制时记得加上-a 参数，这可以保留原始文件的所有者、所属组、权限属性等信息，以便让 bind 服务程序顺利读取文件内容。
考虑到正向解析文件中的参数较多，下面对每个参数都作了简要的说明；编辑完成后记得 wq 保存并重启 named 服务程序，让新的解析数据生效。
在解析文件中，A 记录类型表示将域名指向一个 IPv4 地址，而 AAAA 表示将域名指向一个 IPv6 地址；此外还有下图中的 8 种记录类型。
为了检验解析结果，一定要先把 Linux 系统网卡中的 DNS 地址修改成本机 IP 地址，这样就可以使用由本机提供的 DNS 查询服务了。nslookup 命令用于检测能否从 DNS 服务器中查询到域名与 IP 地址的解析记录，来更准确地检验 DNS 服务器是否已经正常提供服务。
若解析出的结果不是本机 IP，则很有可能是虚拟机选择了联网模式，并由互联网 DNS 服务器进行了解析；正常解析结果为上图“Address: 本机 IP#53”，即由本地服务器 IP 的 53 端口号进行解析。
13.2.2 反向解析实验
在 DNS 域名解析服务中，反向解析的作用是将用户提交的 IP 地址解析为对应的域名信息，一般用于对某个 IP 地址上绑定的所有域名进行整体屏蔽，屏蔽由某些域名发送的垃圾邮件；也可以针对某个 IP 地址进行反向解析，大致判断出有多少个网站运行在上面。
编辑区域配置文件 /etc/named.rfc1912.zones；反向解析在定义 zone（区域）时要把 IP 地址反写，比如原来是 192.168.187.0，反写后就是 187.168.192，而且只需写出 IP 地址的网络位即可。把下列参数添加至正向解析参数的后面。
编辑数据配置文件；同上从 /var/named 目录中 cp 反向解析的模板文件 named.loopback，加上 -a 参数改名为 192.168.187.arpa，然后按下面的格式填写到文件中，其中 IP 地址仅需要写主机位如图。
下图参数 PTR 为指针记录，仅用于反向解析。
重启 named 服务检验解析结果；在前面的正向解析实验中，已经把系统网卡中的 DNS 地址修改成了本机 IP 地址，因此可以直接使用 nslookup 命令来检验解析结果，输入 IP 地址即可查询到对应的域名信息。
13.3 部署从服务器
在 DNS 域名解析服务中，从服务器可以从主服务器上获取指定的区域数据文件，从而起到备份解析记录与负载均衡的作用；通过部署从服务器不仅可以减轻主服务器的负载压力，还可以提升用户的查询效率。
在主服务器的区域配置文件中允许该从服务器的更新请求，即修改 allow-update {允许更新区域信息的主机地址;};参数，然后重启主服务器的 DNS 服务程序。配置防火墙放行规则，让 DNS 协议流量可以正常通过。
在从服务器上安装 bind-chroot 软件包，修改主配置文件 /etc/named.conf，让从服务器也能够对外提供 DNS 服务，并且测试其与主服务器的网络连通性。
编辑从服务器 zone 配置文件 /etc/named.rfc1912.zones，填写主服务器的 IP 地址与要抓取的区域信息，然后重启服务；注意此时的服务类型应该是 slave（从），而不再是 master（主）；masters 参数后面为主服务器的 IP 地址，而且 file 参数后面定义的是同步数据配置文件后要保存到的位置，稍后可以在该目录内看到同步的文件。
当从服务器的 DNS 服务程序重启后，一般就已经自动从主服务器上同步了数据配置文件，而且该文件默认会放置在区域配置文件中 file 后面所定义的目录位置中。 随后确认从服务器的网络参数，把 DNS 地址改为 192.168.187.131，启用网卡后即可使用从服务器提供 DNS 域名解析服务。最后使用 nslookup 命令顺利看到解析结果了。
13.4 安全的加密传输
互联网中的绝大多数 DNS 服务器（超过 95%）都是基于 BIND 域名解析服务搭建的，而 bind 服务程序为了提供安全的解析服务，已经对 TSIG（见 RFC 2845）加密机制提供了支持。TSIG 主要是利用了密码编码的方式来保护区域信息的传输（Zone Transfer），即 TSIG 加密机制保证了 DNS 服务器之间传输域名区域信息的安全性。
dnssec-keygen 命令用于生成安全的 DNS 服务密钥，其格式为“dnssec-keygen [参数]”，下面在主服务器生成一个主机名称为 bind 的 128 位 HMAC-MD5 算法的密钥文件； 在执行该命令后默认会在当前目录中生成公钥和私钥文件，我们需要把私钥文件中 Key 参数后面的值记录下来，一会儿要将其写入密钥验证文件中。常用的参数以及作用如图。
在主服务器中创建密钥验证文件；进入 bind 服务程序用于保存配置文件的目录，把刚刚生成的密钥名称、加密算法和私钥加密字符串按照下面的格式写入 tran.key 传输配置文件中。为了安全可将文件的所属组修改成 named 并将文件权限设为 640，然后设置该文件一个硬链接指向/etc 目录。
开启并加载 bind 服务的密钥验证功能；需要在主服务器的主配置文件 /etc/named.conf 中添加加载密钥验证文件，然后重启 bind 服务，使得只允许带有 bind 密钥认证的 DNS 服务器同步数据配置文件。
至此 DNS 主服务器的 TSIG 密钥加密传输功能就已经配置完成；清空 DNS 从服务器同步目录中所有的数据配置文件，再次重启 bind 服务程序同步，发现已经不能像先前自动获取到数据配置文件了。
配置从服务器使其支持密钥验证；配置 DNS 从服务器和主服务器的方法大致相同，都需要在 bind 服务程序的配置文件目录中创建密钥认证文件，并设置相应的权限，然后设置一个硬链接指向 /etc 目录。
开启并加载从服务器的密钥验证功能；同样是在主配置文件中加载密钥认证文件，然后按照指定的格式写上主服务器的 IP 地址和密钥名称。注意！密钥名称等参数位置不要太靠前，大约在第 50 多行比较合适，否则 bind 服务程序会因为没有加载完预设参数而报错。
两台服务器的 bind 服务程序都已经配置妥当，并匹配到了相同的密钥认证文件。接下来在从服务器上重启 bind 服务程序，可以发现又能顺利地同步到数据配置文件了；再次进行解析显示是由 131 的从服务器提供。
13.5 部署缓存服务器
DNS 缓存服务器把用户经常使用到的域名与 IP 地址的解析记录保存在主机本地，从而提升下次解析的效率。DNS 缓存服务器一般用于经常访问某些固定站点而且对这些网站的访问速度有较高要求的企业内网中，但实际的应用并不广泛，并且是否可以成功解析还与指定的上级 DNS 服务器的允许策略有关。
下面配置系统的双网卡参数；缓存服务器一般用于企业内网，旨在降低内网用户查询 DNS 的时间消耗。为了更加贴近真实的网络环境，实现外网查询功能，我们需要在缓存服务器中再添加一块网卡，客户端不局限于一台。下图为缓存服务器实验环境的结构拓扑。
将新添加的网卡设置为“桥接模式”，然后设置成与物理设备相同的网络参数（此处需要大家按照物理设备真实的网络参数来配置）。
新添加的桥接模式网卡默认是没有配置文件的，需要自行输入网卡名称和Ethernet 类型。配置好后用命令 nmcli connection up 让新的网卡参数生效。
在 bind 服务程序的主配置文件 /etc/named.conf 添加缓存转发参数；在大约第 20 行添加参数“forwarders { 上级 DNS 服务器地址; };”，上级 DNS 服务器地址指的是获取数据配置文件的服务器。考虑到查询速度、稳定性、安全性等因素，我这里使用的是深圳市移动 DNS 服务器的地址 211.136.192.6。
重启 DNS 服务验证结果；把客户端主机的 DNS 服务器地址参数修改为 DNS 缓存服务器的 IP 地址 192.168.187.128，这样即可让客户端使用本地 DNS 缓存服务器提供的域名查询解析服务。
在将客户端主机重启网络服务，即可使用 nslookup 命令来验证，可见 cool 与 down 用的同一个地址。
13.6 分离解析技术
喜欢看《Linux 就该这么学（第 2 版）》的海外读者越来越多，如果继续把本书配套的网站服务器架设在北京市的机房内，则海外读者的访问速度会很慢，直接把服务器架设在海外的机房，国内读者的访问会很慢。于是可以购买多台服务器并分别部署在全球各地，然后使用 DNS 的分离解析功能让不同地理范围内的读者通过访问相同的网址，从不同的服务器获取到相同的数据。
例如下图分别为处于北京的 DNS服务器和处于美国的 DNS 服务器分配不同的 IP 地址，然后让国内读者在访问时自动匹配到北京的服务器，而让海外读者自动匹配到美国的服务器。建议大家将虚拟机还原到初始状态，并重新安装 bind 服务程序，以免多个实验之间相互产生冲突
下面修改 bind 服务程序的主配置文件，同前面实验把第 11 行的监听端口与第 19 行的允许查询主机修改为 any，由于配置 DNS 分离解析功能与 DNS 根服务器配置参数有冲突，所以需要把第 55 行的根域信息删除或注释掉。
把区域配置文件 /etc/named.rfc1912.zones 中原有的数据清空，然后按照以下格式写入参数。首先使用 acl 参数分别定义两个变量名称（china 与 america），view 参数的作用是通过判断用户的 IP 地址是中国的还是美国的，然后去分别加载不同的数据配置文件（linuxprobe.com.china 或 linuxprobe.com.america）；当把相应的 IP 地址分别写入到数据配置文件后，即可实现 DNS 的分离解析功能。
建立数据配置文件；同上面实验从 /var/named 目录中 cp 通过模板文件创建出两份不同名称的区域数据文件， 其名称要与上面区域配置文件中的参数相对应。
其中 122.71.115.15 和 106.185.25.15 两台服务器并没有在实验环节中配置，需要验证全部的可自行设置。目前可以验证解析到 122.71.115.10 和106.185.25.10 服务器。
重新启动 named 服务验证结果；将客户端主机（Windows 系统或 Linux 系统均可）的 IP 地址分别设置为 122.71.115.1 与 106.185.25.1，将 DNS 地址分别设置为服务器主机的两个 IP 地址；当不同的客户机ping 网站域名时就能清晰地看到是由哪个服务器 IP 返回的结果。
模拟的外网用户测试，结果也是由外网 DNS 服务器 IP 提供的解析。
