金鱼哥RHCA回忆录：RH358管理DNS和DNS服务器--DNS问题故障排除

RH358管理DNS和DNS服务器–DNS问题故障排除

本章节介绍DNS常见的TroubleShooting。

此文章（ 第三章 管理DNS和DNS服务器–DNS问题故障排除 ）收录在RHCA专栏：RHCA 回忆录

1. DNS故障排除

工作名称解析取决于相关设置是否正确：

• 客户端名称解析和/etc/resolv.conf。

• 客户端使用的缓存名称服务器的操作。

• 向缓存名称服务器提供数据的权威名称服务器的操作。

• 权威名称服务器上的数据。

• 用于在这些系统之间通信的网络的配置。

这就产生了几个可能的故障点。

2. 确认名称解析问题的来源

DNS是系统最常用的名称解析方法，因此在发生名称解析错误时经常被指责。但这并不是系统解析主机名和IP地址的唯一方式。但是，也可以使用其他方法进行名称解析，包括本地/etc/hosts文件和Zeroconf网络。

系统的/etc/nsswitch.conf文件中的hosts行控制了查找主机名的方式。一个典型的条目如下所示:

hosts:  files  dns  myhostname

• 首先在本地/etc/hosts文件中查找主机名。

• 否则，它将执行DNS查找。

• 如果DNS查找失败，localhost和系统主机名的结果应该使用nss-myhostname(8)进行解析。

可以使用glibc-common包中的getent命令来执行名称解析，按照/etc/nsswitch.conf所规定的主机名解析顺序来镜像大多数应用程序使用的过程。

[user@host ~]$ getent hosts example.com
172.25.254.254 example.com

如果getent的结果与dig产生的结果不同，那么这就清楚地表明，除了DNS之外，还有其他东西对意外的名称解析结果负责。

3. 调查DNS问题

调查DNS问题的最佳工具之一是dig。dig命令执行DNS查找，并提供详细的响应，其中包括关于请求和结果的诊断信息。

在下面的示例中，使用要解析的名称调用dig。默认情况下，它会在A记录中查找该名称:

[user@host ~]$ dig servera.lab.example.com
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> servera.lab.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3241
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;servera.lab.example.com. IN A

;; ANSWER SECTION:
servera.lab.example.com. 3600 IN A 172.25.250.10

;; Query time: 0 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Wed May 13 15:20:31 CDT 2020
;; MSG SIZE rcvd: 68

结果显示，请求的状态为NOERROR，这意味着请求成功完成。有一份记录作为答案。QUESTION SECTION重述查询，ANSWER SECTION显示返回的资源记录: servera.lab.example.com有一个A记录指向172.25.250.10，并且有一个生存时间(TTL)，表明答案应该被缓存3600秒

还可以指定要查找的其他资源记录。例如，下面的命令指定要查找同一主机的AAAA记录:

[user@host ~]$ dig AAAA servera.lab.example.com
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> AAAA servera.lab.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61178
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;servera.lab.example.com. IN AAAA

;; ANSWER SECTION:
servera.lab.example.com. 3600 IN AAAA fde2:6494:1e09:1::a
servera.lab.example.com. 3600 IN AAAA fde2:6494:1e09:2::a

;; Query time: 0 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Wed May 13 15:22:01 CDT 2020
;; MSG SIZE rcvd: 101

这个例子返回了主机的两条AAAA记录。如果缺少ANSWER SECTION且ANSWER为0，则查找没有为该名称找到该类型的资源记录。

通常，dig使用/etc/resolv.conf中列出的DNS名称服务器。可以通过在命令行上添加一个@后跟服务器名来指定一个不同的名称服务器。下面的示例在classroom.example.com上查找example.com的MX记录。他的结果还报告了一些关于名称服务器的相关信息，缓存名称服务器也将缓存这些信息。

[user@host ~]$ dig @classroom.example.com mx example.com
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> @classroom.example.com mx
example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17161
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 98551d3793ee3d2c90d490435ebc5cdec91821df16f7ff0d (good)
;; QUESTION SECTION:
;example.com. IN MX

;; ANSWER SECTION:
example.com. 86400 IN MX 10 classroom.example.com.

;; AUTHORITY SECTION:
example.com. 86400 IN NS classroom.example.com.

