Linux服务--3.DNS 服务

DNS 服务介绍

DNS的诞生

当我们在浏览器中输入一个域名访问某个网站时，这个域名最终会被解析为一个IP地址，我们的浏览器实际是在和这个IP地址进行通信。 负责将域名解析到IP地址的协议为DNS（Domain Name System，域名解析系统）。 网络中每个节点都有自己唯一的IP地址，通过IP地址可以实现节点之间的相互访问，但是如果和所有的节点进行通信都使用IP地址的方式，人们很难记住这么多IP地址，为此提出了DNS，将难以记忆的IP地址映射为字符类型的地址。 Internet的前身ARPAnet时就已经存在主机名称和IP地址的对应关系，只是当时主机数目很少，只需要一个HOSTS.txt文件就可以维护对应关系，HOSTS.txt由NIC（network information center）维护，改动自己主机名的使用者通过电子邮件将自身改动发送给NIC，NIC定期更新HOSTS.txt，这一切在主机数目很少时都没有什么问题。但当ARPAnet使用TCP/IP协议之后，网络用户数量出现了激增，手动维护HOSTS.txt似乎变得困难起来：

• 名称冲突：NIC虽然可以保证管理的主机名称一致性，但很难保证主机不会随机修改名称和别人正在使用的一致。

• 一致性：随着网络规模扩大，用户的HOSTS.txt很难保持一致性，很可能主机的HOSTS.txt文件还未更新，其余主机的名称已经变动了数次。

于是接替者DNS由此诞生。

域名系统组成

域名：主机的字符标识方式。大部分情况下，我们访问网站时在浏览器内输入的URL就是该网站的域名。 域名解析服务器（DNS Server）：负责维护域名与IP地址对应关系的数据库，并对解析者的请求进行响应。 域名系统是一个分布式的结构，每个服务器上的数据库只保存了部分域名与IP的对应关系。

域名的标识方法

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

Domain

domain 是 resource records 的集合，该集合以通用名结尾，表示 DNS 命名空间的整个⼦树，如xiaomi.com。 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之类的域。

其他顶级域参考顶级域名参考根域数据库。

• 域名的表示方法为：主机名.次顶级域名.顶级域名.根域，根域为"."，一般最后的根域不表示。

DNS查询方式

DNS是一个分布式系统，绝大多数的DNS服务器端的数据库不会拥有所有的域名记录，当客户端向一个DNS服务器端查询域名但该DNS服务器端上却没有该域名的记录时，此时会有两种继续查询的方式：

• 递归查询：由DNS服务器向其他DNS服务器进行查询，将最终查询结果返回给DNS客户端。

• 迭代查询：DNS服务器告知DNS客户端其他DNS服务器地址，客户端自行向其他DNS服务器进行查询。

迭代查询不同于递归查询，DNS服务器1返回的DNS响应里的内容是另外一个DNS服务器地址。 主机的 DNS 查询主要有两种方式：递归查询和迭代查询。 DNS 查询时，DNS 请求报头部的 RD 字段决定了查询类型：

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

• RD 为 0 => 迭代查询。 两者主要区别：

• 递归：一问到底，委托别人全权代办（PC → DNS 服务器）

• 迭代：层层问路，自己一站一站挨个去问（DNS 服务器对外查询）

递归查询

我只发1 次请求，全权交给对方，对方必须给我最终答案（IP）或者报错，不能甩锅。 角色：客户端 ↔ 本地 DNS 服务器（运营商 DNS / 8.8.8.8 / 自建 dnsmasq）

迭代查询

我向服务器发起请求，对方查不到完整结果，只返回下一级服务器地址，需要我自己继续挨个询问。 角色：本地 DNS 服务器 ↔ 根域名服务器、顶级域、权威服务器

DNS查询完整流程对比

（以 www.xiaomi.com 为例）

✅ 标准互联网DNS流程（递归 + 迭代结合，99.9%场景）：

DNS 资源记录

DNS资源记录（Resource Record，RR）是DNS服务器中存储域名与对应信息的核心数据结构，每一条记录都对应一个域名的特定属性。 通用模板（所有DNS记录都长这样）

#域名                   TTL     类别   记录类型 内容
owner-name             TTL     class   type   data
server.laogao.cloud.    300     IN     A       192.168.1.10

记录说明：

A 资源记录

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

server.laogao.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.laogao.cloud.   30 IN CNAME lab.laogao.cloud.
server.laogao.cloud.    30 IN CNAME www.laogao.cloud.

• 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记录。

【区域名】 TTL IN NS 【权威服务器FQDN.】
laogao.cloud.                       86400 IN NS dns.laogao.cloud.
区域（zone）名字                                 该区域由哪台 DNS 服务器负责权威解答
168.192.ip-addr.arpa.               86400 IN NS dns.laogao.cloud.
9.0.e.1.4.8.4.6.2.e.d.f.ip6.arpa.   86400 IN NS dns.laogao.cloud.

说明：

• 其中两个NS记录用于192.168.0.0/16网络和fde2:6484:1e09::/48网络的反向查找。

• classroom.laogao.cloud上的区域可能包含NS记录，以将对192.168.254.0/24和fde2:6484:1e09::1:: /64的反向查找委托给另一个名称服务器。

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

SOA 资源记录

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

• 指定了一个序列号

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

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

记录值说明：

MX 资源记录

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

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

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

主机和资源记录

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

• ⼀个或多个A或AAAA记录

• 用于将其IP地址反向映射到名称的PTR记录

• ⼀个或多个CNAME记录（可选）

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

• 唯一的 SOA 记录

• 每个权威名称服务器的 NS 记录

• ⼀个或多个MX记录（可选）

• 用于在域中查找服务的⼀个或多个SRV记录（可选）

DNS常用客户端命令

windows查询dns缓存

