Chapter5 - 管理服务器的DNS

Change Lee2023年5月19日...大约 27 分钟

DNS 概念

域名系统

域名系统（DNS）是一个层次命令系统，充当联网主机和资源的目录。目录中的信息将网网络名称映射到数据，并且在称为资源记录的逻辑条目中维护。DNS层次结构的顶部和分支以 root域“.”开始，向下直至多个下一级别域。

DNS 层次结构的每个级别在域名中以 “.”来描述，并使用“.”表示顶级。com 、net 和 org 之类的域占据层次结构的第二级。example.com 和 redhat.com 之类的域占据第三级，以此类推。

使用DNS 时，务必分清楚一些用于指示DNS 层次结构的常见术语。如 domain,shubdomain 和 zone .

域

域是资源记录的集合，这些资源记录以公用名称结尾并且表示 DNS 名称空间的整个子树，如 example.com 。最大的可能域是 root域 "."，这包括整个DNS名称空间。

顶级域（TLD）是仅有一个组成部分的域。通用 TLD（gTLD）最初按主题组织，并包括 .com 、.edu 、.net等等。国家/地区代码 TLD （ccTLD）根据国家来组织，并且包括 .us、.uk、.cn、.ru等等

子域

子域是指作为另一个域的子树的域。在讨论两个域之间的相互关系时使用该术语。例如 lab.example.com 是 example.com 的子域。

区域

区域是指特定名称服务器直接负责或对其具有权威的某个域组成部分。这可以是整个域，或者只是域的一部分（其部分或所有子域被委派给其他名称服务器）

DNS 查询分析

系统需要使用 DNS 服务器执行名称解析时，它将首先向/etc/resolv.conf 中列出的服务器依次发送查询，直到它获得响应或查询了全部列出的服务器。host 或 dig 命令用于手动查询 DNS名称。

本地权威数据

当查询到达 DNS 服务器时，服务器首先确定正在查询的信息是否驻留在服务器对其有权威的区域中。如果服务器是所查询名称或地址所属区域的权威，那么服务器将以其本地区域文件中包含的信息来响应客户端。这种类型的响应称为权威答案（aa），因为提供响应的服务器对提供的数据有权威。来自名称服务器的权威答案在 DNS响应的标题中开启了 aa标志。

本地的缓存非授权数据

如果DNS 服务器不是相关记录的权威，但是最近又获得了该记录以回答之前的查询，那么它仍可能在其缓存中具有一份记录副本。缓存是用于在指定时间内存储查询答案的位置，这一时间是由每个资源记录响应中称为生存时间（TTL）的值来确定的。如果服务器的缓存中存在答案，则会将该答案提供给客户端。此答案将不会设置 aa 标志，因为服务器对提供的数据没有权威。

通过递归获取的远程非权威数据

如果DNS服务器对于正在查询的名称没有权威，则DNS 服务器不会在其缓存中占有记录，DNS服务器随后将尝试通过称为递归的迭代过程来检索记录。具有空缓存的DNS服务器将按照从其本地预填充根hints 文件中检索的ip 地址查询中中一个根名称服务器，从而开始递归过程。根名称服务器随后可能将以引用响应，这表明名称服务器对于包含所查询的名称的TLD 具有权威。

在收到引用后，DNS服务器随后将对作为引用的TLD 权威名称服务器执行另一个迭代查询。根据正在查询的名称中是否有更多剩余委派，该权威名称服务器将发送权威答案或者另一个引用。此操作将继续，直到到达权威服务器且权威服务器使用权威答案做出响应。

最终答案以及在最终答案之前获得的所有中间答案都将由DNS 服务器进行缓存以提高性能。如果在查询 www.example.com 期间，DNS 服务器发现 example.com 区域具有权威名称服务器，则它将针对任何将来查询直接查询这些服务器以获取 example.com 区域中的信息，而不是在根名称服务器中重新启动递归。

DNS 资源记录

DNS 资源记录(RR)是DNS 区域中的条目，用于指定有关该区域中某个特定名称或对象的信息。一个资源记录包含以下元素：type,TTL ,class 和 data 并且按以下格式组织：

owner-name        TTL    class    type    data
www.example.com    300    IN        A    192.168.1.10

