14.DNS服务器

DNS服务介绍

DNS(Domain Name System,域名系统)服务是一种用于将域名转换为IP地址的分布式数据库服务。

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

DNS层次结构:

  • 根域:DNS层次结构最顶层,使用独立的"."表示
  • 顶级域:DNS层级结构第二层,如.com、.net、.org等域
  • 二级域:DNS层次结构第三层,如bqbro.cloud、baidu.com等域
  • 以此类推。

DNS层次结构如图所示:

image-20250806184510651

DNS相关术语

Domain

Domain是 resource records (资源记录)的集合,是一个涵盖不同层级的统称,它可以包含二级域,也可以是二级域本身,甚至可以是更高级别的域(如顶级域)或更低级别的子域。是对整个域名系统中 “可被解析的名称” 的统称,既可以指完整域名(如 example.com 或 blog.example.com),也可以指某个层级的域(如 “example.com 这个域名包含二级域 example 和顶级域 .com”)。Domain该集合以通用名结尾,表示DNS命名空间的整个子树,如bqbro.cloud、ac.bqbro.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.bqbro.cloud是bqbro.cloud的子域,而bqbro.cloud是**.com的子域。 我们也可以将bqbro.cloud称为第二级域,并将lab.bqbro.cloud称为第三级域。 Subdomain的关键点是在于它是某个父域的下级域,符合"从属关系"**的判断。

Zone

Zone是特定名称服务器直接负责的域。它可能是整个域,也可能只是域的一部分。Zone可以将部分或全部子域都委派给另一个名称服务器或多个名称服务器。 简单来说,它是 DNS 服务器 “负责管辖” 的一块域名区域。

示例:

  • 假设 example.com 是一个 Zone,其 Zone 文件中可能包含:
    • www.example.com → 192.168.1.1(A 记录)
    • mail.example.com → 192.168.1.2(A 记录)
    • example.com 的 MX 记录指向 mail.example.com
  • 如果将 shop.example.com 委派给另一个 DNS 服务器,则 shop.example.com 成为独立 Zone,原 example.com 的 Zone 文件不再包含其解析记录。

DNS查询

主机的 DNS 查询主要有两种方式:递归查询迭代查询,二者的核心区别在于 “谁负责完成整个查询流程”。下面详细说明两种方式的特点、适用场景及流程差异:

1. 递归查询(Recursive Query)
  • 定义:客户端向 DNS 服务器发送查询请求时,要求服务器必须返回最终结果(要么找到 IP 地址,要么返回 “查询失败”),客户端无需参与中间过程,只需等待结果。
  • 核心特点
    • 客户端 “甩锅”:把整个解析任务交给服务器,自己只等答案。
    • 服务器 “包办”:若服务器本地无缓存,会主动向其他 DNS 服务器(根、顶级域、权威服务器等)迭代查询,直到获取结果。
  • 适用场景
    通常是客户端(如电脑、手机、浏览器)向本地 DNS 服务器发起的查询(例如你在浏览器输入域名时,设备会向本地 DNS 服务器发送递归查询)。
  • 流程示例
    客户端 → 本地 DNS 服务器(递归请求) → 本地 DNS 服务器自行迭代查询根、顶级域、权威服务器 → 本地 DNS 服务器将最终 IP 返回给客户端。
2. 迭代查询(Iterative Query)
  • 定义:DNS 服务器之间的查询方式,接收查询的服务器只返回自己知道的信息(可能是最终结果,也可能是 “下一步该查询的服务器地址”),由发起查询的一方自行继续查询,直到获取结果。
  • 核心特点
    • “分步问路”:每个服务器只提供 “局部信息”,不负责全程处理。
    • 发起方 “主动推进”:需要自己根据返回的线索,依次向其他服务器查询。
  • 适用场景
    通常是DNS 服务器之间的查询(例如本地 DNS 服务器向根服务器、顶级域服务器发起的查询)。
  • 流程示例
    本地 DNS 服务器 → 根服务器(迭代请求) → 根服务器返回 “.com 顶级域服务器地址” → 本地 DNS 服务器 → .com 顶级域服务器(迭代请求) → 返回 “example.com权威服务器地址” → 本地 DNS 服务器 → example.com权威服务器 → 返回最终 IP。