C:\\Users\\69466>ping www.huawei.com
正在 Ping hcdnw.cbgipv6.gslb.c.cdnhwc2.com [221.229.162.64] 具有 32 字节的数据:
来自 221.229.162.64 的回复: 字节=32 时间=9ms TTL=55
来自 221.229.162.64 的回复: 字节=32 时间=10ms TTL=55
来自 221.229.162.64 的回复: 字节=32 时间=10ms TTL=55
来自 221.229.162.64 的回复: 字节=32 时间=19ms TTL=55
221.229.162.64 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 9ms，最长 = 19ms，平均 = 12ms
C:\\Users\\69466>ipconfig /displaydns | findstr huawei
www.huawei.com
记录名称. . . . . . . : www.huawei.com
CNAME 记录  . . . . . : www.huawei.com.akadns.net
记录名称. . . . . . . : www.huawei.com.akadns.net
CNAME 记录  . . . . . : www.huawei.com.c.cdnhwc1.com
记录名称. . . . . . . : www.huawei.com.c.cdnhwc1.com
C:\\Users\\69466>ipconfig /flushdns
Windows IP 配置
已成功刷新 DNS 解析缓存。
# nslookup交互式
C:\\Users\\69466>nslookup
默认服务器:  dns.google
Address:  8.8.8.8
> www.qq.com
服务器:  dns.google
Address:  8.8.8.8
非权威应答:
名称:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  240e:e1:a800:120::76
240e:e1:a800:120::36101.91.42.232101.91.22.57
Aliases:  www.qq.com
# nslookup非交互式
C:\\Users\\69466>nslookup www.360.cn
服务器:  dns.google
Address:  8.8.8.8
非权威应答:
名称:    www.360.cn
Addresses:  36.99.171.154
106.63.103.5

wohis查询域名信息

[root@dns-client ~]# yum install -y whois
[root@dns-client ~]# whois qq.com

host命令

#host： Linux 下用来查询 DNS 解析的小工具
#-t NS： 指定查询类型为 NS 记录（Name Server， 域名服务器）
#huawei.com： 要查的域名
[root@dns-client ~]# host -t NS huawei.com   #查询 huawei.com 这个域名， 由哪些 DNS
服务器负责解析
huawei.com name server nsallsec.huawei.com.
huawei.com name server nsall4th.huawei.cn.
huawei.com name server nsall.huawei.com.
huawei.com name server nsall3rd.huawei.cn.
#查IP（A记录）
[root@dns-client ~]# host www.qq.com
www.qq.com is an alias for ins-r23tsuuf.ias.tencent-cloud.net.
ins-r23tsuuf.ias.tencent-cloud.net has address 101.91.22.57
ins-r23tsuuf.ias.tencent-cloud.net has address 101.91.42.232
ins-r23tsuuf.ias.tencent-cloud.net has IPv6 address 240e:e1:a800:120::76
ins-r23tsuuf.ias.tencent-cloud.net has IPv6 address 240e:e1:a800:120::36
#查邮箱服务器(MX记录)
[root@dns-client ~]# host -t MX qq.com
qq.com mail is handled by 30 mx1.qq.com.
qq.com mail is handled by 20 mx2.qq.com.
qq.com mail is handled by 10 mx3.qq.com.

dig命令

[root@dns-client ~]# dig -t A www.qq.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7 <<>> -t A www.qq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3240
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 512
;; QUESTION SECTION:
;www.qq.com. IN A
;; ANSWER SECTION:
www.qq.com. 5 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
ins-r23tsuuf.ias.tencent-cloud.net. 5 IN A 101.91.22.57
ins-r23tsuuf.ias.tencent-cloud.net. 5 IN A 101.91.42.232
;; Query time: 519 msec
;; SERVER: 10.1.8.2#53(10.1.8.2)
;; WHEN: Wed Aug 05 14:39:17 CST 2026
;; MSG SIZE rcvd: 119
# 只看精简结果(最实用)
[root@dns-client ~]# dig +short www.qq.com
ins-r23tsuuf.ias.tencent-cloud.net.
101.91.42.232101.91.22.57
# 只看回答部分
[root@dns-client ~]# dig +nocmd +noall +answer www.qq.com
www.qq.com. 5 IN CNAME ins-r23tsuuf.ias.tencent-cloud.net.
ins-r23tsuuf.ias.tencent-cloud.net. 5 IN A 101.91.22.57
ins-r23tsuuf.ias.tencent-cloud.net. 5 IN A 101.91.42.232

nslookup命令

nslookup可以支持交互和非交互式两种方式执行 非交互模式：

# 查www.qq.com对应IP是多少
[root@dns-client ~]# nslookup www.qq.com
Server: 10.1.8.2
Address: 10.1.8.2#53
Non-authoritative answer:
www.qq.com canonical name = ins-r23tsuuf.ias.tencent-cloud.net.
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.22.57
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.42.232
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:e1:a800:120::36
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:e1:a800:120::76
# 让114.114.114.114帮我解析www.qq.com
[root@dns-client ~]# nslookup www.qq.com 114.114.114.114
Server: 114.114.114.114
Address: 114.114.114.114#53
Non-authoritative answer:
www.qq.com canonical name = ins-r23tsuuf.ias.tencent-cloud.net.
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.42.232
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.22.57
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:e1:a800:120::36
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:e1:a800:120::76

交互模式：

[root@dns-client ~]# nslookup
> www.qq.com
Server: 10.1.8.2
Address: 10.1.8.2#53
Non-authoritative answer:
www.qq.com canonical name = ins-r23tsuuf.ias.tencent-cloud.net.
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.22.57
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.42.232
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:e1:a800:120::36
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:e1:a800:120::76
>
> set q=a
> www.qq.com
Server: 10.1.8.2
Address: 10.1.8.2#53
Non-authoritative answer:
www.qq.com canonical name = ins-r23tsuuf.ias.tencent-cloud.net.
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.22.57
Name: ins-r23tsuuf.ias.tencent-cloud.net
Address: 101.91.42.232
>

配置权威名称服务器

权威名称服务器架构