资源记录字段

字段名称	内容
owner-name	该资源记录的名称
TTL	资源记录的生存时间（秒），这会指定 DNS 解析器应缓存此资源记录的时间长度
class	记录的“类”，几乎总是 IN（表示 Internet）
type	类型表示此记录存储的信息的排序。例如， A记录将主机名映射到 IPV4 地址
data	此记录存储的数据。确切模式根据记录类型而不同。

有几个重要的资源记录类型：

A(IPv4地址)记录

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

AAAA (IPv6 地址)

AAAA 资源记录（“四 A”记录）将主机名称映射到 IPv6 地址

CNAME(规范名称)记录

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

当 DNS 解析器收到CNAME 记录作为查询的响应时，DNS 解析器将使用规范名称（而非原始名称）重新发出查询。

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

CNAME 记录很有用，但在使用时应小心，通常，出于效率和脆弱性的原因，应避免将 CNAME 记录指向其他 CNMAE 记录，从而也可以避免意外创建CNAME 循环。CNAME 记录链必须以 A 和 / 或 AAAA 记录结束。请注意，当使用内容传输网络（CDN ）提高通过Internet 传输数据的速度和可靠性时可以合法使用 CNAME 链。同样地。 NS 和 MX 记录不得指向CNAME 记录，而是指向名称包含 A 和/或 AAAA 记录的名称。

PTR （指针）记录

PTR 记录将 ipv4 或 ipv6 地址映射到主机名。它们用于反向 DNS 解析。

PTR 记录以特殊格式对行为类似于主机名的 IP地址进行编码。对于 ipv4 地址，地址被逆向，最具体的部分在最前面。并且结果被视为特殊域 in-addr.arpa 的子域中的主机。对于 ipv6 地址，地址分割为半字节边界上的子域（每个十六进制数），并且设置为特殊域ip6.arpa的子域，如以下示例所示。尽管此语法可能看上去很奇怪，但这更便于DNS 管理员将地址范围的职责委派给其他DNS 管理员。

SOA (授权起始)记录

SOA 记录提供了有关 DNS 区域工作方式的信息。

每个区域正好有一个 SOA 记录。其指定区域的哪个名称服务器的主要名称服务器（主）、有关次要（从）名称服务器应如何更新其信息副本的信息以及区域的管理联系方式。其数据字段包含以下元素：

SOA 记录数据元素

数据元素	内容
Master nameserver	名称服务器的主机名，该名称服务器是域信息的原始来源，并且可能会接受动态DNS 更新（如果区域支持）
RNAME	DNS 区域负责人的电子邮件地址（hostmaster）。电子邮件地址中的 @ 将替换为 RNAME中的 “.”。例如电子邮件地址 hostmaster@example.com写为 hostmaster.example.com
Serial number	区域的版本号，随着对区域记录的任何更改而增加。
Refresh	从服务器应检查区域更新的频率（以秒为单位）
Retry	从服务器在重试失败的刷新之前应等待的时间（以秒为单位）
Expiry	如果刷新失败，从服务器在停止使用其旧的区域副本响应查询之前应等待的时间（以秒为单位）
Minimum	如果解析器查找某个名称并且该名称不存在（获得不存在的域 (NXDOMAIN)响应），解析器应将“记录不存在”这一信息进行缓存的持续时间（以秒为单位）。

MX(邮件交换)记录

MX 记录将域名映射到邮件交换，后者将接受该名称的电子邮件。

此记录类型的数据是一个优先级编号（最低优先级）（用于确定在多个MX 记录之间进行选取时的顺序）以及一个用于该名称的邮件交换的主机名。

TXT （文本）记录

TXT 记录用于将名称映射到任何人类可读的文本

TXT 记录通常用于提供由发送方策略框架（SPF）、域密钥识别邮件（DKIM）、基于域的消息身份验证、报告和一致性（DMARC) 等等使用的数据。

