DNS 服务器

什么是 DNS？

简单来说，Domain Name System 作用就是把我们在浏览器里输入的网站域名，翻译成机器能听懂的 IP 地址。你可以把它想象成互联网世界的“电话簿”：我们不需要记住每个网站复杂的数字 IP（比如 192.0.2.1），只需要记住像 www.example.com 这样好记的名字，DNS就会帮我们找到对应的联系方式
DNS 是层级化且去中心化的。全球各地分布着无数的域名服务器，它们定期沟通、更新数据并消除冗余。这种分布式设计极大地提高了互联网的访问速度和可靠性

DNS 是怎么运作的

要搞懂 DNS 的解析过程，需要认识四种服务器，当请求一个 URL 时，请求会在这四个服务器之间穿梭，直到找到正确的IP地址

DNS 递归解析器 (DNS Recursor)

DNS Recursor 也称为 DNS 递归服务器，专门负责接收来自客户端设备的主机名查询，当客户端发起 URL 请求时，它是第一个被联系的 DNS 服务器，通常由互联网服务提供商运营
在收到客户端的请求后，DNS 解析器会自己模拟客户端的行为，向其他三类 DNS 服务器发起查询，并检查从权威 DNS 服务器获取的记录，以获取对应的 IP 地址
当收到主机名查询请求时，DNS 解析器首先会在本地缓存或客户端设备操作系统的缓存中查找，如果在缓存中找到了该主机名，则立即完成解析并返回结果。如果缓存中没有找到，则 DNS 解析器会联系 DNS 根服务器，继续进行后续的 DNS 解析过程

根域名服务器 (Root Nameserver)

根域名服务器包含构成根区域（Root Zone）的信息。根区域包含所有顶级域（TLD）的名称和 IP 地址。根区域包含以下信息：

• 通用顶级域名（gTLD），例如 .com、.net、.io 等
• 国家代码顶级域名（ccTLD）例如加拿大的 .ca 或日本的 .jp
• 国际化顶级域名（IDN TLD）

注意：在 DNS 查询过程中，DNS 递归服务器无法被直接指向根区域。因此，解析器软件中内置了一份包含 13 个根服务器 IP 地址 的列表。每当发起 DNS 查询时，DNS 解析器的首次通信总是与这 13 个硬编码的 IP 地址之一进行
DNS 系统会将 DNS 请求路由到地理位置最近的根域名服务器。根区域的数据来自互联网数字分配机构（IANA），IANA 是互联网名称与数字地址分配机构（ICANN）的一部分。根区域使用 DNSSEC 签名以确保真实性，将其分发给根服务器运营商，以便他们在自己的根服务器上发布

顶级域名服务器 (TLD Nameserver)

顶级域名服务器包含所有共享相同域名后缀的域名信息，例如 .com、.net 等
TLD 服务器保存该顶级域名下二级域名（如 example.com）的 IP 地址。换句话说，.com TLD 服务器包含所有以 .com 结尾的网站的 IP 地址信息
在 DNS 解析过程中，TLD 服务器的任务是返回请求主机名的权威域名服务器（Authoritative Nameserver）的 IP 地址

权威域名服务器 (Authoritative Nameserver)

权威域名服务器是 DNS 解析过程的最终环节。权威服务器接收域名和子域名，并向 DNS 解析器返回正确的 IP 地址。请注意，只有当该权威服务器拥有相应 DNS 记录时才会发生这种情况
在某些情况下，权威域名服务器会将 DNS 解析器引导至另一个包含特定子域名记录的服务器（例如 support.example.com）
权威域名服务器分为两种类型：主服务器（Master/Primary Nameserver）和从服务器（Slave/Secondary Nameserver）。主服务器保存区域记录的原始副本，而从服务器保存一份副本。由此，从服务器就可以分担 DNS 查询负载，并在主服务器出现故障时作为备份

DNS 服务介绍

学习DNS层次结构前，首先要搞清楚DNS层次结构中一些术语，例如domain，subdomain和zone
域名 Domain ，是互联网中用于标识网站或网络资源的名称，例如 example.com，它由顶级域名和更低层级的标签组成
子域名 Subdomain ，是主域名下更细分的一层，用于区分不同服务或部门，比如 www.example.com、blog.example.com
区域 Zone ，是 DNS 管理中的概念，指的是某个域名及其子域名 DNS 记录的管理范围，通常对应一个DNS 区域文件或 DNS 提供商中的一个配置单元，所以域名表示地址，子域名表示该地址的子部分，而 Zone 则表示对这些名称及其记录进行集中管理的边界

DNS 查询

主机的 DNS 查询主要有两种方式：递归查询和迭代查询
DNS 查询时，DNS 请求报头部的 RD 字段决定了查询类型：
RD 为 1 => 递归查询（默认查询方式）
RD 为 0 => 迭代查询

• 递归查询 以 本地名称服务器 为中心进行查询

递归查询：以本地名称服务器为中心，DNS 客户端只是发出原始的域名查询请求报文，然后就一直处于等待状态，直到本地名称服务器发来了最终的查询结果。此时的本地名称服务器就相当中介代理的作用

• 迭代查询 以 DNS客户端自己 为中心查询

迭代查询：以DNS客户端自己为中心。所有查询工作全部是 DNS 客户端自己进行。DNS客户 会按照顺序向本地名称服务器 、一级名称服务器、二级名称服务器、权威名称服务器发出查询 DNS的请求查询报文，这个过程中每一级服务器就会返回一个能解答这个查询的下一个名称服务器列表 A，获取到下个查询列表信息 A 后 DNS 客户 会再向返回的列表 A 中发出请求，直到找到最终负责所查域名的名称服务器，从它得到最终结果