权威名称服务器存储 DNS 资源记录，并为其管理的区域提供权威答案。 Linux中的Berkeley Internet Name Domain（BIND）软件可以实现权威的名称服务器。 BIND允许我们将权威服务器配置为区域的主要服务器或辅助服务器。区域中只有一台主服务器，但可具有多台辅助服务器。 辅助服务器通过请求区域传输，定期从主服务器下载区域信息的最新版本。 它们执行区域传输的频率以及如何知道其数据是否过时由区域的SOA资源记录控制。 名称服务器可以是某些区域的主要服务器，同时也可以其他区域的辅助服务器。 当前BIND服务器角色为master和slave，以后会变更为primary和secondary（例如，BIND9.16 ESV版本）。 注册新的DNS域时，必须提供该域的所有公共权威名称服务器的名称和IP地址。我们的注册服务商将该信息放在父域的区域文件中（如NS，A和AAAA记录），以便DNS解析器可以找到我们的名称服务器。为了帮助确保可靠性，我们应该至少有两个公共DNS服务器，并且它们应位于不同的站点，以避免由于网络故障而造成的中断。 并非所有权威服务器都必须是公共的。例如，使用primary服务器来管理区域文件，并将区域信息发布到权威的secondary服务器。primary服务器是私有的，而secondary服务器是面向公众的，从而为外部客户端提供权威性的答案，保护我们的primary服务器免受攻击。

架构示例1：外部客户端查找example.com

查找过程：客户的仅缓存名称服务器首先查询其中一个根名称服务器。 它定向到负责.com域的名称服务器池。 这些服务器之一使用example.com域的NS记录进行响应，因此仅缓存名称服务器会查询其中一个面向公众的辅助名称服务器。

架构示例2：内部客户端查找example.com

更好的方法是提供内部slave权威服务器。 查询本地域的记录时，消除了外部查询，而且更加安全。

BIND实验

节点规划

使用centos 7模板克隆出2台，根据节点规划更改主机名，IP地址 dns-server:

[root@localhost ~]# hostnamectl set-hostname dns-server
[root@localhost ~]# nmcli connection modify ens33 ipv4.method manual
ipv4.addresses 10.1.8.10/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes
[root@localhost ~]# nmcli connection up ens33

dns-client:

[root@localhost ~]# hostnamectl set-hostname dns-client
[root@localhost ~]# nmcli connection modify ens33 ipv4.method manual
ipv4.addresses 10.1.8.11/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes
[root@localhost ~]# nmcli connection up ens33

安装 BIND

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

[root@dns-server ~]# yum install -y bind bind-utils
# 安装完成后的组要配置文件
/etc/named.conf #主配置
/etc/named.rfc1912.zones #额外区域配置
/var/named/ #解析库文件存放目录
/var/log/messages # named 排错日志

软件包说明：

• bind，服务器软件包，真正运行 DNS 服务的程序。

• bind-utils， bind 工具软件包，用来测试、查询、排查 DNS，包含：nslookup 、 dig 、 host等命令。

  • dig → 最强大的 DNS 查询

  • nslookup → Windows/Linux 通用查询

  • host → 简单域名解析 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服务器需要执行以下步骤：

定义地址匹配列表

在/etc/named.conf文件的开头，可以使用acl指令定义地址匹配列表。 acl指令不是用于控制客户端对服务器的访问，而是使用它们来定义IP地址和网络列表。 把一组 IP 地址 / 网段 定义成一个名字（给 IP 段起别名，方便 DNS 权限控制），它们提供别名，可以与访问控制指令和其他配置选项一起使用，并使更新配置文件更加容易。 后面在 named.conf 里可以直接用这个名字控制：

• 谁能查询DNS

• 谁能递归查询

• 谁能同步区域数据

条目可以是完整的IP地址或网络，用尾点（10.1.8.）或CIDR表示法（192.168.0/24或2001:db8::/32）表示，也可以使用先前定义的地址匹配列表的名称。 请考虑以下ACL定义：

# vim /etc/named.conf
# 定义一个叫 trusted-nets 的组， 包含两个网段： 192.168.10.0/24 和 192.168.20.0/24
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网络中的主机匹配。acl语句定义的地址集可以被多个指令引用。

Important

acl：定义访问控制列表

trusted-nets：你自己起的名字（可信网段）

{ } 里面放允许的网段，192.168.10.0/24：第一个可信网段，192.168.20.0/24：第二个可信网段

named中内置了四个预定义的ACL：

案列：你的服务器IP：10.1.8.0/24

• localhost → 匹配：127.0.0.1、::1、10.1.8.10

• localnets → 匹配：127.0.0.0/8、::1/128、10.1.8.0/24

配置 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回送地址。

# vim /etc/named.conf
options {
listen-on port 53 { 127.0.0.1; 10.1.8.10; };
……
};

listen-on 是 "监听哪些本机 IP"

• 127.0.0.1：只允许本机内部访问 DNS（本机自己用）

• 10.1.8.10：允许局域网 / 外部机器访问这台服务器的 DNS

谁能访问

• 本机访问 127.0.0.1:53 → 能收到

• 其他机器访问 10.1.8.10:53 → 能收到

• 访问本机其他 IP（如 192.168.x.x） → 收不到

如果你想让 DNS 监听所有地址

• 把配置改成：listen-on port 53 { any; }; 示例2：结合acl指令配置。

# vim /etc/named.conf
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)。 区域转移允许客户端获取我们区域中所有数据的转储。 区域转移应该受到限制，否则攻击者很容易快速获取我们区域中的所有资源记录。 DNS 主从架构中：

• 主DNS：负责写解析记录

• 从DNS：需要从主服务器下载全部解析记录

这个下载动作叫区域传送（Zone Transfer）

allow-transfer { 允许的IP };
# 就是只允许这些 IP 来下载你的 DNS 数据。

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

[user@host ~]$ dig axfr @classroom.laogao.cloud laogao.cloud
#dig DNS 查询工具（来自 bind-utils）
#axfr = Area Transfer = 区域传送= 一次性下载整个域名的所有解析记录
# @classroom.laogao.cloud @ 后面 = 向哪台 DNS 服务器发起请求,这里就是向
classroom.laogao.cloud 这台 DNS 服务器请求
#laogao.cloud要下载 哪个域名区域 的全部记录

实验步骤

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