SRV(服务）记录

SRV 记录用于查找支持域的特定服务的主机。

使用格式设置为包含服务和协议名称的域名，如 _service.Protocol.domainname,SRV 记录可提供为域提供服务的主机的名称以及服务侦听的端口号。SRV记录还包括 priority 和 weight 值，以指示在多个主机可用于某一特定服务时应该使用主机的顺序。

此SRV 记录示例表明，server0.example.com 域在主机 server0.example.com 上的端口 389 使用TCP 来提供LDAP 服务，且优先级为 0 ,权重为 100 .

主机和资源记录

一个典型主机，无论是客户端还是服务器，都将具有以下记录：

一个或多个 A 和/或 AAAA 记录，用于将其主机名映射到其IP 地址
其每个 IP 地址都有一个PTR 记录，用于将 IP 地址逆向映射到其主机名
（可选）一个或多个 CNAME 记录 ,用于将备用名称映射到其规范主机名

除了区域中主机的记录之外，DNS 区域通常还具有以下内容：

正好一个SOA 记录，用于指定区域的工作方式
其每个权威名称服务器的 NS记录
一个或多个 MX 记录，用于将域名映射到邮件交换，后者接收以域名结尾的地址的电子邮件。
（可选）各种功能（如 SPF 或 Google 地点验证）的一个或多个 TXT 记录
（可选）用于在域中查找服务的一个或多个 SRV 记录。

用途	资源记录类型
包含区域的权威信息，如电子邮件联系人以及用于配置主、从DNS 服务器之间的交互信息	SOA
将主机名映射到 IPv4	A
识别区域的权威名称服务器	NS
用于发布域的网络服务器位置	SRV
标识负责接受域的电子邮件的邮件交换	MX
将主机名映射到 IPv6	AAAA
启用 ip 地址到主机名的逆向 DNS 查询	PTR
将某个名称别名化为规范名称	CNAME
用于发布任意人类可读的文本。通常用于 SPF 、 DKIM 和 DMRC	TXT

配置缓存名称服务器

缓存名称服务器和 DNSSEC

缓存名称服务器

缓存名称服务器在本地缓存中存储 DNS 查询结果，并且在 TTL 到期后从缓存中删除资源记录。通常设置缓存名称服务器以代表本地网络上的客户端执行查询。这降低了 Internet 上的 DNS 流量，从而极大提高了 DNS 名称解析的效率。随着缓存的增加，缓存名称服务器从其本地缓存中回答越来越多的客户端查询，从而提高DNS 性能。

DNSSEC 验证

鉴于 UDP 的无状态性质，DNS 事务很容易被欺骗和篡改。缓存名称服务器过去一直是期望重定向或支持网络流量的攻击者青睐的目标。这通常通过以下方式来实现：利用DNS 服务器软件中的漏洞来欺骗 DNS 服务器接受恶意数据并将其填充到缓存中，也就是通常称为缓存中毒的方法。一旦攻击者成功使用 DNS 服务器的缓存中毒，便可利用 DNS 服务器上的缓存名称服务有效破坏众多客户端收到的 DNS 数据，并因此可以重定向或支持客户端的网络流量。

缓存名称服务器可以极大提高本地网络上的DNS 性能，同时它们还可以通过执行域名系统安全特性扩展（DNSSEC）验证来提高安全性。在缓存名称服务器上启用的 DNSSEC 验证可在资源记录置于缓存中供客户端使用之前验证资源记录的真实性和完整性，从而防止客户端遭受缓存中毒。

将unbound 作为缓存名称服务器进行配置和管理

有若干软件包可用于配置缓存名称服务器，包括 bind、dnsmasq 和 unbound 。在本示例中，启用了 DNSSEC 验证的情况下将 unbound 作为安全缓存名称服务器进行配置和管理

配置unbound

将 unbound 配置为安全缓存名称服务器

1、安装 unbound

以 root 用户安装 unbound 软件包

[root@server0 ~]# yum install -y unbound

2、启动并启用 unbound.service

[root@server0 ~]# systemctl start unbound
[root@server0 ~]# systemctl enable unbound
ln -s '/usr/lib/systemd/system/unbound.service' '/etc/systemd/system/multi-user.target.wants/unbound.service'
[root@server0 ~]#

3、配置要侦听的网络接口。

默认情况下，unbound 仅侦听 localhost 网络接口。要使umbound 能够作为缓存名称服务器供远程客户端使用，请使用 /etc/unbound/unbound.conf 的server 子句中的 interface 选项来指定要侦听的网络接口。值 0.0.0.0 会将 unbound 配置为侦听所有网络接口：

4、配置客户端访问权限

默认情况下，unbound 会拒绝来自所有客户端的递归查询。在 /etc/unbound/unbound.conf 的server 子句中，使用 access-control 选项指定允许哪些客户端进行递归查询。

5、配置转发

在 /etc/unbound/unbound.conf 中，创建 forward-zone 子句以指定要将查询转发到的 DNS 服务器。可以使用 forward-host 选项按主机名指定 DNS 服务器，或者使用 forward-addr 选项按 ip 地址指定。对于缓存名称服务器，通过将 forward-zone 指定为 “." 以转发所有查询。

6、如果需要，可对特定的未签名区域绕过 DNSSEC 验证。

默认情况下，启用 unbound 以执行 DNSSEC 验证，以验证是否收到了所有DNS 响应。

/etc/unbound/unbound.conf 的 server 子句中的 domain-insecure选项可用于指定应跳过 DNSSEC 验证的域。这在处理未签名的内部域时通常是需要的。否则会导致信任链验证失败。

7、如果需要，请安装特定签名区域的信任定位符（不含完整信任链）

由于并非所有 ccTLD 都实现了 DNSSEC ,这些 ccTLD 的子域可以由DNSSEC 签名，但是仍具有损坏的信息链。可以使用 /etc/unbound/unbound.conf 的 server 子句中的 trust-anchor 选项指定区域的信任定位符，从而解决此问题。使用 dig 来获取区域的密钥签名（KSK) 的 DNSKEY 记录，并输入该记录作为 trust-anchor 选项的值。

