DNS 服务器

DNS 服务器

DNS 服务介绍

DNS 服务介绍

DNS（Domain Name System，域名系统）服务是一种用于将域名转换为IP地址的分布式数据库服务。它是互联网的核心服务之一，使得用户能够通过易于记忆的域名来访问网站和其他网络服务，而无需记住复杂的IP地址。

DNS 也是一个存储网络主机和资源目录的分层命名系统。 目录中的信息将网络名称映射到不同资源记录。

• 根域：DNS层次结构最顶层，使用独立的"."表示。
• 顶级域（一级域）：DNS层次结构第二层，例如**.com**，.net和**.org**等域。
• 二级域：DNS层次结构第三层，例如 **shizhan88.cloud **和 redhat.fun 等域。由各个组织使用。
• 以此类推。

学习DNS层次结构前，首先要搞清楚DNS层次结构中一些术语，例如domain，subdomain和zone等。

Domain

domain 是 resource records 的集合，该集合以通⽤名结尾，表示 DNS 命名空间的整个⼦树，如 shizhan88.cloud。

top-level domain （TLD- 顶级域）由 Internet Assigned Numbers Authority（IANA-互联网号码分配机构）管理，并负责委派顶级域。

常见的TLD类型：

• Generic TLDs（gTLD-通用顶级域名），最初是按主题组织的，包括.com，.edu和.net等。
• Country code TLDs（ccTLD-国家代码顶级域名），根据ISO 3166-1标准在国家范围上组织的，并包括.us，.uk，.cn和.ru之类的域。