递归查询和迭代查询的关键区别
对比维度 递归查询 迭代查询
发起方 客户端 → 本地 DNS 服务器 DNS 服务器之间(如本地 DNS → 根服务器)
责任方 接收请求的服务器负责全程解析 发起查询的服务器自行完成后续查询
结果返回 必须返回最终答案(成功 / 失败) 返回已知信息(结果或下一跳地址)
典型场景 用户设备查询本地 DNS 本地 DNS 查询根 / 顶级域 / 权威服务器

DNS resource records(资源记录)

DNS 资源记录(DNS Resource Records,RR) 是存储在 DNS 服务器中的核心数据,用于定义域名与 IP 地址、服务位置等信息的映射关系。每个资源记录都有固定的格式和用途,共同构成了域名系统的 “数据库”。

所有资源记录都遵循统一的基本格式(以 BIND 配置文件为例):
域名 [TTL] 类别 类型 数据

  • 域名:记录所关联的域名(如 example.comwww.example.com)。
  • TTL(Time to Live):记录在缓存中的存活时间(单位秒,可选,默认继承区域配置)。
  • 类别:几乎都是 IN(Internet,互联网类别),其他类别极少使用。
  • 类型:记录的类型(核心字段,决定数据格式和用途)。
  • 数据:具体的记录内容(格式因类型而异)。
常见的 DNS 资源记录类型
1. A 记录(Address Record)
  • 用途:将域名映射到 IPv4 地址(最常用的记录类型)。
  • 数据格式:IPv4 地址(如 192.168.1.1)。
  • 示例
    www.example.com. 3600 IN A 104.21.8.174
    表示 www.example.com 对应 IPv4 地址 104.21.8.174,缓存 1 小时(3600 秒)。
2. AAAA 记录(IPv6 Address Record)
  • 用途:将域名映射到 IPv6 地址(对应 IPv6 网络)。
  • 数据格式:IPv6 地址(如 2001:0db8:85a3:0000:0000:8a2e:0370:7334)。
  • 示例
    www.example.com. 3600 IN AAAA 2001:db8::1
3. CNAME 记录(Canonical Name Record,别名记录)
  • 用途:为域名设置别名,将一个域名指向另一个域名(而非直接指向 IP)。
  • 数据格式:目标域名(需以点 “.” 结尾,如 example.com.)。
  • 示例
    blog.example.com. 3600 IN CNAME www.example.com.
    表示 blog.example.comwww.example.com 的别名,访问前者会自动解析到后者的 IP。
  • 注意:CNAME 记录不能与其他记录(如 A、MX)共存于同一域名(避免冲突)。
4. MX 记录(Mail Exchange Record,邮件交换记录)
  • 用途:指定接收域名邮件的邮件服务器地址,用于邮件投递。
  • 数据格式:优先级(0-65535,数字越小优先级越高)+ 邮件服务器域名。
  • 示例
    example.com. 3600 IN MX 10 mail.example.com.
    example.com. 3600 IN MX 20 backup.mail.example.com.
    表示 example.com 的邮件优先由 mail.example.com 接收,若其不可用,再由 backup.mail.example.com 接收。
  • 注意:MX 记录指向的必须是域名(而非 IP),且该域名需有对应的 A/AAAA 记录。
5. NS 记录(Name Server Record,域名服务器记录)
  • 用途:指定管理某个域名(或子域)的权威 DNS 服务器,是 DNS 层级结构的核心。
  • 数据格式:权威 DNS 服务器的域名。
  • 示例
    example.com. 86400 IN NS ns1.example.com.
    example.com. 86400 IN NS ns2.example.com.
    表示 example.comns1.example.comns2.example.com 这两台服务器负责解析。
  • 注意:顶级域(如 .com)的 NS 记录由 ICANN 管理,二级域(如 example.com)的 NS 记录由域名注册商设置。
6. TXT 记录(Text Record,文本记录)
  • 用途:存储任意文本信息,常用于域名验证、反垃圾邮件(SPF/DKIM/DMARC)等。
  • 数据格式:字符串(用引号包裹,支持多行)。
  • 示例
    • 域名所有权验证:example.com. 3600 IN TXT "google-site-verification=abc123"
    • 反垃圾邮件(SPF):example.com. 3600 IN TXT "v=spf1 ip4:192.168.1.1 ~all"