8、将更改保存到 /etc/unbound/unbound.conf

9、检查 /etc/unbound/unbound.conf配置文件是否有语法错误。

[root@server0 ~]# unbound-checkconf 
unbound-checkconf: no errors in /etc/unbound/unbound.conf
[root@server0 ~]#

10、重新启动 unbound.service

[root@server0 ~]# systemctl restart unbound

11、配置防火墙以允许 DNS 流量。

[root@server0 ~]# firewall-cmd --permanent --add-service=dns
success
[root@server0 ~]# firewall-cmd --reload
success
[root@server0 ~]#

转储和加载unbound 缓存

对DNS 问题进行故障排除时，缓存名称服务器的管理员要转储数据，如由于陈旧资源记录产生的缓存数据。通过unbound DNS 服务器，可以通过联合 dump_cache 子命运行 unbound-control实用程序来转储络缓存。

使用 dump_cache 命令执行 unbound-control 以便文本格式将缓存转储到 stdout 。可以将此输出定向到文件以进行存储，也可以在之后使用 unbound-control load_cache 命令重新加载到缓存中（如果需要）。unbound-control load_cache 从 stdin 中读取填充缓存。

[root@server0 ~]# unbound-control load_cache < dump.out

清空unbound 缓存

缓存名称服务器的管理员需要经常从缓存中清除过期的资源记录。在过期资源记录上的TTL 到期之前，缓存中的错误和过期资源记录将阻止新的已更正的对应资源记录代客户端使用。管理员可以通过执行带有 flush子命令的 unbound-control 来强制清除过期记录而不必等待TTL 过期。

[root@server0 ~]# unbound-control flush www.example.com

www.example.com 如果需要从 unbound DNS 服务器缓存中清除属于某个域的所有资源记录，则可以使用 flush_zone 子命令来执行 unbound-control .

[root@server0 ~]# unbound-control flush_zone example.com

使用dnssec-trigger 更新本地缓存 unbound 配置

除了为本地子网提供缓存名称服务 unbound 作为本地缓存名称服务器也很有用，可提供安全的DNS 名称解析以供在个别系统上本地使用。对于本地缓存名称服务器设置，/etc/resolv.conf 中的 nameserver 条目将配置为指向unbound 正在侦听本地主机。unbound 配置将 DNS 请求转发到上游名称服务器并验证其响应。

对于运行本地缓存名称服务的 DHCP 系统，如果 DHCP 提供的 DNS 服务器发生更改，则 unbound 的配置中指定的上游名称服务器可能过期。可以利用相同名称的软件包提供的 dnssec-trigger 工具来自动更新 unbound 的配置文件中的转发器设置以指向新的 DNS 服务器。dnssec-trigger 工具与 unbound 组合使用对于漫游客户机上的安全DNS 名称解析很有用。