;; ADDITIONAL SECTION:
classroom.example.com. 86400 IN A 172.25.254.254

;; Query time: 1 msec
;; SERVER: 172.25.254.254#53(172.25.254.254)
;; WHEN: Wed May 13 15:28:23 CDT 2020
;; MSG SIZE rcvd: 124

诊断网络连通性问题

DNS名称解析要正常工作，客户端必须能够与解析名称服务器通信，解析名称服务器必须能够与其他权威的名称服务器通信。

例如，如果dig不能到达/etc/resolv.conf中的任何DNS服务器，则会出现以下错误。这可能是因为名称服务器宕机、客户端上的网络或防火墙出现问题，或者/etc/resolv.conf配置错误。

[user@host ~]$ dig A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> A example.com
;; global options: +cmd
;; connection timed out; no servers could be reached

如果涉及防火墙，则必须确保客户端可以通过UDP和TCP连接53端口的名称服务器。即使DNS主要使用UDP协议，当响应的大小超过512字节(4096字节对于DNS解析器和服务器，支持扩展机制的DNS (EDNS))，解析器必须从UDP切换到TCP，并重试查询。

如果允许53/UDP端口上的流量，但不允许53/TCP端口，会看到截断通知，当解析器遇到一个响应大于它可以处理的UDP时，紧随其后的是主机不可到达的错误：

[user@host ~]$ dig @dns.example.com A labhost1.example.com
;; Truncated, retrying in TCP mode.
;; Connection to 172.25.1.11#53(172.25.1.11) for labhost1.example.com failed:
host unreachable.

dig使用tcp或vc选项来帮助确定DNS查询是否使用TCP可以成功。这些选项强制dig使用TCP，而不是默认的先使用UDP，然后只在较大的响应时退回到TCP。

[user@host ~]$ dig +tcp A example.com

解析DNS响应码

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

[user@host ~]$ dig A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30523
…………

NOERROR状态表示查询已成功解析。

如果服务器在执行客户端查询时遇到问题，会显示以下常见错误状态码之一:

DNS状态码

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

SERVFAIL

造成SERVFAIL返回代码的一个常见原因是DNS服务器无法与授权查询名称的名称服务器进行通信。这可能是因为权威名称服务器不可用。可能是由网络问题引起的，这些问题干扰了缓存DNS服务器和权威名称服务器之间的客户机-服务器通信，例如网络路由问题或网络路径上任何一跳上的防火墙规则。

要确定为什么名称服务器在代表客户端查询执行递归时生成SERVFAIL返回代码，名称服务器管理员需要确定是哪个名称服务器通信导致了失败。在这个场景中，可以使用dig的+trace选项来查看名称服务器的迭代查询的结果，从根名称服务器开始。

NXDOMAIN

NXDOMAIN返回码表示没有找到与查询的名称相关的记录。如果这不是预期的结果，并且查询指向的服务器不是该名称的权威，那么服务器的缓存可能包含该名称的反向缓存。用户可以等待服务器将该名称的负缓存过期，或者向服务器管理员提交请求，从服务器缓存中清除该名称。名称从缓存中删除后，服务器将查询权威名称服务器，以接收名称的当前资源记录。

NXDOMAIN返回码可能出现的另一种情况是在查询包含孤立CNAME的CNAME记录时。在CNAME记录中，记录右侧的名称(规范名称)应该指向包含a或AAAA记录的名称。如果这些关联的记录不存在或稍后被删除，则CNAME记录中的规范名称是孤立的。当这种情况发生时，查询CNAME记录中的所有者名称将不再是可解析的，并将导致一个NXDOMAIN返回码。

REFUSED

REFUSED返回码表示DNS服务器存在策略限制，无法完成客户端的查询。策略限制通常在DNS服务器上实现，以限制哪些客户端可以进行递归查询和区域传输请求。导致REFUSED返回码的常见原因有:客户端配置了错误的DNS服务器，或者DNS服务器配置错误导致有效的客户端请求被拒绝。

尽管NOERROR状态表示在解析查询时没有遇到错误，但它不能保证不存在DNS问题。存在这样的情况:DNS响应中的DNS记录可能与预期的结果不匹配。

4. 在缓存名称服务器上处理旧数据