7. SOA 记录(Start of Authority Record,起始授权记录)
  • 用途:每个 DNS 区域(如 example.com)的 “元数据”,包含区域的权威信息(如主服务器、管理员邮箱、序列号等),是区域文件的第一条记录。

  • 数据格式
    主DNS服务器域名 管理员邮箱 序列号 刷新时间 重试时间 过期时间 最小TTL

  • 示例

    example.com. 86400 IN SOA ns1.example.com. admin.example.com. ( 2023100101 3600 1800 604800 86400 )
    
    • 主服务器:ns1.example.com
    • 管理员邮箱:admin@example.com(记录中用 “.” 代替 “@”)
    • 序列号:2023100101(更新记录时需递增,用于主从服务器同步)
    • 刷新时间:3600 秒(从服务器多久查询一次主服务器更新)
    • 重试时间:1800 秒(刷新失败后多久重试)
    • 过期时间:604800 秒(从服务器在主服务器不可用时,最多缓存记录多久)
    • 最小 TTL:86400 秒(未指定 TTL 时的默认值)
其他常见记录类型
  • PTR 记录:反向解析记录,将 IP 地址映射到域名(如 1.1.168.192.in-addr.arpa. IN PTR example.com.,用于 IP 反查域名)。
  • SRV 记录:服务定位记录,指定特定服务(如 VoIP、游戏服务器)的地址和端口(格式:优先级 权重 端口 目标域名)。
  • CNAME 与 A 记录的选择:若需要将多个域名指向同一 IP,用 CNAME 更灵活(IP 变更时只需改一次 A 记录);但根域名(如 example.com)通常不建议用 CNAME(可能与 MX 等记录冲突)。
总结

DNS 资源记录是域名解析的 “数据基础”,不同类型的记录各司其职:A/AAAA 记录负责 “域名→IP” 的核心映射,CNAME 提供别名,MX 保障邮件投递,NS 定义权威服务器,SOA 管理区域同步。理解这些记录的作用,有助于排查域名解析问题(如 “网站打不开”“邮件发不出” 等)。

配置权威名称服务器

权威名称服务器(Authoritative Name Server)是 DNS(域名系统)架构中负责直接提供特定域名解析信息的服务器,它对自己所管理的域名具有 “最终解释权”,是域名解析的 “权威来源”。

核心特点

  • 权威性:对于它所管辖的域名(如example.com),权威名称服务器存储着该域名的官方 DNS 资源记录(如 A 记录、MX 记录等),这些记录是域名所有者配置的官方信息,其他服务器会以它的数据为准。
  • 无缓存依赖:权威服务器不会从其他服务器查询域名信息,而是直接返回自己存储的原始数据(除非配置了辅助服务器,从主服务器同步数据)。
  • 分工明确:每个域名至少对应一台权威服务器,负责解析该域名及其子域名(如www.example.commail.example.com)。

作用

当递归 DNS 服务器(如用户本地运营商的 DNS 服务器)收到域名解析请求时,会逐级查询,最终找到该域名的权威名称服务器,然后从它那里获取准确的 IP 地址或其他解析信息,再返回给用户设备。

例如,当查询www.baidu.com时,递归服务器会先找到.com顶级域的权威服务器,再通过它找到baidu.com的权威服务器,最终从baidu.com的权威服务器获取www.baidu.com对应的 IP 地址。

分类

  • 主权威服务器(Master):存储域名资源记录的原始文件,管理员直接在此配置和修改记录。
  • 辅助权威服务器(Slave):从主权威服务器同步资源记录,作为备份,提高解析可靠性和负载均衡能力。

简单来说,权威名称服务器就像域名的 “官方登记处”,所有关于该域名的解析信息都以它为准,是 DNS 解析中提供最终答案的关键角色。

安装 BIND

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

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

软件包说明:

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

配置 BIND

named主要配置文件是**/etc/named.conf**。 该文件控制BIND的基本操作,由root用户(named组)拥有,具有八进制权限0640,并且具有named_conf_t SELinux类型。