其他顶级域参考顶级域名参考[根域数据库][https://www.iana.org/domains/root/db\]。

Subdomain

Subdomain 是另一个域的完整子树的域。 在讨论两个域之间的关系时使用此术语。 例如，lab.shizhan88.cloud 是shizhan88.cloud 的子域，而shizhan88.cloud 是**.com的子域。 我们也可以将 shizhan88.cloud称为第二级域，并将lab.shizhan88.cloud**称为第三级域。

Zone

Zone 是特定名称服务器直接负责的域。 它可能是整个域，也可能只是域的一部分。Zone可以将部分或全部子域都委派给另一个名称服务器或多个名称服务器。

例如，root名称服务器对root zone具有权威性，但它们将.com域的职责委派给其他名称服务器，这些名称服务器为.com区域提供权威性应答。 这些服务器还可以继续将责任委派给其他名称服务器。

DNS 查询

主机的 DNS 查询主要有两种方式：递归查询 和迭代查询。

DNS 查询时，DNS 请求报头部的 RD 字段决定了查询类型：

• RD 为 1 => 递归查询 ，默认查询方式。
• RD 为 0 => 迭代查询。

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

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

有些DNS服务器，为了减轻自己的负载，则会配置禁止使用递归查询，则客户端只能使用递归查询。

两者主要区别：

• 递归查询 以 本地名称服务器 为中心进行查询
• 迭代查询 以 DNS客户端自己 为中心查询。

迭代查询

**迭代查询，也叫迭代解析。**使用迭代解析方式时，**所有的查询工作都是由 DNS 客户自己进行的。**如果它所配置的主名称服务器（如 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 客户端。
7. DNS 客户端继续按照步骤 5 与步骤 6 的方法分别向三级、四级名称服务器查询，直到查到最终的权威名称服务器返回到最终的记录。

如果在上述步骤中对应域名的权威名称服务器都说找不到对应的域名记录，则会向 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 请求报文。
10. 权威名称服务器 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 服务器查询的。

简单的讲，递归查询步骤；

1. 客户端向本机配置的本地名称服务器发出 DNS 域名查询请求，发出请求后客户端一直处于等待状态，等待本地名称服务器返回查询结果。
2. 本地名称服务器收到 DNS 请求后，先查询本地的缓存，查到存在该域名记录项立即返回结果，否则本地名称服务器不断向 DNS 名称服务器发送 DNS 请求查询，直到查到改域名对应的权威名称服务器并获得记录结果。
3. 本地名称服务器 解析到结果后将结果返回给 客户端。

递归查询-示例

假设客户端访问站点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 resource record (RR-DNS资源记录)条目指定有关区域中特定名称或对象的信息。 资源记录格式如下：

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

记录说明：

Field name	Content
owner-name	The name for this resource record.
TTL	The Time To Live of the resource record in seconds. This specifies how long this resource record should be cached by DNS resolvers.
class	The "class" of the record, almost always IN ("internet").
type	The type of information stored by this record. For example, an A record maps a host name to an IPv4 address.
data	The data stored by this record. The exact format varies by record type.

A 资源记录

A 资源记录将主机名映射到IPv4地址。

server.shizhan88.cloud. 	86400 IN A 172.25.254.254

AAAA 资源记录

AAAA资源记录（4A记录）将主机名映射到IPv6地址。

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

CNAME 资源记录

CNAME资源记录将一个名称别名为另一个名称（规范名称），该名称应具有A或AAAA记录。

当DNS解析程序收到对查询的CNAME记录时，它将使用规范名称而不是原始名称重新发出查询。

CNAME记录的数据字段可以指向DNS中任何区域的名称，无论该区域是内部的还是外部的：

www-dev.shizhan88.cloud. 	30 IN CNAME lab.shizhan88.cloud.
server.shizhan88.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 资源记录

PTR或pointer资源记录将IPv4或IPv6地址映射到主机名。 它们用于反向DNS解析。

PTR记录以一种类似于主机名的特殊格式对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.

该语法可能看起来很奇怪，但是它简化了将地址范围的责任委托给其他DNS管理员的情况。

NS 资源记录

NS或名称服务器资源记录将域名映射到对其DNS区域具有权威性的DNS名称服务器。 该区域的每个公共权威名称服务器都必须具有NS记录。

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

说明：

• 其中两个NS记录用于10.1.8.0/16 网络和fde2:6484:1e09::/48网络的反向查找。
• classroom.shizhan88.cloud上的区域可能包含NS记录，以将对192.168.254.0/24和fde2:6484:1e09::1:: /64的反向查找委托给另一个名称服务器。

NS记录映射的名称必须有A或4A记录。

SOA 资源记录

SOA资源记录，也叫做起始授权机构记录，提供有关DNS区域如何运行的信息。 每个区域必须有一个SOA记录。

• 指定了一个序列号
• 指定其他权威性名称服务器用来确定何时从主要名称服务器传输区域资源记录的各种超时时间。

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

记录值说明：

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

MX 资源记录

MX资源记录将域名映射到接受该域的电子邮件的邮件交换（mail exchange）。邮件服务器故障时，提供负载平衡和冗余的邮件服务器帮助路由电子邮件。

该记录类型的数据是用于确定在多个MX记录之间选择的优先级（首选最低），以及用于该名称的邮件交换的主机名。

shizhan88.cloud. 86400 IN MX 10 dns.shizhan88.cloud.
shizhan88.cloud. 86400 IN MX 10 mail.shizhan88.cloud.
shizhan88.cloud. 86400 IN MX 100 mailbackup.shizhan88.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），该主机属于域shizhan88.cloud。 LDAP服务器是server.shizhan88.cloud，正在侦听端口389，优先级为0，权重为100（如果客户端接收到多个SRV记录，则控制选择哪个服务器）。

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

主机和资源记录

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

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

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

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

配置权威名称服务器

权威名称服务器架构

权威名称服务器存储 DNS 资源记录，并为其管理的区域提供权威答案。

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

名称服务器可以是某些区域的主要服务器，同时也可以其他区域的辅助服务器。

当前BIND服务器角色为master 和slave ，以后会变更为primary 和secondary（例如，BIND 9.16 ESV版本）。

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

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

安装 BIND

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

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

软件包说明：

• bind，服务器软件包。
• bind-utils，bind 工具软件包。

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	Description
none	Matches no hosts.
any	Matches all hosts.
localhost	Matches all IP addresses of the DNS server.
localnets	Matches all hosts from the DNS server's local subnets.

配置 named 侦听的IP地址

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

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

示例1：将BIND配置为侦听10.1.8.10 IPv4地址和默认的IPv4回送地址。

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

示例2：结合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 {
          ......
          recursion yes;
          allow-recursion { trusted-nets; };
          ......
  };

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

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

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

  [user@host ~]$ dig axfr @classroom.shizhan88.cloud shizhan88.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块将服务器配置为承载shizhan88.cloud 及其相应的反向查找区域8.1.10.in-addr.arpa 的主要区域文件。 它使用从ACL标识example.net服务器中检索到的区域文件，充当example.net域的辅助服务器。

[root@server ~]# vim /etc/named.conf
......
# 最后添加如下内容
zone "shizhan88.cloud" IN {
        type master;
        file "shizhan88.cloud.zone";
};

zone "8.1.10.in-addr.arpa" IN {
        type master;
        file "10.1.8.zone";
};

配置说明：

• type，指定服务器角色。
• file ，指定相对路径名。 相对路径由 options 块中的 directory 指令设置。

创建区域文件

辅助区域文件应保存在/var/named/slaves中。辅助服务器启动时，会将其缓存的区域版本与主服务器上的当前版本进行比较：如果区域文件版本是最新的，则使用该区域文件； 如果区域文件版本不是最新的或文件不存在，则named执行区域传输并将结果缓存在该文件中。

BIND 应该能够读取这些区域文件，但不能写入它们。 这些文件应归root 用户和named组所有，以便守护程序在某种程度上受到损害时不能更改它们。

[root@server ~]# touch /var/named/shizhan88.cloud.zone /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）

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

示例：example.com域SOA资源记录

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

添加记录

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

• SOA记录。
• 每个公用名称服务器的NS记录。
• 该区域的其他A，AAAA，CNAME，MX，SRV和TXT记录。

示例：shizhan88.cloud域

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

$TTL 1D
@       IN SOA  dns.shizhan88.cloud. admin.shizhan88.cloud. (
                                2025112001      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      dns.shizhan88.cloud.
        MX   10 mail1.shizhan88.cloud.
        MX   10 mail2.shizhan88.cloud.
dns     A       10.1.8.10
www     CNAME   server.shizhan88.cloud.
server  A       10.1.8.10
client  A       10.1.8.11
mail1   A       10.1.8.101
mail2   A       10.1.8.102

示例说明：

• @字符代表区域的名称，避免重复键入，并且在某些情况下允许重复使用。
• 区域文件中的SOA记录与前面的示例中的SOA记录是等效的。
• 如果记录的名称为空，则其值与前面的记录相同。

因此，在前面的示例中：

• 第一个记录是shizhan88.cloud.的SOA记录
• 接下来的记录是shizhan88.cloud.的NS记录
• 然后有一个dns的A记录。
• 然后有一个server的A记录。
• 然后有一个www的CNAME记录。
• 然后有一个client的A记录。
• 然后有一个域的MX记录。
• 然后有一个mail的A记录。

任何不以点号结尾的名称均被视为部分主机名，应将区域名称添加为完全合格的域名。 换句话说，server等效于server.shizhan88.cloud.。

反向记录，将IP地址映射到主机名。该区域文件必须具有：

• SOA记录
• NS记录
• PTR记录。

示例：8.1.10.inaddr.arpa区域

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

$TTL 1D
@       IN SOA  dns.shizhan88.cloud. admin.shizhan88.cloud. (
                                2025112001      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      dns.shizhan88.cloud.
10      PTR     dns.shizhan88.cloud.
        PTR     www.shizhan88.cloud.
        PTR     sever.shizhan88.cloud.
11      PTR     client.shizhan88.cloud.
101     PTR     mail1.shizhan88.cloud.
102     PTR     mail2.shizhan88.cloud.

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.shizhan88.cloud.子域委派给ns1.support.shizhan88.cloud.和ns2.support.shizhan88.cloud.。

  support IN NS ns1.support.shizhan88.cloud.
          IN NS ns2.support.shizhan88.cloud.

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

  ns1.support.shizhan88.cloud. IN A 192.100.100.10
  ns2.support.shizhan88.cloud. 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 shizhan88.cloud /var/named/shizhan88.cloud.zone 
  zone shizhan88.cloud/IN: loaded serial 42
  OK

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

例如，我们可以查看与named.service 单位文件有关的systemd的日志输出：

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

注意区域行，每个区域代表服务器加载的权威区域。 如果无法加载区域，请注意显示的错误消息。

确认区域正确加载后，请验证区域内容是否正确。使用host -l DOMAIN或dig -t AXFR DOMAIN命令启动区域传输，生成所有区域记录的列表。 请记住，这必须在服务器的allow-transfer指令中列出的主机上完成。

运行 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

客户端测试

方式1：配置dns

# 配置客户端 dns
[root@client ~]# nmcli connection modify ens32 ipv4.dns 10.1.8.10
[root@client ~]# nmcli connection up ens32

# ping 工具测试
[root@client ~]# ping www.shizhan88.cloud
[root@client ~]# ping dns.shizhan88.cloud

# 其他工具
[root@client ~]# host student
www.shizhan88.cloud is an alias for client.shizhan88.cloud.
client.shizhan88.cloud has address 10.1.8.11

[root@client ~]# getent hosts student
10.1.8.11       client.shizhan88.cloud www.shizhan88.cloud

方式2：dig工具

# dig工具测试
[root@client ~]# yum install -y bind-utils
# 查询相关记录，@10.1.8.10指定向10.1.8.10服务器查询记录
# 查询NS记录 
[root@client ~]# dig @10.1.8.10 shizhan88.cloud NS
# 查询MX记录 
[root@client ~]# dig @10.1.8.10 shizhan88.cloud MX
# 查询A记录 
[root@client ~]# dig @10.1.8.10 www.shizhan88.cloud
# 查询PTR记录
[root@client ~]# dig @10.1.8.10 -x 10.1.8.101