DNS 故障排除

由于DNS 的客户端-服务器架构，在系统上正确使用DNS 名称解析不仅依赖于该系统上的DNS 正确配置和操作，而且还依赖其解析名称服务器以及用于解析其DNS 请求的众多权威名称服务器的配置和操作。由于 DNS 是分布式目录，因此递归名称解析通常会涉及到大量与不同权威名称服务器的后台交互。这些大量交互产生了很多可能的故障点。

使用缓存名称服务器可显著降低 DNS 工作负载以及提高DNS 性能。但是，缓存功能会产生下面的情况：由于数据不再是最新的，导致客户端收到的DNS 响应不准确，这就增加了另一个故障点。

由于DNS 在网络服务运行方面扮演了重要角色，因此 Linux 管理员必须能够在发生DNS 问题时迅速加以解决以最大程序降低服务中断。准确且高效率进行DNS 故障排除的关键在于能够在大量后台客户端-服务器交互中找出所观察的意外行为由多个点的哪一个引起。这要求使用正确的工具并明确理解其提供的诊断数据。由于 Domain InterNet Groper( dig) 的详细诊断输出，这是一个用于调查DNS 问题的不错工具。

名称解析方法

由于DNS 服务通常是最广使用的名称解析方法。因此只要发生意外的名称解析结果，通常被视为责任方，切记，除了 DNS 之外，在异构环境中，一个联网主机上的名称解析可通过其方法进行，如本地主机文件(hosts)、Windows Internet 名称服务（wins)等等。

在 Linux 系统上，默认情况下，首先使用主机文件 /etc/hosts ，按照 /etc/nesswitch.conf中指定的顺序来尝试名称解析。因此，在开始解析故障诊断时，请铁勿贸然假设问题存在于 DNS。首先确定正在使用中的名称解服务机制，而不是直接从DNS 开始。glibc-common 软件包中的getent 命令以及 syslinux 软件包中的 gethostip 命令均可用于执行名称解析，按照/etc/nsswitch.conf 规定的主机名解析顺序来镜像大部分应用程序使用的进程。

[root@desktop0 ~]# getent hosts example.com
172.25.254.254  example.com
[root@desktop0 ~]# gethostip example.com
example.com 172.25.254.254 AC19FEFE

如果 getent 或 gethostip 的结果不同于 dig 产生的结果，那么这明确表明并非是 DNS 导致了意外的名称解析结果。查阅 /etc/nsswitch.conf 以确定在 DNS 之前是否利用了其他名称解析机制。

客户端–服务器网络连接

要使 DNS 名称解析正确生效，系统必须首先能够与其解析名称服务器或其他权威名称服务器进行客户端–服务器交互。部分源于这一层的常见 DNS 问题是由于解析器和防火墙配置错误而导致的。

使用 dig 对 DNS 问题进行故障排除时，如果没有从DNS 服务器收到响应，则明确表明原因在于客户端-服务器网络与 DNS 服务器的连接。

[root@server0 ~]# dig A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> A example.com
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@server0 ~]#

一个可能原因是，由于系统的 DNS 配置中包含不正确的DNS 服务器 IP地址，导致无法访问 DNS 服务器。如果系统充当 DNS 客户端，则不正确的地址可能在 /etc/resolv.conf 中，如果系统被配置为 unbound 缓存名称服务器，则可能在　/etc/unbound/unbound.conf 的 forward-zone子句中。

另一个可能是原因是客户端或服务器系统上的防火墙规则阻止了端口 53 上面的 DNS 流量。尽管 DNS 大部分使用 UDP 协议，但务必请注意，当响应数据大小超过 512 字节时或者超过 4096字节时（如果是支持 DNS 扩展机制（EDNS)的 DNS 服务器），则解析器将回退为使用TCP 来重试查询。因此，正确的配置应同时时 UDP 和 TCP 允许端口53 上的DNS 流量。如果解析器遇到的响应大小超过了其能够通过 UDP处理的大小，则仅对 UDP 允许端口53 流量将导致截断错误。