配置文件还指定了每个区域的配置文件位置,这些文件通常保存在**/var/named**中。

配置DNS服务器需要执行以下步骤:

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

在/etc/named.conf文件的开头,可以使用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; };
配置 named 侦听的IP地址

我们可以在/etc/named.conf文件options块中指定许多全局设置。listen-onlisten-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.bqbro.cloud bqbro.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; };
};
......

配置说明:

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

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

[root@server ~]# vim /etc/named.conf
......
# 最后添加如下内容
zone "bqbro.cloud" IN {
    type master;
    file "bqbro.cloud.zone";
};
zone "8.1.10.in-addr.arpa" IN {
    type master;
    file "10.1.8.zone";
};

配置说明:

  • type,指定服务器角色。
  • file,指定相对路径名。 相对路径由 options 块中的 directory 指令设置。
创建区域文件
[root@server ~]# touch /var/named/bqbro.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
编辑区域文件格式

区域文件可以以**$TTL**指令开头,该指令为任何未列出的资源记录设置默认的TTL。 这使我们可以一次为许多资源记录调整TTL。 无需编辑整个文件。 如果TTL是数字,则以秒为单位。

$TTL 3600

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

  • M表示分钟(1M为60)
  • H小时(1H是3600)
  • D天(1D为86400)
  • W数周(1W是604800)

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

image-20250806204400400

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

示例:bqbro.cloud域

[root@server ~]# vim /var/named/bqbro.cloud.zone
$TTL 3600
@ IN SOA dns.bqbro.cloud. root.bqbro.cloud. (
    42 ; serial
    3H ; secondary refresh
    15M ; secondary retry
    1W ; secondary timeout
    15M ; minimum cache TTL for negative answers
)
               IN NS dns.bqbro.cloud.
dns            IN A 10.1.8.10
server         IN A 10.1.8.10
student        IN CNAME client.bqbro.cloud.
client         IN A 10.1.8.11
www         30 IN A 10.1.8.200
@              IN MX 10 mail.bqbro.cloud.
mail           IN A 10.1.8.253

示例说明:

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

因此,在前面的示例中:

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

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

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

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

示例:8.1.10.inaddr.arpa区域

[root@server ~]# vim /var/named/10.1.8.zone
$TTL 3600
@ IN SOA dns.bqbro.cloud. root.bqbro.cloud. (
    42 ; serial
    3H ; secondary refresh
    15M ; secondary retry
    1W ; secondary timeout
    15M ; minimum cache TTL for negative answers
)
               IN NS dns.bqbro.cloud.
10             IN PTR server.bqbro.cloud.
10             IN PTR dns.bqbro.cloud.
11             IN PTR client.bqbro.cloud.
11             IN PTR student.bqbro.cloud.
200            IN PTR www.bqbro.cloud.
253            IN PTR mail.bqbro.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.bqbro.cloud.子域委派给ns1.support.bqbro.cloud.ns2.support.bqbro.cloud.

    support IN NS ns1.support.bqbro.cloud.
            IN NS ns2.support.bqbro.cloud.
    

如果这些名称服务器的名称本身不在support.bqbro.cloud域中,必须在父域bqbro.cloud中为每个子域的名称服务器添加glue (粘合)记录(A或AAAA资源记录):

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

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

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

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

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

确认区域正确加载后,请验证区域内容是否正确。使用host -l DOMAINdig -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 student.bqbro.cloud
[root@client ~]# ping dns.bqbro.cloud

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

[root@client ~]# getent hosts student
10.1.8.11       client.bqbro.cloud student.bqbro.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 bqbro.cloud NS
# 查询MX记录 
[root@client ~]# dig @10.1.8.10 bqbro.cloud MX
# 查询A记录 
[root@client ~]# dig @10.1.8.10 student.bqbro.cloud
# 查询PTR记录
[root@client ~]# dig @10.1.8.10 -x 10.1.8.100
递归查询

以dns服务器为中心进行查询,最终结果返回给客户端。

image-20240813202031819

迭代查询

以客户端为中心进行查询,获取最终结果。

递归查询使用选项 +trace

[root@client ~]# dig +trace @server www.baidu.com

image-20250806204945475
感谢观看,如涉及版权问题请联系作者处理!!!!1

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