递归查询与迭代查询的本质区别（Fact）
角色定位不同
公共 DNS（如 8.8.8.8）：它们的定位就是“服务大众”，所以必须开启递归
权威 DNS（Authoritative Server）：它们的职责是回答自己管辖范围内的域名，而不是帮别人去查其它域名。为了保持自身的专注和稳定它们通常严禁递归

迭代查询：当 DNS 服务器不知道答案时，它不会替客户端继续查询，而是返回一个参照Referral。这个响应包的权威段Authority Section或附加段Additional Section中会包含下一级 DNS 服务器的名称和 IP 地址。它把“找路”的任务直接丢回给客户端，或上一级解析器

递归查询：当 DNS 服务器不知道答案时，它绝不会向客户端返回下层服务器的地址，而是扮演客户端的角色，亲自向下一级服务器发起请求。它必须直接给客户端一个最终结果：正确的 IP 地址或错误信息
递归服务器通常需要维护一个庞大的缓存表有些DNS服务器，为了减轻自己的负载，则会配置禁止使用递归查询，则客户端只能使用迭代查询

DNS 系统的有效性在于这种混合架构：它把易用性留在了网络边缘电脑和本地ISP之间，把高性能与高可靠性留在了全球根服务器和权威服务器之间，普通用户因此得以享受傻瓜式简单服务，而互联网核心架构也得以免于被海量查询压垮

迭代查询

迭代查询（Iterative Query） 也叫迭代解析。使用迭代解析方式时，所有的查询工作都是由 DNS 客户自己进行的，迭代查询遵循的是“参考与转接”原则。当一台 DNS 服务器（通常是根或顶级域服务器）收到迭代查询请求时，如果其本地没有直接答案，它不会代为向外询问，而是向请求者返回一个参考地址（Referral），即指向下一级更有权限的服务器地址。这种机制将查询的压力分散到了请求端（通常是运营商的递归服务器），确保了处于金字塔顶端的根服务器不会因为处理全球海量的嵌套递归任务而过载
在实际运作中，迭代查询是一个层层收缩范围的过程。以查询 www.example.com 为例：本地 DNS 服务器首先以迭代方式询问根服务器，根服务器由于只维护顶级域信息，会给出 .com 服务器的地址；本地服务器转而询问 .com 顶级服务器，得到 example.com 授权服务器的地址；最后，本地服务器直接向该权威服务器发起请求，并最终获取主机记录
如果它所配置的主名称服务器（如 Windows 系统中的 首选 DNS 服务器）不能解析的话，客户端还会继续向所配置的其它名称服务（如 Windows 系统中的 备用 DNS 服务器）查询。如果考虑了本地名称服务器的缓存技术（在 DNS 服务器上对一定数量查询过的记录保存一定时间，这样后面查询同样的域名信息时就可直接从缓存中调出来，以加速查询效率）的话，迭代名称解析的基本流程如下（在此仅以首先 DNS 服务器作为本地名称服务器为例，与其它备用 DNS服务器的解析流程完全一样）：

1. DNS 客户端向本机配置的本地名称服务器发出 DNS 域名查询请求
2. 本地名称服务器收到请求后，先查询本地的缓存

• 如果有该域名的记录项，则本地名称服务器就直接把查询的结果返回给客户端。
• 如果本地缓存中没有该域名的记录，则向 DNS 客户端返回一条 DNS 应答报文，报文中会给出一些参考信息，如本地名称服务器上的根名称服务器地址等

3. DNS 客户端在收到本地名称服务器的应答报文后，会根据其中的根名称服务器地址信息，向对应的根名称服务器再次发出与前面一样的 DNS 查询请求报文
4. 根名称服务器在收到 DNS 查询请求报文后，通过查询自己的 DNS 数据库得到请求 DNS 域名中顶级域名所对应的顶级名称服务器信息，然后以一条 DNS 应答报文返回给 DNS 客户端
5. DNS 客户端根据来自根名称服务器应答报文中的对应顶级名称服务器地址信息，向该顶级名称服务器发出与前面一样的 DNS 查询请求报文
6. 顶级名称服务器在收到 DNS 查询请求后，先查询本地的缓存：
   如果有所请求的 DNS 域名的记录项，则直接把对应的记录项返回给 DNS 客户端
   否则，通过查询后把对应域名中二级域名所对应的二级名称服务器地址信息以一条 DNS应答报文返回给 DNS 客户端。如果在上述步骤中对应域名的权威名称服务器都说找不到对应的域名记录，则会向 DNS 客户端返回一条查询失败的 DNS 应答报文，称为负响应。当然，如果这个权威名称服务器上配置了指向其它名称服务器的转发器，则权威名称服务器还会在转发器指向的名称服务器上进一步重复上述步骤查询。另外，如果 DNS 客户端上配置了多个 DNS 服务器，则还会继续向其它 DNS 服务器查询的。DNS 查找到这里就基本来可以获取域名对应的 IP 了，除非需要查找的域名没有配置 IP 则查询失败

• 迭代查询过程示例
  

假设客户端访问站点www.example.com ，那么 DNS 客服端的查询过程如下：