[root@dns-server ~]# vim /etc/named.conf
……
# 最后添加如下内容
zone "laogao.cloud" IN {
type master;
file "laogao.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@dns-server ~]# cp /var/named/named.localhost /var/named/laogao.cloud.zone
[root@dns-server ~]# cp /var/named/named.loopback /var/named/10.1.8.zone
[root@dns-server ~]# chmod 640 /var/named/*.zone
[root@dns-server ~]# chown root:named /var/named/*.zone
# 如果系统开启了selinux功能，执行下面命令设置文件标签
[root@dns-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资源记录

添加记录

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

• SOA记录。

• 每个公用名称服务器的NS记录。

• 该区域的其他A，AAAA，CNAME，MX，SRV和TXT记录。

示例：laogao.cloud域

# 参考/var/named/named.localhost
[root@dns-server ~]# vim /var/named/laogao.cloud.zone

$TTL 1D
@       IN SOA dns.laogao.cloud. root.laogao.cloud. (
0       ; serial
1D     ; refresh
1H     ; retry
1W     ; expire
3H )   ; minimum
IN NS   dns.laogao.cloud.
dns     IN A    10.1.8.10
server IN A    10.1.8.10
student IN CNAME client.laogao.cloud.
client IN A    10.1.8.11
www  30 IN A    10.1.8.200
@       IN MX 10 mail.laogao.cloud.
mail   IN A    10.1.8.253

示例说明：

• @字符代表区域的名称，避免重复键入，并且在某些情况下允许重复使用。

• 区域文件中的SOA记录与前面的示例中的SOA记录是等效的。

• 如果记录的名称为空，则其值与前面的记录相同。

因此，在前面的示例中：

• 第一个记录是laogao.cloud.的SOA记录

• 接下来的记录是laogao.cloud.的NS记录

• 然后有一个dns的A记录。

• 然后有一个server的A记录。

• 然后有一个student的CNAME记录。

• 然后有一个client的A记录。

• 然后有一个域的MX记录。

• 然后有一个mail的A记录。

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

• SOA记录

• NS记录

• PTR记录。

示例：8.1.10.inaddr.arpa区域

# 参考/var/named/named.loopback
[root@dns-server ~]# vim /var/named/10.1.8.zone

$TTL 1D
@       IN SOA dns.laogao.cloud. root.laogao.cloud. (
0       ; serial
1D     ; refresh
1H     ; retry
1W     ; expire
3H )   ; minimum
IN NS   dns.laogao.cloud.
10     IN PTR server.laogao.cloud.
10     IN PTR dns.laogao.cloud.
11     IN PTR client.laogao.cloud.
11     IN PTR student.laogao.cloud.
200     IN PTR www.laogao.cloud.
253     IN PTR mail.laogao.cloud.

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

验证配置

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

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

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

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

[root@dns-server ~]# named-checkzone laogao.cloud
/var/named/laogao.cloud.zone
zone laogao.cloud/IN: loaded serial 0
OK
[root@dns-server ~]# named-checkzone 1.8.10 /var/named/10.1.8.zone
zone 1.8.10/IN: loaded serial 0
OK

启动服务器时，应监视系统日志中是否有错误。 单个错误也可能会导致整个区域无法加载，但是无法加载区域不会阻止后台驻留程序启动。因此除非我们在启动过程中监视系统日志，否则很难弄清楚哪里错了。 例如，我们可以查看与named.service单位文件有关的systemd的日志输出：

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

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

运行 BIND

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

客户端测试

方式1：配置dns

# 配置客户端 dns
[root@dns-client ~]# nmcli connection modify ens33 ipv4.dns 10.1.8.10
[root@dns-client ~]# nmcli connection up ens33
# ping 工具测试
[root@dns-client ~]# ping dns.laogao.cloud
PING dns.laogao.cloud (10.1.8.10) 56(84) bytes of data.
64 bytes from dns.laogao.cloud (10.1.8.10): icmp_seq=1 ttl=64 time=1.26 ms
[root@dns-client ~]# ping student.laogao.cloud
PING client.laogao.cloud (10.1.8.11) 56(84) bytes of data.
64 bytes from client.laogao.cloud (10.1.8.11): icmp_seq=1 ttl=64 time=0.092 ms
# 其他工具
[root@dns-client ~]# host student.laogao.cloud
student.laogao.cloud is an alias for client.laogao.cloud.
client.laogao.cloud has address 10.1.8.11
[root@dns-client ~]# host 10.1.8.10
10.8.1.10.in-addr.arpa domain name pointer server.laogao.cloud.
10.8.1.10.in-addr.arpa domain name pointer dns.laogao.cloud.
[root@dns-client ~]# getent hosts student.laogao.cloud
10.1.8.11       client.laogao.cloud student.laogao.cloud

方式2：dig工具

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

配置缓存名称服务器-Unbound(扩展)

缓存名称服务器将DNS查询结果存储在本地缓存中，并在它们的TTL过期时从缓存中删除资源记录。在本地网络中设置缓存名称服务器，提供本给客户端查询是很常见的。 通过减少跨Internet的DNS流量，这极大地提高了DNS名称解析的效率。 随着本地缓存数量增加，缓存名称服务器回答越来越多的客户端查询，DNS性能将得到改善。

有几个软件包可用于配置缓存名称服务器，包括bind，dnsmasq和unbound。

在本部分中，我们将学习如何安装，配置和管理Unbound。

安装软件包

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

配置 unbound

配置文件/etc/unbound/unbound.conf：

• 在server子句中，定义网络监听。

interface: 10.1.8.20
interface: 2001:db8:1001::f0

        默认UNbound监听localhost网络接口。

        如果设置监听0.0.0.0或者::0，则将会监听所有接口，同时需要设置interface-automatic为yes。否则设置interface-automatic为no。

        如果此时本地还运行libvirtd服务，并且Unbound绑定到所有接口，将导致Unbound无法启动。因为libvirtd会运行dnsmasq，而dnsmasq也会在local接口上监听53端口。

• 在server子句中，定义访问控制列表。 使用access-control选项指定哪些客户端可以进行递归查询。我们可以指定网络或IP地址，最具体的匹配项获胜。三个最有用的设置是：

        allow，允许访问

        refuse，阻止访问并将DNS REFUSED错误发送给客户端

        deny，阻止访问，不发送响应

access-control: 127.0.0.0/8 allow
access-control: 172.25.0.0/24 allow
access-control: 2001:db8:1001::/32 allow
access-control: 10.1.8.0/24 allow
access-control: 10.1.7.0/24 refuse

配置访问控制，禁止除预期客户端之外的主机使用递归缓存名称服务器。 如果我们允许Internet上的任何主机递归查询我们的服务器，则攻击者可以使用它对第三方执行DNS放大分布式拒绝服务攻击。详情参考Deep Inside a DNS Amplification DDoS Attack | Cloudflare Blog。

• （可选）转发请求到其他名称服务器

如果此名称服务器无法访问Internet，但可以访问另外一个连接Internet的名称服务器，则可能需要执行此操作。 我们也可以执行此操作，以将对内部域的查询直接发送到对该域具有权威性的名称服务器。

创建一个forward-zone子句以指定要转发的域以及将查询转发到的DNS服务器。 将名称值设置为"." 转发所有查询。 使用forward-host选项通过主机名或使用forward-addr选项通过IP地址为转发区域指定DNS服务器。

forward-zone:

name: "."

forward-addr: 10.1.8.10

• （可选） 在server子句中，定义不需要DNSSEC验证的域。

默认情况下，Unbound执行DNSSEC验证收到的所有DNS响应。 通常，我们希望它执行此操作，但是有时我们的内部域未正确签名，因此无法通过DNSSEC验证。 server子句中的domain-insecure选项指定应跳过DNSSEC验证的域。

domain-insecure: laogao.cloud

harden-dnssec-stripped 设置为no，控制所有域名都不进行DNSSEC验证。

启用服务器

# 测试配置文件语法
[root@cache ~]# unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
# 启用并启动服务
[root@cache ~]# systemctl enable unbound –now
[root@cache ~]# systemctl status unbound
# 设置防火墙
[root@cache ~]# firewall-cmd –add-service=dns
[root@cache ~]# firewall-cmd –add-service=dns –permanent

客户端测试

[root@client ~]# dig @10.1.8.20 client.laogao.cloud
[root@client ~]# dig @10.1.8.20 student.laogao.cloud
[root@client ~]# dig @10.1.8.20 dns.laogao.cloud

管理缓存

导出缓存

在对DNS问题进行故障排除时，例如过时的资源记录导致的问题，缓存名称服务器的管理员可能需要转储缓存数据。

#导出缓存到stdout
[root@cache ~]# unbound-control dump_cache
START_RRSET_CACHE
;rrset 3597 1 0 8 3
dns.laogao.cloud. 3597 IN A 10.1.8.10
;rrset 3563 1 0 8 3
student.laogao.cloud. 3563 IN CNAME client.laogao.cloud.
;rrset 3557 1 0 7 3
laogao.cloud. 3557 IN NS dns.laogao.cloud.
;rrset 3557 1 0 8 3
client.laogao.cloud. 3557 IN A 10.1.8.11
END_RRSET_CACHE
START_MSG_CACHE
msg client.laogao.cloud. IN A 33152 1 3557 3 1 1 1
client.laogao.cloud. IN A 0
laogao.cloud. IN NS 0
dns.laogao.cloud. IN A 0
msg student.laogao.cloud. IN A 33152 1 3557 3 2 1 1
student.laogao.cloud. IN CNAME 0
client.laogao.cloud. IN A 0
laogao.cloud. IN NS 0
dns.laogao.cloud. IN A 0
msg dns.laogao.cloud. IN A 33152 1 3597 3 1 1 0
dns.laogao.cloud. IN A 0
laogao.cloud. IN NS 0
END_MSG_CACHE
EOF
#导出缓存到文件
[root@cache ~]# unbound-control dump_cache > dns_dump

清空缓存

缓存名称服务器的管理员可能还需要定期从缓存中清除过时的资源记录。 缓存中错误和过时的资源记录会阻止更正的对应项对客户端可用，直到资源记录上的TTL过期为止。 我们可以清除缓存中过时的记录，而不必等待TTL过期。

[root@cache ~]# unbound-control flush student.laogao.cloud

清除zone中所有记录

[root@server ~]# unbound-control flush_zone laogao.cloud

导入缓存

[root@server ~]# unbound-control load_cache < dns_dump

配置缓存名称服务器-Dnsmasq(扩展)

Dnsmasq 介绍

Dnsmasq 是一个集 DNS 缓存、DHCP 、DHCP 中继、PXE一体的软件。多个功能即可以同时实施，也可以独立实施。

• 作为 DNS 缓存服务器，可以通过缓存 DNS 请求来提高对访问过的网址的连接速度。
• 作为 DHCP 服务器，可用于为局域网电脑分配内网ip地址和提供路由。
• 作为 DHCP 中继服务器，为局域网提供 DHCP 中继服务。
• 作为 TFTP 服务器，提供网络 PXE 网络引导。

Dnsmasq 轻量且易配置，适用于个人用户或小型网络。

本部分主要讲解DNS缓存功能。

DNS 用途

应对ISP的DNS劫持（反DNS劫持），输入一个不存在的域名，正常的情况下浏览器是显示无法连接，DNS劫持会跳转到一个广告页面。先随便nslookup 一个不存在的域名，看看ISP商劫持的IP地址。

智能DNS加快解析速度，打开/etc/dnsmasq.conf文件，server=后面可以添加指定的DNS，例如国内外不同的网站使用不同的DNS。

# 国内指定DNS
server=/cn/114.114.114.114
server=/taobao.com/114.114.114.114
server=/taobaocdn.com/114.114.114.114
# 国外指定DNS
server=/google.com/8.8.8.8

屏蔽网页广告，将指广告的URL指定127这个IP，就可以将网页上讨厌的广告给去掉了。

address=/ad.youku.com/127.0.0.1
address=/ad.iqiyi.com/127.0.0.1

指定域名解析到特定的IP上。这个功能可以让你控制一些网站的访问，非法的DNS就经常把一些正规的网站解析到不正确IP上。

address=/freehao123.com/123.123.123.123

管理控制内网DNS，首先将局域网中的所有的设备的本地DNS设置为已经安装Dnsmasq的服务器IP地址，然后配置Dnsmasq的服务器Hosts文件：/etc/hosts，指定域名到特定的IP中。

例如想让局域网中的所有用户访问www.freehao123.com时跳转到192.168.0.2，添加：

192.168.0.2 www.freehao123.com

dnsmasq 解析流程

如果不想用 /etc/hosts 文件做解析，在 /etc/dnsmasq.conf 中加入 no-hosts 语句。

如果不想通过/etc/resolv.conf 文件中DNS查询，在 /etc/dnsmasq.conf 中加入 no-reslov 语句。

dnsmasq 安装

[root@cache ~]# yum install -y dnsmasq

dnsmasq 配置

/etc/dnsmasq.conf 配置文件提供大量的注释说明。 比较重要参数：

• resolv-file，定义dnsmasq从哪里获取上游DNS服务器的地址， 默认值 /etc/resolv.conf 。

• strict-order，指定严格按照 resolv-file 文件中的顺序从上到下进行DNS解析，直到第一个解析成功为止。

• listen-address，定义dnsmasq监听的地址，默认是监控本机的所有网卡上。

• address，自定义解析A记录，例如：address=/long.com/192.168.115.10 访问long.com时的所有域名都会被解析成192.168.115.10

• server，指定使用哪个DNS服务器进行解析。对于不同的网站可以使用不同的域名对应解析。

• bogus-nxdomain，对于任何被解析到此 IP 的域名，响应 NXDOMAIN ，以使其解析失效。可以多次指定，通常用于对于访问不存在的域名，禁止其跳转到运营商的广告站点。

配置示例：

server=/laogao.cloud/10.1.8.10

dnsmasq 启用

# 测试配置文件语法
[root@cache ~]# dnsmasq -test
[root@cache ~]# echo $?
# 启用并启动服务
[root@cache ~]# systemctl enable dnsmasq –now
[root@cache ~]# systemctl status dnsmasq
# 设置防火墙
[root@cache ~]# firewall-cmd –add-service=dns
[root@cache ~]# firewall-cmd –add-service=dns –permanent

客户端测试

[root@client ~]# dig @10.1.8.20 client.laogao.cloud
[root@client ~]# dig @10.1.8.20 student.laogao.cloud
[root@client ~]# dig @10.1.8.20 dns.laogao.cloud

三个以上域名服务器

Linux 处理 DNS 请求时有个限制，在 resolv.conf 中最多只能配置三个域名服务器。作为一种变通方法，可以在 resolv.conf 文件中只保留 localhost 作为域名服务器，然后为外部域名服务器另外创建resolv-file 文件。

# 为 dnsmasq 新建一个域名解析文件
[root@dnsmasq ~]# vim /etc/resolv.dnsmasq.conf
# Google's nameservers, for example
nameserver 8.8.8.8
nameserver 8.8.4.4

# 引用上述文件
[root@dnsmasq ~]# vim /etc/dnsmasq.conf
# 添加如下记录
resolv-file=/etc/resolv.dnsmasq.conf

排故 DNS 问题

名称解析依赖以下几点：

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

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

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

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

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

名称解析来源顺序

DNS是系统最常用的名称解析方法，因此，当发生名称解析错误时，通常会被指责为DNS。 但这不是系统解析主机名和IP地址的唯一方法。其他名称解析方法包括本地/etc/hosts文件和Zeroconf网络。

系统 /etc/nsswitch.conf 文件中的hosts行控制查找主机名的方式。

典型的条目如下所示：

hosts: files dns myhostname

首先在本地/etc/hosts文件中查找，然后执行DNS查找，最后使用nss-myhostname查找本地配置的系统主机名。

我们可以使用glibc-common软件包中的getent命令，按照/etc/nsswitch.conf所指定的主机名称解析顺序执行名称解析。这种解析过程也是大多数应用程序解析的过程。

[root@client ~]# getent hosts server.laogao.cloud
10.1.8.20       server.laogao.cloud server

调查DNS问题

dig工具

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

在以下示例中，将使用名称来调用dig进行解析。 默认情况下，它将查找该名称的A记录。

[root@server ~]# dig servera.laogao.cloud
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> servera.lab.laogao.cloud
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7589
;; 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.laogao.cloud. IN A
;; ANSWER SECTION:
servera.lab.laogao.cloud. 3600 IN A 172.25.250.10
;; Query time: 1 msec
;; SERVER: 10.1.8.20#53(10.1.8.20)
;; WHEN: Fri Mar 05 17:55:55 CST 2021
;; MSG SIZE rcvd: 68

输出说明：结果表明请求的状态为NOERROR，这意味着它已成功完成。 问题部分重述查询，回答部分显示返回的资源记录：servera.lab.laogao.cloud的A记录指向172.25.250.10，并具有生存时间（TTL），缓存3600秒。

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

[user@host ~]$ dig AAAA servera.lab.laogao.cloud
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> AAAA servera.lab.laogao.cloud
;; 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.laogao.cloud. IN AAAA
;; ANSWER SECTION:
servera.lab.laogao.cloud. 3600 IN AAAA fde2:6494:1e09:1::a
servera.lab.laogao.cloud. 3600 IN AAAA fde2:6494:1e09:2::a
;; Query time: 0 msec
;; SERVER: 10.1.8.20#53(10.1.8.20)
;; WHEN: Wed May 13 15:22:01 CDT 2020
;; MSG SIZE rcvd: 101

本示例为主机返回了两个AAAA记录。

[root@server ~]# dig AAAA servera.lab.laogao.cloud
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> AAAA servera.lab.laogao.cloud
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38275
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d6f0231ceac57242ebe19dc4604200e983840c3f1f9a3b75 (good)
;; QUESTION SECTION:
;servera.lab.laogao.cloud. IN AAAA
;; Query time: 16 msec
;; SERVER: 10.1.8.20#53(10.1.8.20)
;; WHEN: Fri Mar 05 17:59:05 CST 2021
;; MSG SIZE rcvd: 80

如果缺少ANSWER SECTION并且ANSWER为0，则查找找不到该名称的该类型的资源记录。 通常，dig使用/etc/resolv.conf中列出的DNS名称服务器。 我们可以通过在命令行上添加一个@，然后加上服务器的名称来指定其他名称服务器。

以下示例在classroom.laogao.cloud上查找laogao.cloud的MX记录。 结果还报告有关名称服务器的一些相关信息，缓存名称服务器也将缓存这些信息。

[root@server ~]# dig @10.1.8.20 mx laogao.cloud
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> @10.1.8.20 mx laogao.cloud
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15684
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2af577a35598d62d58d9f5e7604201ebf3383377df6034f6 (good)
;; QUESTION SECTION:
;laogao.cloud. IN MX
;; ANSWER SECTION:
laogao.cloud. 86400 IN MX 10 dns.laogao.cloud.
;; AUTHORITY SECTION:
laogao.cloud. 86400 IN NS dns.laogao.cloud.
;; ADDITIONAL SECTION:
dns.laogao.cloud. 86400 IN A 172.25.254.254
;; Query time: 3 msec
;; SERVER: 10.1.8.20#53(10.1.8.20)
;; WHEN: Fri Mar 05 18:03:23 CST 2021
;; MSG SIZE rcvd: 124

如果getent的结果与dig产生的结果不同，则可以清楚地表明，是DNS以外的其他原因导致了意外的名称解析结果。

网络连接问题

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

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

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

如果涉及防火墙，则必须确保客户端可以与名称服务器UDP和TCP上53端口通信。 如果名称服务器只允许端口53/UDP上的流量通过，不允许端口53/TCP上的流量通过，则当响应的大小超过512字节（支持DNS扩展机制（EDNS）的服务器为4096字节）时，解析器必须从UDP切换到TCP并重试查询，我们会看到截断通知以及主机无法访问的错误：

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

dig命令可以指定tcp或vc选项，强制使用TCP查询记录，而不是默认行为：先使用UDP，然后仅对于大响应才使用TCP。

[user@host ~]$ dig +tcp A laogao.cloud

DNS响应代码

DNS客户端与服务器之间的通信成功，dig会生成详细的输出。 dig输出的HEADER部分中status字段报告DNS服务器生成的响应代码，以响应客户端的查询。

示例：

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

• NOERROR，表示在解析查询时未遇到任何错误，但不能保证没有DNS问题。 例如，因为缓存的原因，响应中的DNS记录可能与预期结果不匹配的情况。
• SERVFAIL，常见原因是DNS服务器无法与对所查询名称具有权威性的名称服务器进行通信：可能是权威名称服务器不可用，也可能是DNS服务器与具有权威性的名称服务器之间网络问题引起的。例如网络路径问题或网络路径中任何跃点处的防火墙规则。 在这种情况下，dig可以使用+trace选项查看名称服务器的迭代查询的结果，从根名称服务器开始。

[kiosk@foundation0 ~]$ dig +trace www.baidu.com
; <<>> DiG 9.11.13-RedHat-9.11.13-3.el8 <<>> +trace www.baidu.com
;; global options: +cmd
. 454534 IN NS d.root-servers.net.
. 454534 IN NS j.root-servers.net.
. 454534 IN NS b.root-servers.net.
. 454534 IN NS h.root-servers.net.
. 454534 IN NS g.root-servers.net.
. 454534 IN NS k.root-servers.net.
. 454534 IN NS i.root-servers.net.
. 454534 IN NS c.root-servers.net.
. 454534 IN NS l.root-servers.net.
. 454534 IN NS e.root-servers.net.
. 454534 IN NS m.root-servers.net.
. 454534 IN NS f.root-servers.net.
. 454534 IN NS a.root-servers.net.
. 454534 IN RRSIG NS 8 0 518400 20210317050000 20210304040000
42351 . HxjaNY4Tov7w+gpegYYXzD8P11ykXhmKeNTlTjV8O/sC2yAbefqYdi6B
YQQoocoCGqugJ9eFCRqMoEQi8QHSWCp6hpstazPBueAek4yFRpTUwCpH
1tPjR3oyLBDIBKxB7/Os0m40Rk7NfR3chEy4ai4bCkeFSggDAbRjZwgk
V8ZpPLvZWGX/GhlPiUbc5odtkpppJHo/FV7OhWA0Jmd2iVIMOsmutbvT
KSU8HzOoNHgaRGKIZcAeOTp/j/9TCL8pW8l/AZzbnWM2avZy+5wlVn2k
M3NUX5K3MXXNfBQBUy+UYAPqeh7/EhrlChkxjCEHDOIq9MCDXAVAQfo2 zcImDA==
;; Received 1125 bytes from 172.25.254.250#53(172.25.254.250) in 1 ms
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 86400 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20210318010000
20210305000000 42351 .
Y3nBy7cGonYK3vgL+u9zrDtqzqL6OlUUUhBM+iHkoQ7TNnp7QXKTjURN
H9ykExpcWTDDdaXf+k6ParCzDwYoGr5KGGM0c4csz2jj6torcNHvhFll
3tkqYOatpcV7gm+sNmC4B/iNeABGvoSRT326EZaGe43vIT1O2ftyAdCW
Rom7a+CoqiN7bcHhU7K4kUxcE6dVW5AJnCnm/STBnD9Kco6tv8uyjvBE
YJUsgqGIb59J2OfvwccgqsVankZCBgyI8BLTfbsCPhe53gSNFK2CjsOd
PO69P3adYFeeOQYOIOXfYtFaVLV/FHIuvlANfBMp3Lgg5tfQa4d51llR QdVzvQ==
;; Received 1201 bytes from 192.33.4.12#53(c.root-servers.net) in 251 ms
baidu.com. 172800 IN NS ns2.baidu.com.
baidu.com. 172800 IN NS ns3.baidu.com.
baidu.com. 172800 IN NS ns4.baidu.com.
baidu.com. 172800 IN NS ns1.baidu.com.
baidu.com. 172800 IN NS ns7.baidu.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 –
CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400
20210309054120 20210302043120 58540 com.
xu4zFDXunvf8TEDRn7OhqULrfIfbeUof5gXCAgN5gY80ZcSZDKZiqeiX
RGNqLnwSLnN5fU3phijv+XK2LPDkL9AeYpw+w40qxcGXAuuS3aM5rXpz
8/g4Y/HK76tixxsdegWw2Cm7gLH/MSLPgzfdKGs40hS6ecPRaDa1cAQq
JbJWBF1cO0RgctIrpFXjMjIOo8eHfboPYtexQfNuoJZW0A==
HPVUSBDNI26UDNIV6R0SV14GC3KGR4JP.com. 86400 IN NSEC3 1 1 0 –
HPVVN3Q5E5GOQP2QFE2LEM4SVB9C0SJ6 NS DS RRSIG
HPVUSBDNI26UDNIV6R0SV14GC3KGR4JP.com. 86400 IN RRSIG NSEC3 8 2 86400
20210309071843 20210302060843 58540 com.
IKqXZ7K/eIC6usypUOei3ty9zqlUzNIu1+4xyo0wMpdxQNavLtpGO7vq
4TadkZpNWGV4U3TrzVGEo7o4suM+l3KyVRh2KwOAfrz2kWvJOIS4yvDD
SjA4ftcxNH/4eIuLlpFO7LUkWlUwwxJeUwZNXsCv5wgxKPk7EMZY5Tt3
Xj+BZARS8D6/m4SXdkCX1QmSJ/ab+36A9KT056w4X8+yQg==
;; Received 761 bytes from 192.33.14.30#53(b.gtld-servers.net) in 229 ms
www.baidu.com. 1200 IN CNAME www.a.shifen.com.
a.shifen.com. 1200 IN NS ns3.a.shifen.com.
a.shifen.com. 1200 IN NS ns1.a.shifen.com.
a.shifen.com. 1200 IN NS ns4.a.shifen.com.
a.shifen.com. 1200 IN NS ns2.a.shifen.com.
a.shifen.com. 1200 IN NS ns5.a.shifen.com.
;; Received 239 bytes from 14.215.178.80#53(ns4.baidu.com) in 35 ms

• NXDOMAIN，表示未找到与查询名称关联的记录。

如果查询针对的名称服务器不具有权威性，则该服务器的缓存可能包含该名称的负缓存。用户可以等待服务器中负缓存记录过期，或者向服务器管理员提交请求从服务器缓存中清除该名称。从缓存中删除该名称后，服务器将查询权威名称服务器以接收该名称的当前资源记录。

另一种情况是在查询包含孤立的CNAME记录。在CNAME记录中，记录右侧的名称（规范名称）应指向包含A或AAAA记录的名称。如果这些关联的记录不存在，则CNAME记录中的规范名称将被孤立。

最后一种情况是权威服务器中确实没有对应记录。

• REFUSED，表示DNS服务器的策略阻止客户端的查询。 通常在DNS服务器上实施策略限制，以限制哪些客户端可以进行递归查询和区域传输请求。 导致REFUSED返回码的一些常见原因是客户端配置为查询错误的DNS服务器或DNS服务器配置错误，导致有效的客户端请求被拒绝。

Zone数据问题

有时，名称解析问题是由于权威名称服务器上区域中错误配置引起的。当我们管理区域文件时，诊断这些问题的能力就显得尤为重要。

得到不同的答案：DNS 轮询

一个名称可以在DNS中具有多个记录。 这使我们可以配置轮询DNS。DNS轮询是一种简单、低成本的负载平衡机制，实现多个主机之间网络资源负载均衡。

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

错误创建此配置时会出现问题。 例如，权威名称服务器的管理员打算更改主机的A记录：为主机添加了第二条A记录，同时没有删除旧的A记录。 如果旧的A记录的IP地址已退役，但仍在DNS中，则DNS轮询的负载分配效应将导致大约一半的客户端获得过时的A记录。

反向查询失败：缺少PTR记录

• 许多网络服务使用DNS对来自客户端的传入连接执行反向查找。 DNS中缺少PTR记录，不同的网络服务会导致不同问题。
• 默认情况下，SSHD对连接的客户端IP执行反向查找。 没有PTR记录会导致建立这些连接的延迟。 许多邮件服务器采用反向DNS查找来连接客户端IP，以防御恶意电子邮件客户端。 实际上，许多邮件服务器被配置为拒绝客户端的IP连接，而DNS中的PTR查询无法解决该问题。

因此，网络服务的管理员需要了解这些服务不仅针对正向查询，而且还针对反向DNS查找的要求。

获取记录不存在的响应

如果已将记录从区域中删除，并且在查询记录时仍收到响应：

• 首先确认没有从缓存数据中回答查询。
• 如果通过dig输出中aa标志的存在确认答案是权威的，则可能的原因是该区域中存在通配符（*）记录。

*.laogao.cloud. IN A 172.25.254.254

通配符记录可以用作名称不存在的给定类型的所有查询的全部内容。 保留先前的通配符记录后，如果先前存在于server.laogao.cloud的A记录被删除，则查询名称仍将成功，并且将在其位置提供通配符A记录中的IP地址。

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

在区域文件中，短主机名将通过附加区域名称而自动扩展为FQDN。 要在区域文件中指示FQDN，名称必须以“.”结尾，例如server.laogao.cloud. 。 不这样做可能导致不同的问题，取决于记录类型。 例如，在NS记录的特定于类型的数据部分中犯的这种错误有可能使整个区域失去能力，而在MX记录中犯的错误可能导致域的电子邮件传递完全停止。

识别循环的CNAME记录

应当避免指向CNAME记录的CNAME记录，以减少DNS查找效率低下的情况。 造成此问题的另一个原因是可能创建无法解析的CNAME循环，例如：

test.laogao.cloud. IN CNAME lab.laogao.cloud.
lab.laogao.cloud. IN CNAME test.laogao.cloud.

具有孤立CNAME的CNAME记录将导致NXDOMAIN状态，而循环CNAME记录将返回NOERROR状态。

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

有时，我们可能会发现主域名服务器在其区域内为DNS查询提供的答案与其他权威域名服务器不同。这通常是由于我们的从服务器没有从主服务器上获取区域最新版本引起的。 考虑以下问题：

• 从名称服务器是否具有区域的最新版本？查看SOA记录中的序列号。

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

• 主服务器和从服务器之间的通信是否被网络问题或防火墙阻止？

• 主服务器是否允许从服务器执行区域传输？对于BIND，查看主服务器的allow-transfer指令。

• 从服务器是否配置了该区域的正确主服务器？