缓存名称服务器可以减少DNS工作负载并提高DNS性能。但是，缓存可能会导致客户端接收到过时的信息。

当DNS应答来自已不在权威服务器上当前的缓存数据，但TTL尚未过期时，就会发生这种情况。这可能是区域管理员在更改资源记录数据之前将TTL设置得过高的结果。

在这些情况下，必须首先确认响应是非权威的缓存数据。查看挖掘输出的标志部分。权威的答案由aa标识的存在表示

[user@host ~]$ dig A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31114
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

来源于缓存数据的DNS响应是不权威的，因此没有aa标志集。答案来自缓存的另一个指示是在后续查询的响应中减少了资源记录的TTL值。缓存数据的TTL持续倒计时到过期，而权威数据的TTL始终保持静态。

权威名称服务器管理员应该在更改之前将记录的TTL设置为低，然后在记录更新时将其设置为正常，这样就不会发生这个问题。当发生这种情况时，管理员通常必须等待每个人缓存中的旧版本过期。如果使用过时的、未过期的记录管理缓存名称服务器，则可以从缓存中清除坏记录。使用Unbound名称服务器时，使用unbound-control flush record-name命令刷新与record-name关联的记录。

5. 识别区域数据的问题

有时，名称解析问题是由于权威名称服务器上的区域配置中的意外行为、遗漏或错误造成的。即使您不管理权威的名称服务器，您也应该能够识别返回到客户机的数据是否是问题所在。在管理区域文件时，诊断这些问题的能力更加重要。

获得不同的答案：Round-robin轮循式DNS

一个名称在DNS中可以有多条记录。这允许您配置轮循DNS，并且通常用作一种简单、低成本的负载均衡机制，以便在多个主机之间分配网络资源负载。

当DNS客户端提交一个包含多个a或AAAA记录的名称查询时，所有记录作为一个集合返回。但是，在集合中返回这些记录的顺序对于每个查询都是不同的。因为客户端通常使用集合中的第一个地址，所以每个响应中记录顺序的更改会有效地导致跨这些轮循DNS记录中的多个IP地址分发网络服务请求。

当错误地创建此配置时，有时会出现问题。例如，权威名称服务器的管理员可能打算更改主机的A记录，但错误地为该主机添加了第二个A记录，而没有删除旧的记录。如果旧的A记录的IP地址在服务器上退役了，但仍然在DNS中，roundrobin DNS的负载分布效应将导致大约一半的客户端(得到过时的A记录的那一半)服务失败。

看到反向查找失败：丢失PTR记录

许多网络服务使用DNS来执行来自客户机的传入连接的反向查找。DNS中缺少PTR记录可能会导致问题，问题的性质取决于服务。缺省情况下，SSHD执行连接客户机ip的反向查找。缺少PTR记录会导致这些连接的建立延迟。

许多邮件服务器合并反向DNS查找连接的客户端ip作为防御恶意电子邮件客户端。事实上，许多邮件服务器被配置为拒绝ip的客户端连接，这无法通过DNS中的PTR查询来解析。因此，支持网络服务的管理员需要确保他们理解这些服务不仅对正向DNS查找有需求，而且对反向DNS查找也有需求。

对不存在记录的响应

如果从区域中删除了一条记录，并且在查询该记录时仍然收到响应，那么首先要确认没有从缓存的数据中响应查询。如果答案是经过挖掘输出中aa标志的确认的，那么可能的原因是区域中存在通配符(*)记录。

*.example.com. IN A 172.25.254.254

通配符记录可作为给定类型中不存在名称的所有查询的通配符。在前面的通配符记录存在的情况下，如果先前存在host.example.com的A记录并且它被删除了，对该名称的查询仍然会成功，并且通配符A recoro中的IP地址将在其位置上提供。

在名称中看到FQDN两次以及相关错误

在区域文件中，没有表示为完全限定域名(FQDNs)的主机名通过附加区域的名称自动扩展为FQDNs。表示名字是一个区域文件中的FQDN，它必须以“.”结尾。例如:“ www.example.com. ”如果不这样做，可能会导致不同的问题，这取决于所犯错误的记录类型。例如，在NS记录的特定类型数据部分中犯这样的错误可能会使整个区域失去能力，而在MX记录中犯这样的错误可能会导致一个域的电子邮件传递完全停止。