1. DNS 客户端向所配置的本地名称服务器发出解析 www.example.com 域名的 DNS 请求报文。
2. 本地名称服务器收到 客户端的 DNS 查询请求报文后，先查询本地缓存。假设没有查到该域名对应记录，则本地名称服务器把所配置的根名称服务器 a.rootserver.net 地址信息以 DNS 应答报文返回给 DNS 客户端
3. DNS 客户端在收到本地名称服务器的 DNS 应答报文后，根据其中给出的根名称服务器地址信息，向对应的根名称服务器再次发送解析 www.example.com 域名的 DNS 请求报文）。
4. 根名称服务器在收到 DNS 查询请求后，通过查询得到 .com 顶级域名所对应的顶级名称服务器，然后把查询到的对应顶级域名信息以一条 DNS 应答报文返回给 DNS 客户端
5. DNS 客户端在收到根名称服务器的 DNS 应答报文，得到 .com 顶级域名所对应的顶级名称服务器地址后，再次向对应的顶级名称服务器发送一条解析 www.example.com 域名的的DNS 请求报文。
6. .com 顶级名称服务器在收到 DNS 客户端的 DNS 查询请求报文后，先查询本地的缓存，假设也没有该域名的记录项，则查询example.com 所对应的二级名称服务器，然后把查询到的对应二级域名信息以一条 DNS 应答报文返回给 DNS 客户端
7. DNS 客户端在收到 .com 顶级名称服务器的 DNS 应答报文，得到 example.com 二级域名所对应的二级名称服务器地址后，再次向对应的二级名称服务器发送一条解析 www.example.com 域名的 DNS 请求报文。
8. example.com 二级名称服务器在收到 DNS 客户端的 DNS 查询请求报文后，也先查询本地的缓存。假设也没有该域名的记录项，则查询 www.example.com 所对应的权威名称服务器（因为这个名称服务器已包括了整个域名 www.example.com 所在区域），然后把查询到的对应权威域名信息以一条 DNS 应答报文返回给 DNS 客户端9. DNS 客户端在收到 example.com 二级名称服务器的 DNS 应答报文，得到www.example.com 三级域名所对应的权威名称服务器地址后，再次向对应的权威名称服务器发送解析 www.example.com 域名的 DNS 请求报文
9. 权威名称服务器 www.example.com 在收到 DNS 客户端的 DNS 查询请求报文后，在它的DNS 区域数据库中查找，最终得出了 www.example.com 域名所对应的 IP 地址。然后向 DNS 客户端返回一条 DNS 应答报文。这样 DNS 客户端获取 IP 地址后就可以正常访问这个网站了

递归查询

递归查询是默认的 DNS 解析方式。在这种解析方式中，如果客户端配置的本地名称服务器遇到不能解析的，则后面的查询全由本地名称服务器代替DNS 客户端进行查询，直到本地名称服务器从权威名称服务器得到了正确的解析结果，然后由本地名称服务器告诉 DNS 客户端查询的结果。
在递归查询过程中，一直是以本地名称服务器为中心的，DNS 客户端只是发出原始的域名查询请求报文，然后就一直处于等待状态，直到本地名称服务器返回最终的查询结果。此时的本地名称服务器就相当于中介代理的作用。
如果考虑了本地名称服务器的缓存技术（在 DNS 服务器上对一定数量查询过的记录保存一定时间，这样后面查询同样的域名信息时就可直接从缓存中调出来，以加速查询效率），则递归解析的基本流程如下（在此仅以首先 DNS 服务器作为本地名称服务器为例，与其它备 DNS 服务器的解析流程完全一样）：

1. 客户端向本机配置的本地名称服务器发出 DNS 域名查询请求。
2. 本地名称服务器收到请求后，先查询本地的缓存，如果有该域名的记录项，则本地名称服务器就直接把查询的结果返回给客户端；如果本地缓存中没有该域名的记录，则本地名称服务器再以 DNS 客户端的角色发送与前面一样的 DNS 域名查询请求发给根名称服务器。
3. 根名称服务器收到 DNS 请求后，把所查询得到的所请求的 DNS 域名中顶级域名所对应的顶级名称服务器地址返回给本地名称服务器。
4. 本地名称服务器根据根名称服务器所返回的顶级名称服务器地址，向对应的顶级名称服务器发送与前面一样的 DNS 域名查询请求。
5. 顶级名称服务器在收到 DNS 查询请求后，也是先查询本地的缓存，如果有所请求的 DNS 域名的记录项，则直接把对应的记录项返回给本地名称服务器，然后再由本地名称服务器返回给 DNS 客户端，否则向本地名称服务器返回所请求的 DNS 域名中的二级域名所对应的二级名称服务器地址。
6. 本地名称服务器根据根名称服务器所返回的二级名称服务器地址，向对应的二级名称服务器发送与前面一样的 DNS 域名查询请求。
7. 二级名称服务器在收到 DNS 查询请求后，也是先查询本地的缓存，如果有所请求的 DNS 域名的记录项，则直接把对应的记录项返回给本地名称服务器，然后再由本地名称服务器返回给 DNS 客户端，否则向本地名称服务器返回所请求的 DNS 域名中的三级域名所对应的三级
   名称服务器地址。