dig 的tcp 或 vc 选项有助于诊断DNS 查询在使用 TCP 时是否可以成功，。这些选项强制dig 使用tcp，而非表现下列默认行为：首先使用udp ，仅当响应大小需要时才回退为使用 tcp 。

在网络层处理 DNS 问题时，dig 提供很少的输出，因此另外使用网络包分析器（如 tcpdump )通常也很有用，可确定在网络层后台发生的情况。使用 tcpdump ，管理员可以确定无法仅通过dig来确定的信息，如DNS 请求的目标 ip 地址，请求包是否离开客户端，请求包是否到达服务器，响应包是否离开服务器，响应包是否到达客户端等等。

DNS 响应代码

如果 DNS 客户端-服务器通信成功，则dig 将生成更详细的输出，详细描述从 DNS 服务器收到的响应的性质。dig 的输出的HEADER部分中的status 字段报告 DNS 服务器为响应客户端的查询而生成的响应代码。

状态 NOERROR 表示已成功解析查询。如果服务器在满足客户端的查询时遇到问题，则将显示以下其中一个通用错误代码。

DNS 返回代码

代码	含义
SERVFAIL	名称服务器在处理查询时遇到问题
NXDOMAIN	查询名称在区域中不存在
REFUSHED	由于策略限制，名称服务器拒绝了客户端的DNS请求。

SERVFAIL

SERVFAIL 状态的常见原因是 DNS 服务器无法与对正在查询的名称有权威的名称服务器进行通信。这可以是由于权威名称服务器不可用。还可能是网络层的问题干扰了 DNS 服务器与权威名称服务器之间的客户端–服务器通信，如网络路径中任何跃点上的网络路由问题或防火墙规则。

要确定名称服务器在代表客户端的查询执行递归时是否生成了 SERVFAIL状态，名称服务器的管理员将需要确定哪个名称服务器通信导致了故障。在此情况下。dig 的 +trace 选项有助于查看名称服务器的迭代查询的结果（从根名称服务器开始）。

NXDOMAIN

NXDOMAIN状态指示没有找到与查询的名称相关联的记录。如果这不是预期结果并且查询被定向到一个对该名称没有权威的服务器，那么服务器的缓存可能包含名称的负缓存。用户可以等待服务器使该名称的负缓存到期，或者向服务器管理员提交请求，要求从服务器的缓存中清空名称。一旦从缓存中删除了名称，服务器将查询权威名称服务器以接收该名称的当前资源记录。

可能意外遇到NXDOMAIN状态的另一种情况是在查询包含孤立 CNAME 的 CNAME 记录时，在 CNAME 记录中，记录右侧的名称(即规范名称）应指向一个包含 A 或 AAAA 记录的名称。如果这些关联的 A 或 AAAA 记录不存在或者之后被删除，则CNAME 记录中的规范名称将变成孤立。发生此情况时，对 CNAME 记录中所有者名称的查询将不再可解析，并且将导致 NXDOMAIN 返回代码。

REFUSHED

REFUSHED 状态指示 DNS 服务器的某个策略限制阻止了其满足客户端的查询。策略限制通常是在 DNS 服务器实施，以限制哪些客户端可以进行递归查询和区域传输请求。导致意外的REFUSHED返回代码的一些常见原因是客户端配置为查询错误的 DNS 服务器，或者 DNS 服务器配置错误导致有效的客户端请求被拒绝。

其他常见DNS 问题

过期的缓存数据

DNS 返回代码NOERROR 表示解析查询时没有遇到错误。但是，这不能保证 DNS 没有问题。有些情况下，DNS 响应中的 DNS 记录可能与预期结果不匹配。错误答案的最常见原因是，答案源自缓存的数据，而不再是最新的。

在这些情况下，首先确认响应确定是非权威的缓存数据。这可以通过查看 dig 的输出的 flags 部分来轻松确定。 DNS响应（即权威答案）将通过显示 aa标志来指示。

源自缓存数据的DNS 响应不是权威的，因此将不会设置 aa 标志。表示答案来自缓存的另一个特征是每个后续查询的响应中资源记录的 TTL 值的倒数。缓存数据的TTL 将连接倒数到过期，而权威数据的 TTL 将始终为静态。