标识循环CNAME记录

应该避免指向CNAME记录的CNAME记录，以减少DNS查找的低效。另一个不受欢迎的原因是可能会创建不可解析的CNAME循环，例如:

test.example.com. IN CNAME lab.example.com.
lab.example.com.  IN CNAME test.example.com.

当一个CNAME记录带有一个孤立的CNAME将导致一个NXDOMAIN状态，循环CNAME记录将返回一个NOERROR状态。

注意：大多数权威的名称服务器保护相同区域的记录之间不发生CNAME循环，但在某些情况下，仍然可以在跨多个区域的CNAME记录链中创建循环。

从权威服务器获得不同的答案

有时，您可能会发现您的主名称服务器在其区域内为DNS查询提供了与其他权威名称服务器不同的答案。这通常是因为您的其他服务器没有来自主服务器的区域的最新版本。

当对这种情况进行故障排除时要问的一些问题包括：

• 名称服务器是否有受影响的区域的最新版本?查看SOA记录中的序列号。

• 当您更新主服务器上的区域文件时，是否增加了区域SOA记录中的序列号?

• 主服务器和其他授权服务器之间的通信是否因网络问题或防火墙而受阻?

• 主服务器是否配置为允许其他名称服务器执行区域传输?使用BIND，检查主服务器的allow-transfer指令。

• 其他授权名称服务器是否配置为与该区域的正确主服务器通信?

6. 课本练习

[student@workstation ~]$ lab dns-tshooting start

用户报告当从服务器向example.com发起SSH会话时发生问题。当命令失败时，显示以下错误信息:" Could not resolve hostname example.com: Name or service not known"

用户怀疑example.com的DNS名称解析有问题。与网络上的所有其他主机一样，服务器应该使用172.25.250.254作为DNS解析。这些信息通常是从DHCP配置的。

对问题进行故障排除，确定根本原因，应用修复，并验证问题已解决。

1. 查看问题。

[student@workstation ~]$ ssh servera
[student@servera ~]$ ssh example.com
ssh: Could not resolve hostname example.com: Name or service not known
[student@servera ~]$ getent hosts example.com
[student@servera ~]$

2. 确定哪些配置影响名称解析。

# 使用grep命令显示/etc/nsswitch.conf文件中的hosts条目。确定名称服务的使用顺序。
[student@servera ~]$ grep ^hosts: /etc/nsswitch.conf
hosts: files dns myhostname

# 因为首先使用文件，所以请检查/etc/hosts文件的内容，以确定是否有example.com的条目。
[student@servera ~]$ grep [[:space:]]example.com /etc/hosts
[student@servera ~]$

# 因为hosts文件没有条目。查看/etc/resolv.conf文件的内容，以确定正确的name-server条目。name server的IP地址为172.25.250.254。如果您有一个不同的名称服务器IP地址，这很可能是名称解析失败的原因。
[student@servera ~]$ grep ^nameserver /etc/resolv.conf
nameserver 172.25.250.255

[student@servera ~]$ dig @172.25.250.255 A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> @172.25.250.255 A example.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

3.修改为正确的配置。

使用NetworkManager服务用正确的name-server条目刷新/etc/resolv.conf文件的内容。

# 验证新条目并确认它解决了名称解析问题。
[student@servera ~]$ sudo systemctl restart NetworkManager
[sudo] password for student: student
[student@servera ~]$

[student@servera ~]$ grep ^nameserver /etc/resolv.conf
nameserver 172.25.250.254

# 验证example.com的名称解析结果。
[student@servera ~]$ getent hosts example.com
172.25.254.254 example.com

[student@servera ~]$ dig example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		86346	IN	A	172.25.254.254

;; Query time: 0 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Thu Jun 10 21:23:05 CST 2021
;; MSG SIZE  rcvd: 56

# 验证从服务器到example.com的SSH连接现在成功了。
[student@servera ~]$ ssh example.com

完成实验。

[student@workstation ~]$ lab dns-tshooting finish

总结

• 介绍DNS故障排除。
• 根据响应码调查DNS故障。
• 如何识别区域数据的问题。

RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶🤪。

以上就是【金鱼哥】对 第三章 管理DNS和DNS服务器–DNS问题故障排除 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点，如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！