8. 就这样本地名称服务器重复步骤 6 和步骤 7 的方法一次次地向三级、四级名称服务器等查询，直到最终的对应域名所在区域的权威名称服务器返回到最终的记录给本地名称服务器。
9. 然后再由本地名称服务器返回给 DNS 客户，同时本地名称服务器会缓存本次查询得到的记录项。
   如果在上述步骤中对应域名的权威名称服务器都说找不到对应的域名记录，则会向 DNS 客户端返回一条查询失败的 DNS 应答报文。当然，如果这个权威名称服务器上配置了指向其它名称服务器的转发器，则权威名称服务器还会在转发器指向的名称服务器上进一步重复上述步骤查询。另外，如果 DNS 客户端上配置了多个 DNS 服务器，则还会继续向其它 DNS 服务器查询的。
   简单的讲，递归查询步骤；
10. 客户端向本机配置的本地名称服务器发出 DNS 域名查询请求，发出请求后客户端一直处于等待状态，等待本地名称服务器返回查询结果。
11. 本地名称服务器收到 DNS 请求后，先查询本地的缓存，查到存在该域名记录项立即返回结果，否则本地名称服务器不断向 DNS 名称服务器发送 DNS 请求查询，直到查到改域名对应的权威名称服务器并获得记录结果。
12. 本地名称服务器 解析到结果后将结果返回给客户端。

• 递归查询过程示例
  

假设客户端访问站点www.example.com ，那么 DNS 客服端的查询过程如下：

1. DNS 客户端 向所配置的本地名称服务器 dns.example.com 发出解析 www.example.com
   域名的 DNS 请求报文
2. 本地名称服务器收到请求后，先查询本地缓存。假设没有查到该域名对应记录，则本地名称服务器向所配置的根名称服务器 a.rootserver.net 发出解析请求解析 www.example.com域名的 DNS 请求报文(相当于对本地名称服务器说:“请给我 www.example.com 所对应的 IP地址”)
3. 根名称服务器收到 客户端的 DNS 查询请求报文后，通过查询得到.com 顶级域名所对应的顶级名称服务器，然后向本地名称服务器返回一条应答报文(相当说“我不知道
   www.example.com 域名所对应的 IP 地址，但我现在告诉你 .com 域名所对应的顶级名称服务器地址”)
4. 本地名称服务器在收到根名称服务器的 DNS 应答报文，得到 .com 顶级域名所对应的顶级名称服务器地址后，再次向对应的顶级名称服务器发送一条请求解析 www.example.com 域名的 DNS 请求报文
5. .com 顶级名称服务器在收到 DNS 请求报文后，先查询本地的缓存，假设也没有该域名的记录项，则查询 example.com 所对应的二级名称服务器，然后也向本地名称服务返回一条 DNS 应答报文(相当于对本地名称服务器说:“我不知道 www.example.com 域名所对应的 IP 地址，但我现在告诉你 example.com 域名所对应的二级名称服务器地址”
6. 本地名称服务器在收到 .com 顶级名称服务器的 DNS 应答报文，得到example.com 二级域名所对应的二级名称服务器地址后，再次向对应的二级名称服务器发送一条请求解析 www.example.com 域名的 DNS 请求报文
7. example.com 二级名称服务器在收到 DNS 请求报文后，也先查询本地的缓存，假设也没有该域名的记录项，则查询 www.example.com 所对应的权威名称服务器，然后也向本地名称服务器返回一条 DNS 应答报文(相当于本地名称服务器说：“我不知道 www.example.com 域名所对应的 IP 地址，但我现在告诉你 www.example.com 域名所对应的权威名称服务器地址”)
8. 本地名称服务器在收到 example.com 二级名称服务器的 DNS 应答报文，得到 www.example.com 三级域名所对应的权威名称服务器地址后，再次向对应的权威名称服务器发送一条请求解析 www.example.com 域名的 DNS 请求报文
9. www.example.com 权威名称服务器在收到 DNS 请求后，在它的 DNS 区域数据库中查找，最终得出了www.example.com 域名所对应的 IP 地址。然后向本地名称服务器返回到一条 DNS 应答报文(相当于对本地名称服务器说：“ www.example.com 域名的 IP 地址为xxx.xxx.xxx.xxx”)
10. 本地名称服务器在收到权威名称服务器的应答报文后，向 DNS 客户端返回一条DNS 应答报文，告诉 DNS 客户端所得到的www.example.com 域名的 IP 地址。这样 DNS 客户端就可以正常访问这个网站了

DNS 资源记录

DNS 也是一个存储网络主机和资源目录的分层命名系统。 目录中的信息将网络名称映射到不同资源记录
DNS区域中的DNS resource record (RR-DNS资源记录)条目指定有关区域中特定名称或对象的信息。 资源记录格式如下：

owner-name             TTL    class    type    data
server.test.cloud.     300    IN       A       192.168.1.10

名称	内容
owner-name（所有人名称）	该资源记录对应的名称。
生存时间/TTL	资源记录的生存时间，单位为秒；表示 DNS 解析器应将该记录缓存多久。
类/class	记录的类别，几乎恒为 IN（Internet，互联网）。
类型/type	本记录所承载的信息类别。例如，A 记录将主机名映射到 IPv4 地址。
数据/data	本记录存储的数据；具体格式随记录类型而变。

主机名Name (Owner)该记录所属的域名（例如 [www.example.com](https://www.example.com)）
生存时间TTL (Time to Live)记录在缓存中保留的秒数。超过此时间后，递归服务器必须删除旧记录并重新查询。
类Class协议族。该值几乎永远是 IN (Internet)。
类型Type定义该记录的功能（是 IP 地址、别名还是邮件服务器）
数据RDATA具体的记录内容。其格式取决于 Type 字段（例如 IP 地址或域名）。

A 资源记录

最基础的记录，将域名（如test.com）映射到IPv4地址（如172.25.254.254） 浏览器访问网站时主要靠它解析IP
A 资源记录将主机名映射到IPv4地址

server.test.cloud. 86400 IN A 172.25.254.254

AAAA 资源记录（4A记录）

A记录的IPv6版本，将域名映射到IPv6地址

a.root-servers.net. 604800 IN AAAA 2001:503:ba3e::2:30

CNAME 资源记录

CNAME资源记录将一个名称别名为另一个名称（规范名称），不能指向IP，该名称应具有A或AAAA记录
当DNS解析程序收到对查询的CNAME记录时，它将使用规范名称而不是原始名称重新发出查询
CNAME记录的数据字段可以指向DNS中任何区域的名称，无论该区域是内部的还是外部的：

www-dev.test.cloud.     30 IN CNAME lab.test.cloud.
server.test.cloud.      30 IN CNAME www.redhat.com.

CNAME记录可能指向具有CNAME的名称，但CNAME记录链最终必须解析为A或AAAA记录的名称
通常，避免将CNAME记录指向其他CNAME记录。 CNAME会使查找效率降低，更脆弱，并且我们可能会意外地创建一个指向彼此的CNAME记录循环
CNAME记录链有合法用途。 例如，它们与Content Delivery Network（CDN）结合使用
NS和MX记录不得指向带有CNAME记录的名称，而是使用带有A和/或AAAA资源记录的名称

PTR 资源记录

反向解析记录将IP地址映射回域名。用于反向DNS查询（如邮件服务器验证来源IP）以一种类似于主机名的特殊格式对IP地址进行编码

• 对于IPv4地址，该地址被颠倒，以最具体的部分开始，然后视为in-addr.arpa域的子域中的主机
• 对于IPv6地址，该地址在半字节边界（每个十六进制数字）上划分为子域，并设置为ip6.arpa域的子域

4.0.41.198.in-addr.arpa. 785 IN PTR a.root-servers.net.
0.3.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.3.a.b.3.0.5.0.1.0.0.2.ip6.arpa
. 86400 IN PTR a.root-servers.net.

NS资源记录 - Name Server

指定哪个权威DNS服务器负责该域名的解析
NS或名称服务器资源记录将域名映射到对其DNS区域具有权威性的DNS名称服务器， 该区域的每个公共权威名称服务器都必须具有NS记录

test.cloud. 86400 IN NS dns.test.cloud.
168.192.ip-addr.arpa. 86400 IN NS dns.test.cloud.
9.0.e.1.4.8.4.6.2.e.d.f.ip6.arpa. 86400 IN NS dns.test.cloud.

说明：
其中两个NS记录用于10.1.8.0/16网络和fde2:6484:1e09::/48网络的反向查找
classroom.test.cloud上的区域可能包含NS记录，以将对192.168.254.0/24和fde2:6484:1e09::1:: /64的反向查找委托给另一个名称服务器
NS记录映射的名称必须有A或4A记录

SOA 资源记录 - Start of Authority

起始授权记录（Start of Authority），每个DNS区域（zone）必须有且仅有一个。它包含域名管理员邮箱、序列号、刷新时间等权威信息，是整个区域的“身份证”
指定了一个序列号，指定其他权威性名称服务器用来确定何时从主要名称服务器传输区域资源记录的各种超时时间

test.cloud. 86400 IN SOA dns.test.cloud. root.test.cloud. 2015071700
3600 300 604800 60

值	示例	含义
MNAME	dns.test.cloud.	该名称服务器是这个区域的主要名称服务器，负责维护区域资源记录。
RNAME	root.test.cloud.	该区域中负责人邮件地址，@ 用 . 代替，例如 root@test.cloud.
SERIAL	2015071700	该区域版本号，随着区域中记录更改而增加。
REFRESH	3600	从名称服务器向主名称服务器更新数据频率。单位秒。
RETRY	300	在重试失败的刷新前，应当等待的时间间隔。单位秒。
EXPIRE	604800	如果刷新失败，从服务器在停止其旧的区域副本响应查询之前等待的时间。单位秒。
MINIMUM	60	如果解析器查找某个名称，并且该名称不存在，解析器应将「记录不存在」这一信息缓存的时间。单位秒。

MX 资源记录 - Mail Exchanger

MX资源记录将域名映射到接受该域的电子邮件的邮件交换（mail exchange）。邮件服务器故障时，提供负载平衡和冗余的邮件服务器帮助路由电子邮件
该记录类型的数据是用于确定在多个MX记录之间选择的优先级（首选最低），以及用于该名称的邮件交换的主机名

test.cloud. 86400 IN MX 10 dns.test.cloud.
test.cloud. 86400 IN MX 10 mail.test.cloud.
test.cloud. 86400 IN MX 100 mailbackup.test.cloud.

TXT 资源记录

TXT 资源记录将名称映射到编码为可打印ASCII字符的任意文本。 它们通常用于提供用于各种电子邮件身份验证方案（例如SPF，DKIM和DMARC）的数据，以验证域所有权（例如，用于Google和Facebook），以及用于其他目的

lwn.net. 27272 IN TXT "google-site-verification: sVlx-
S_z1es5DfNSUNXrqr3n9Y4F7tOr7HNVMKUGs"
lwn.net. 27272 IN TXT "v=spf1 a:mail.lwn.net a:prod.lwn.net
a:git.lwn.neta:ms.lwn.net -all"

SRV 资源记录

SRV 资源记录可帮助客户端找到域中支持特定服务的主机
示例：表明存在一个可以使用TCP传输协议（ _tcp ）与LDAP连接的LDAP服务器（ _ldap ），该主机属于域test.cloud。 LDAP服务器是server.test.cloud，正在侦听端口389，优先级为0，权重为100（如果客户端接收到多个SRV记录，则控制选择哪个服务器）

_ldap._tcp.test.cloud. 86400 IN SRV 0 100 389 server0.test.cloud.

主机和资源记录

• ⼀个主机，无论是客户端还是服务器，都具有以下 DNS 资源记录：

⼀个或多个A或AAAA记录
用于将其IP地址反向映射到名称的PTR记录
⼀个或多个CNAME记录（可选）

• DNS zone 还具有以下资源记录：

唯一的 SOA 记录
每个权威名称服务器的 NS 记录
⼀个或多个MX记录（可选）
用于在域中查找服务的⼀个或多个SRV记录（可选）

配置权威名称服务器

权威名称服务器架构

权威名称服务器存储 DNS 资源记录，并为其管理的区域提供权威答案
Linux中的Berkeley Internet Name Domain（BIND）软件可以实现权威的名称服务器。 BIND允
许我们将权威服务器配置为区域的主要服务器或辅助服务器。区域中只有一台主服务器，但可具
有多台辅助服务器。 辅助服务器通过请求区域传输，定期从主服务器下载区域信息的最新版本。
它们执行区域传输的频率以及如何知道其数据是否过时由区域的SOA资源记录控制。
名称服务器可以是某些区域的主要服务器，同时也可以其他区域的辅助服务器

注册新的DNS域时，必须提供该域的所有公共权威名称服务器的名称和IP地址。我们的注册服务
商将该信息放在父域的区域文件中（如NS，A和AAAA记录），以便DNS解析器可以找到我们的名
称服务器。为了帮助确保可靠性，我们应该至少有两个公共DNS服务器，并且它们应位于不同的
站点，以避免由于网络故障而造成的中断

并非所有权威服务器都必须是公共的。例如，使用primary服务器来管理区域文件，并将区域信
息发布到权威的secondary服务器。primary服务器是私有的，而secondary服务器是面向公众
的，从而为外部客户端提供权威性的答案，保护我们的primary服务器免受攻

• 权威名称服务器架构示例1：外部客户端查找 www.exampledomain.com 的过程

该辅助名称服务器在test.cloud域的区域文件中查找www.exampledomain.com的NS记录。 它
使用dns.test.cloud名称服务器进行响应，因此仅缓存名称服务器会查询此名称服务器。
该名称服务器使用www.exampledomain.com的A记录进行响应，因此仅缓存名称服务器可以
回答www.exampledomain.com的IP地址

安装 BIND

通过安装bind软件包来安装BIND。 名称服务器本身作为named服务运行。 bind包将HTML和
PDF格式的BIND文档在安装在/usr/share/doc/bind/目录

[root@server ~]# yum install -y bind bind-utils

• bind，服务器软件包
• bind-utils，客户端软件包

bind软件包默认将服务配置为基本的递归缓存名称服务器。 它被配置为localhost、相关域和地
址的primary服务器，以减轻根名称服务器的负担。 此默认配置还限制了对本地主机上程序的访
问。它侦听IPv4和IPv6环回接口的端口53 UDP/TCP（127.0.0.1和:: 1）上的连接

配置 BIND

named主要配置文件是/etc/named.conf。 该文件控制BIND的基本操作，由root用户（named组）拥有，具有八进制权限0640，并且具有named_conf_t SELinux类型
配置文件还指定了每个区域的配置文件位置，这些文件通常保存在/var/named中
配置DNS服务器需要执行以下步骤：

• 配置地址匹配列表
• 配置named侦听的IP地址
• 配置客户端的访问控制
• 配置zone
• 编写区域文件

定义地址匹配列表

在/etc/named.conf文件的开头，可以使用acl指令定义地址匹配列表。 acl指令不是用于控制客
户端对服务器的访问，而是使用它们来定义IP地址和网络列表。
它们提供别名，可以与访问控制指令和其他配置选项一起使用，并使更新配置文件更加容易。
条目可以是完整的IP地址或网络，用尾点（10.1.8.）或CIDR表示法（192.168.0/24或2001:db8::/32）表示，也可以使用先前定义的地址匹配列表的名称。
请考虑以下ACL定义:

[root@server ~]# vim /etc/named.conf
acl trusted-nets { 192.168.10.0/24; 192.168.20.0/24; };
acl classroom { 10.1.8.0/24; };

在其值中使用classroom的任何指令都将与10.1.8.0/24网络和192.168.1.21中的主机匹配。acl语句定义的地址集可以被多个指令引用。
named中内置了四个预定义的ACL：

ACL	说明
none	不匹配任何主机。
any	匹配所有主机。
localhost	匹配 DNS 服务器自身的所有 IP 地址。
localnets	匹配与 DNS 服务器处于同一本地子网的所有主机。

配置named侦听的IP地址

/etc/named.conf文件options块中可以指定许多全局设置，其中listen-on和listen-on-v6指令可以指定命名监听的接口和端口

• listen-on选项采用以分号分隔的IPv4地址列表。
• listen-on-v6使用IPv6地址

示例：将BIND配置为侦听10.1.8.10 IPv4地址和默认的IPv4环回地址127.0.0.1

[root@server ~]# vim /etc/named.conf
options {
listen-on port 53 { 127.0.0.1; 10.1.8.10; };
......
};

配置说明：

• listen-on port 53 { 127.0.0.1; 10.1.8.10; }; 指定named侦听的IP地址为默认的IPv4环回地址127.0.0.1和10.1.8.10
• … 其他配置

示例：结合acl指令配置

acl interfaces { 127.0.0.1; 10.1.8.10; };
acl interfacesv6 { ::1; 2001:db8:2020::5300; };
options {
listen-on port 53 { interfaces; };
listen-on-v6 port 53 { interfacesv6; };
...output omitted...
};

配置客户端的访问控制

• 我们可以在/etc/named.conf文件options块中使用以下三个指令配置控制访问：
  allow-query，控制所有查询。 默认情况下，allow-query设置为localhost，对于公开权
  威服务器必须定义allow-query { any; }; 允许互联网托管者从他们那里获取信息
• allow-recursion，控制递归查询。 权威服务器不应允许递归查询， 防止服务器被用于DNS
  放大分布式拒绝服务攻击，并更好地保护其免受缓存中毒攻击。
  配置此功能最简单的方法是完全关闭递归

options {
......
recursion no;
......
};

如果必须允许受信任的客户端执行递归，则可以打开递归并为这些特定主机或网络设置
allow-recursion：

options {
......
allow-recursion { trusted-nets; };
......
};

• allow-transfer，控制区域转移(Zone Transfer)。 区域转移允许客户端获取我们区域中所有数据的转储。区域转移应该受到限制，否则攻击者很容易快速获取区域中的所有资源记录。

主服务器必须配置允许转移，以允许辅助服务器执行区域转移。应该禁止其他主机执行区域传输，允许localhost执行区域传输以帮助进行故障排除

可以使用dig命令查询该区域的AXFR(Zone Transfer)记录

dig axfr @10.1.8.10 test.cloud

实验环境采用如下配置：

[root@server ~]# vim /etc/named.conf
......
options {
# 修改listen-on
listen-on port 53 { 127.0.0.1; 10.1.8.10; };
......
# 修改allow-query
allow-query { any; };
};
......

配置 zone

示例：以下named.conf块将服务器配置为承载example.net及其相应的反向查找区域8.1.10.in-addr.arpa的主要区域文件，它使用从ACL标识example.net服务器中检索到的区域文件，充当example.net域的辅助服务器

[root@server ~]# vim /etc/named.conf
......
zone "example.net" {
type master;
file "example.net.zone";
};
......

配置说明：

• type master; 指定该区域为主服务器
• file “example.net.zone”; 指定该区域的数据文件为example.net.zone

创建区域文件

辅助区域文件应保存在/var/named/slaves中。辅助服务器启动时，会将其缓存的区域版本与主服务器上的当前版本进行比较：如果区域文件版本是最新的，则使用该区域文件； 如果区域文件版本不是最新的或文件不存在，则named执行区域传输并将结果缓存在该文件中。
BIND 应该能够读取这些区域文件，但不能写入它们。 这些文件应归root用户和named组所有，以便守护程序在某种程度上受到损害时不能更改它们。

示例：创建example.net区域文件

[root@server ~]# touch /var/named/example.net.zone
[root@server ~]# touch /var/named/10.1.8.zone
[root@server ~]# chmod 640 /var/named/*.zone
[root@server ~]# chown root:named /var/named/*.zone
# 如果系统开启了selinux功能，执行下面命令设置文件标签
[root@server ~]# chcon -t named_zone_t /var/named/*.zone

编辑区域文件格式
BIND区域文件是一个文本文件：

• 每行包含一个指令或资源记录
• 如果资源记录的数据中包含括号，则它可以跨越多行
• 在同一物理行上的分号（;）右侧的所有内容均被注释掉
  区域文件可以以$TTL指令开头，该指令为任何未列出的资源记录设置默认的TTL。 这使我们可以
  一次为许多资源记录调整TTL，无需编辑整个文件，如果TTL是数字，则以秒为单位。

$TTL 3600

在数字后面可以跟单个字母指定其他时间单位：

• M表示分钟（1M为60）
• H表示小时（1H为3600）
• D表示天（1D为86400）
• W表示周（1W为604800）
• Y表示年（1Y为31536000）

每个区域文件仅包含一个SOA（授权开始）资源记录

示例：example.com 域 SOA 资源记录（BIND 区域文件标准写法）

$TTL 3600
example.com. IN SOA  primary.example.com.  root.example.com. (
    42   ; serial（序列号，辅助 DNS 据此判断区文件是否有更新）
    3H   ; refresh（刷新间隔，辅助 DNS 多久向主 DNS 查询一次）
    15M  ; retry（重试间隔，刷新失败后再次尝试前等待的时间）
    1W   ; expire（过期时间，长期无法联系主服务器时，辅助服务器仍可应答的上限）
    15M  ; minimum（否定回答的最小缓存 TTL，如 NXDOMAIN）
)

1. 定义区域的名称（在此示例中为example.com），后跟IN SOA ，标识记录的类别和类型（互联网SOA记录）
2. 此区域的主要名称服务器primary.example.com 的名称。
3. 该区域负责方的联系电子邮件地址。地址中的第一个点（.）被视为@ 即root.example.com. 代表 root@example.com.
4. 代表文件修订的序列号。 每次文件更改时，必须手动增加序列号值
5. 辅助服务器应多久查询一次主服务器，以查看是否需要刷新区域
6. 如果辅助务器刷新失败，则应尝试尝试重新连接的频率
7. 在放弃之前，辅助服务器应尝试重新连接到无响应的主要服务器的时间。发生这种情况时，辅助服务器将假定该区域不再存在，并停止回答该区域的查询
8. 其他名称服务器缓存来自该区域的NXDOMAIN记录的时间

添加记录

正向记录，将名称映射到IP地址和其他记录。该区域文件必须具有：

1. SOA记录
2. 每个公用名称服务器的NS记录
3. 该区域的其他A，AAAA，CNAME，MX，SRV和TXT记录
   示例：example.com域的A记录

$TTL 3600
@ IN SOA dns.example.com. root.example.com. (
42 ; serial
3H ; secondary refresh
15M ; secondary retry
1W ; secondary timeout
15M ; minimum cache TTL for negative answers
)
        IN NS dns.example.com.
dns     IN A 10.1.8.10
server  IN A 10.1.8.10
student IN CNAME client.example.com.
client  IN A 10.1.8.11
www  30 IN A 10.1.8.200
@       IN MX 10 mail.example.com.
mail    IN A 10.1.8.253

记录说明：

• @字符代表区域的名称，避免重复键入，并且在某些情况下允许重复使用
• 区域文件中的SOA记录与前面的示例中的SOA记录是等效的。
• 如果记录的名称为空，则其值与前面的记录相同。
  因此，在前面的示例中：
• 第一个记录是example.com.的SOA记录
• 第二个记录是example.com.的NS记录
• 第三个记录是dns.example.com.的A记录
• 第四个记录是server.example.com.的A记录
• 第五个记录是student.example.com.的CNAME记录
• 第六个记录是client.example.com.的A记录
• 第七个记录是www.example.com.的A记录
• 第八个记录是mail.example.com.的MX记录
• 第九个记录是mail.example.com.的A记录

任何不以点号结尾的名称均被视为部分主机名，应将区域名称添加为完全合格的域名。换句话说，server等效于server.example.com.
反向记录，将IP地址映射到主机名。该区域文件必须具有：

1. SOA记录
2. NS记录
3. PTR记录

示例：8.1.10.inaddr.arpa区域

[root@server ~]# vim /var/named/10.1.8.zone

$TTL 3600
@ IN SOA dns.example.com. root.example.com. (
42 ; serial
3H ; secondary refresh
15M ; secondary retry
1W ; secondary timeout
15M ; minimum cache TTL for negative answers
)
        IN NS dns.example.com.
10      IN PTR server.example.com.
10      IN PTR dns.example.com.
11      IN PTR client.example.com.
11      IN PTR student.example.com.
200     IN PTR www.example.com.
253     IN PTR mail.example.com.

IP地址的“名称”不需要包括其余的域名，1代替1.8.1.10.in-addr.arpa.

委派子域

• 将子域条目配置在父域

servera.lab IN A 10.1.8.150
serverb.lab IN A 10.1.8.151

• 委派子域给其他名称服务器

将support.example.com.子域委派给 ns1.support.example.com. 和 ns2.support.example.com.

support IN NS ns1.support.example.com.
        IN NS ns2.support.example.com.

如果这些名称服务器的名称本身不在 support.example.com 域中，必须在父域 example.com 中为每个子域的名称服务器添加glue/粘合记录（A或AAAA资源记录）：

ns1.support.example.com. IN A 192.100.100.10
ns2.support.example.com. IN A 192.100.100.11

验证配置

在重新加载或重新启动named之前，应该验证/etc/named.conf文件和区域文件的语法

• named-checkconf，验证 /etc/named.conf

[root@server ~]# named-checkconf
# 如果配置文件不在默认位置，使用一下命令命令验证
[root@server ~]# named-checkconf /media/backups/named.conf

• named-checkzone zone zone-file，通过zone-file验证zone

[root@server ~]# named-checkzone example.com
/var/named/example.com.zone
zone example.com/IN: loaded serial 42
OK

启动服务器时，应监视系统日志中是否有错误。 单个错误也可能会导致整个区域无法加载，但是无法加载区域不会阻止后台驻留程序启动。因此除非我们在启动过程中监视系统日志，否则很难弄清楚哪里错了

[root@server ~]# journalctl -f _SYSTEMD_UNIT=named.service

注意区域行，每个区域代表服务器加载的权威区域。 如果无法加载区域，请注意显示的错误消息
确认区域正确加载后，请验证区域内容是否正确。使用host -l DOMAIN 或dig -t AXFR DOMAIN 命令启动区域传输，生成所有区域记录的列表。 请记住，这必须在服务器的 allowtransfer 指令中列出的主机上完成。

运行 BIND

# 启用并启动服务
[root@server ~]# systemctl enable named --now
[root@server ~]# systemctl status named
# 设置防火墙
[root@server ~]# firewall-cmd --add-service=dns
[root@server ~]# firewall-cmd --add-service=dns --permanent

客户端测试

# 配置客户端 dns
[root@client ~]# nmcli connection modify ens32 ipv4.dns 10.1.8.10
[root@client ~]# nmcli connection up ens32
# ping 工具测试
[root@client ~]# ping student.example.com
[root@client ~]# ping dns.example.com
# 其他工具
[root@client ~]# host student
student.example.com is an alias for client.example.com.
client.example.com has address 10.1.8.11
[root@client ~]# getent hosts student
10.1.8.11 client.example.com student.example.com