resolvectl命令详解

resolvectl命令详解

resolvectl 是现代 systemd 发行版中管理 DNS 解析的核心命令行工具。它用于查询域名、IP 地址和 DNS 资源记录，并与 systemd-resolved 服务交互，检查或动态配置解析器行为。

🔄 从 systemd-resolve 到 resolvectl

在 systemd v239 之前，对应的命令是 systemd-resolve。该命令已被重命名为 resolvectl，并改为基于动词（verb-based）的子命令接口。旧名称 systemd-resolve 通常仍作为符号链接保留，以实现向后兼容，但已不推荐使用。

🧩 基本语法与选项

基本语法为 resolvectl [OPTIONS...] {COMMAND} [NAME...]。常用选项如下：

选项	说明
-4 / -6	仅查询 IPv4 或仅查询 IPv6 地址
-i INTERFACE	指定查询使用的网络接口
-p PROTOCOL	指定查询协议，如 dns、llmnr、mdns 等
-t TYPE	指定 DNS 资源记录类型（如 A、AAAA、MX）
-c CLASS	指定 DNS 查询类别

⚙️ 核心子命令详解

🔍 查询类命令

query HOSTNAME|ADDRESS...

默认行为是将参数作为主机名解析，返回其 IPv4/IPv6 地址；如果参数是 IP 地址，则执行反向解析以获取主机名。结合 --type= 可以查询特定类型的 DNS 记录，使用 --json= 则能以 JSON 格式输出结果。

# 查询域名 IP 地址
resolvectl query example.com

# 查询 MX 记录
resolvectl query --type=MX example.com

# 反向解析 IP
resolvectl query 8.8.8.8

service、openpgp、tlsa 等

resolvectl 还支持查询 DNS-SD 服务、OpenPGP 密钥和 TLSA 证书等特殊记录类型，例如 service 可用于发现网络中的打印服务或 SRV 记录。

📊 状态与诊断

status [LINK...]

显示系统全局及各网络接口当前生效的 DNS 设置，包括 DNS 服务器、搜索域、DNSSEC 状态等。如果不指定子命令，status 是默认行为。

# 查看全局和所有接口的 DNS 状态
resolvectl status

# 仅查看特定接口（如 eth0）的状态
resolvectl status eth0

statistics

显示解析器统计信息，包括缓存大小、查询计数以及 DNSSEC 验证情况等。

monitor

以实时流的方式持续输出本地客户端发起的 DNS 查询及其结果，对于诊断解析问题非常有用。

🧹 缓存管理

flush-caches

清除 systemd-resolved 的所有本地 DNS 缓存。当 DNS 记录变更或遇到解析异常时，可执行此命令。

sudo resolvectl flush-caches

reset-server-features

重置解析器从 DNS 服务器学到的特性信息（如 EDNS0 支持情况），通常在排查服务器兼容性问题时使用。

🛠️ 动态配置（临时生效）

以下命令用于在运行时调整接口的 DNS 配置，重启后会失效。如需持久化，应通过 NetworkManager 或 systemd-networkd 的配置文件进行设置。

dns [LINK [SERVER...]]

为指定接口设置 DNS 服务器。不提供参数时，显示当前设置。

# 将 eth0 的 DNS 设置为 Cloudflare
sudo resolvectl dns eth0 1.1.1.1 1.0.0.1

domain [LINK [DOMAIN...]]

设置接口的搜索域或路由域。域名前加 ~ 可将其设为仅路由域（不用于搜索）。

dnsovertls [LINK [MODE]]

启用或禁用接口的 DNS over TLS（DoT）功能。MODE 可取 yes、no 或 allow-downgrade

sudo resolvectl dnsovertls eth0 yes

dnssec [LINK [MODE]]

设置接口的 DNSSEC 验证模式。

nta [LINK [DOMAIN...]]

配置某个接口的负信任锚（Negative Trust Anchor），用于临时禁用特定域名的 DNSSEC 验证。

💡 实用示例速查

场景	命令
快速解析域名	resolvectl query example.com
查看 DNS 配置	resolvectl status
清除 DNS 缓存	sudo resolvectl flush-caches
临时更换接口 DNS	sudo resolvectl dns eth0 8.8.8.8
实时监控 DNS 查询	sudo resolvectl monitor
查看解析统计	resolvectl statistics

⚠️ 注意事项

1. 持久化配置 ：resolvectl 的动态配置命令仅对当前运行周期有效。永久配置需修改 /etc/systemd/resolved.conf 或对应的网络管理工具配置。

2. /etc/resolv.conf 符号链接 ：在 systemd-resolved 环境中，/etc/resolv.conf 通常应是指向 /run/systemd/resolve/stub-resolv.conf 的符号链接，以确保查询请求被正确导向解析器。

3. 权限要求 ：修改配置、清空缓存等操作通常需要 root 权限（使用 sudo）。

resolvectl和D-Bus接口：org.freedesktop.resolve1.Manager的关系

resolvectl 与 org.freedesktop.resolve1.Manager 的关系非常直接：resolvectl 是 systemd-resolved 服务的官方命令行前端，而 org.freedesktop.resolve1.Manager 正是 systemd-resolved 通过 D-Bus 暴露给外界的核心管理接口。 换句话说，resolvectl 的绝大多数操作，最终都是通过系统 D-Bus 调用 org.freedesktop.resolve1.Manager 上的方法或读取其属性来完成的。

🧱 服务端：systemd-resolved 与 org.freedesktop.resolve1.Manager

systemd-resolved 是实际负责 DNS 解析、缓存、DNSSEC 验证等工作的守护进程。它在系统总线上注册了服务名 org.freedesktop.resolve1，并在对象路径 /org/freedesktop/resolve1 下暴露接口 org.freedesktop.resolve1.Manager。

这个 Manager 接口提供了：

• 方法 ：如 ResolveHostname()、ResolveAddress()、FlushCaches()、SetLinkDNS()、SetLinkDomains() 等。

• 属性：如全局 DNS 服务器、搜索域、DNSSEC 模式、缓存统计等。

• 信号：如链路添加/移除、属性变化等，用于通知客户端。

此外，每个网络接口还会在 /org/freedesktop/resolve1/link/_X 路径下暴露 org.freedesktop.resolve1.Link 接口，用于查询和设置单个链路的解析参数。

🖥️ 客户端：resolvectl 的角色

resolvectl 本身不实现 DNS 协议 ，也不直接读写 /etc/resolv.conf 来解析域名。它是一个纯粹的 D-Bus 客户端工具，负责：

1. 解析命令行参数；

2. 将请求转换为对 org.freedesktop.resolve1.Manager（以及 Link 接口）的 D-Bus 调用；

3. 将返回的结果格式化为人类可读的输出。

因此，如果没有 systemd-resolved 在运行，或者 D-Bus 服务不可用，resolvectl 会报错，无法工作。

🔄 子命令与 D-Bus 方法的对应关系

resolvectl 子命令	底层调用的 D-Bus 方法/属性（org.freedesktop.resolve1.Manager）
query	ResolveHostname()、ResolveAddress()、ResolveService() 等
status	读取 Manager 及各个 Link 对象的属性
statistics	读取缓存统计相关属性
flush-caches	FlushCaches()
reset-server-features	ResetServerFeatures()
dns	SetLinkDNS()
domain	SetLinkDomains()
dnsovertls	SetLinkDNSOverTLS()
dnssec	SetLinkDNSSEC()
nta	SetLinkDNSSECNegativeTrustAnchors()
monitor	订阅 Manager 和 Link 接口的信号，实时输出

🔐 权限与 Polkit

修改解析配置（如 SetLinkDNS、FlushCaches 等）通常需要 root 权限。resolvectl 在调用这些方法时，systemd-resolved 会通过 Polkit 进行授权检查，因此普通用户直接执行会提示权限不足，需要使用 sudo。

🔍 如何直接观察这层关系

你可以用 busctl 直接内省这个 D-Bus 接口，看到 resolvectl 所依赖的方法和属性：

busctl introspect org.freedesktop.resolve1 /org/freedesktop/resolve1
busctl introspect org.freedesktop.resolve1 /org/freedesktop/resolve1/link/_1

也可以直接通过 busctl call 调用 ResolveHostname 等方法，而不经过 resolvectl。这证明了 resolvectl 只是一个方便的封装层。

💡 总结

• org.freedesktop.resolve1.Manager 是 systemd-resolved 提供的 D-Bus 管理 API，是服务端接口。

• resolvectl 是 该 API 的官方命令行客户端，负责把用户命令翻译成 D-Bus 调用并展示结果。

• 两者是客户端-服务端 关系，通过系统 D-Bus 解耦。其他程序也可以直接使用这个 D-Bus 接口，而不必调用 resolvectl。

resolvectl和systemd-resolved是如何通讯的？

resolvectl 与 systemd-resolved 之间的通讯，完全通过系统 D-Bus 进行。resolvectl 是一个无状态的客户端 ，它自身不实现解析逻辑，而是将你在命令行输入的所有操作，翻译成对 systemd-resolved 守护进程的 D-Bus 方法调用，并接收其返回的结果。

📡 通讯核心：D-Bus 接口 org.freedesktop.resolve1

systemd-resolved 在 D-Bus 系统总线上注册了服务名 org.freedesktop.resolve1，并在对象路径 /org/freedesktop/resolve1 上暴露了 org.freedesktop.resolve1.Manager 接口。这个接口就是你与解析服务交互的"控制面板"。

🔄 通讯流程拆解

一次典型的通讯流程，可以拆解为以下几步：

1. 建立连接 ：resolvectl 启动后，会连接到系统 D-Bus，并通过服务名 org.freedesktop.resolve1 找到 systemd-resolved 进程-。

2. 调用方法 ：根据你输入的子命令，resolvectl 会向 org.freedesktop.resolve1.Manager 接口发送具体的 D-Bus 方法调用。例如：

   • 执行 resolvectl query example.com，会调用 ResolveHostname() 方法。

   • 执行 sudo resolvectl dns eth0 1.1.1.1，会调用 SetLinkDNS() 方法。

3. 接收响应 ：systemd-resolved 处理完请求后，通过 D-Bus 将结果（如 IP 地址列表、操作成功状态）返回给 resolvectl，后者再将其格式化为人类可读的输出。

📊 读取状态与统计

对于 resolvectl status 和 resolvectl statistics 这类查询命令，resolvectl 并非调用方法，而是读取 D-Bus 对象上的属性（Properties） 。Manager 接口暴露了大量只读属性，例如 DNS、Domains、TransactionStatistics 等，resolvectl 直接获取这些属性的值来展示系统状态。

👂 实时监控与信号

resolvectl monitor 的实现机制与其他命令不同。它会订阅 systemd-resolved 发出的 D-Bus 信号（Signals） 。当系统中有 DNS 查询完成时，systemd-resolved 会广播包含查询域名和返回 IP 地址等信息的信号，resolvectl monitor 收到后便实时打印出来。

🔐 权限控制：Polkit 的介入

修改解析配置的操作（如 SetLinkDNS、FlushCaches）受到 Polkit 的严格管控。当 resolvectl 尝试调用这些方法时，systemd-resolved 会向 Polkit 发起授权检查。这就是为什么这些命令通常需要 sudo 权限，而像 query 这样的只读查询则不需要。

🔍 如何亲手观察这层通讯

你可以使用 busctl 命令直接观察这个 D-Bus 接口，甚至绕过 resolvectl 直接与 systemd-resolved 对话：

# 内省 Manager 接口，查看所有方法、属性和信号
busctl introspect org.freedesktop.resolve1 /org/freedesktop/resolve1

# 直接通过 D-Bus 调用 ResolveHostname 方法（不经过 resolvectl）
busctl call org.freedesktop.resolve1 /org/freedesktop/resolve1 \
  org.freedesktop.resolve1.Manager ResolveHostname \
  "isit" 0 "example.com" 0 0

resolvectl query详解

resolvectl query 是 resolvectl 工具中最核心、最常用的子命令，用于执行正向解析 （域名 → IP）和反向解析（IP → 域名），并且能够查询各种类型的 DNS 资源记录。

🎯 核心功能

resolvectl query 的默认行为非常直观：

• 正向解析 ：当参数是主机名时，它会解析并返回对应的 IPv4 和 IPv6 地址

  。

• 反向解析：当参数是 IPv4 或 IPv6 地址时，它会执行反向操作，返回对应的主机名。

它通过 D-Bus 与 systemd-resolved 通信，因此查询结果会包含来源信息 （如使用的协议、网络接口）以及认证状态（如 DNSSEC 验证是否通过）。

📝 基本语法

resolvectl query [OPTIONS...] HOSTNAME|ADDRESS...

你可以同时指定多个主机名或 IP 地址进行批量查询。

⚙️ 关键选项

query 命令的强大之处在于它可以配合多种选项来执行特定类型的查询。

选项	说明
--type=TYPE / -t TYPE	指定要查询的 DNS 资源记录类型 （如 A、AAAA、MX、NS、TXT 等）。
--class=CLASS / -c CLASS	指定 DNS 查询类别（如 IN、CH 等），通常与 --type 配合使用。
--interface=IFACE / -i IFACE	指定使用哪个网络接口来发送查询。
--search=no	禁用搜索域逻辑 。当查询单标签域名（如 myserver）时，默认会拼接搜索域（如 myserver.example.com）进行查找。
--cache=no	绕过 systemd-resolved 的本地缓存，强制向 DNS 服务器发起新的查询。
--json=FORMAT	以 JSON 格式 输出结果，仅在配合 --type= 时可用。
--legend=no	隐藏输出中的图例信息，使结果更简洁。

📊 输出结果解读

resolvectl query 的输出非常详细，通常会包含以下几部分信息：

1. 查询结果本身：如域名对应的 IP 地址。

2. 来源信息 ：显示该结果是来自 DNS、LLMNR、mDNS 还是 /etc/hosts 等本地源。

3. 网络接口 ：显示查询是经过哪个网络接口（如 eth0、wlan0）完成的。

4. 认证状态 ：通常显示为 authenticated: yes/no，表明数据是否通过了 DNSSEC 验证或来自可信的本地源。

💡 实用示例

以下是一些常见的使用场景：

1. 基础正向与反向解析

# 正向解析域名
resolvectl query example.com

# 反向解析 IP 地址
resolvectl query 8.8.8.8

2. 查询特定类型的 DNS 记录

# 查询域名的 MX 记录（邮件交换记录）
resolvectl query --type=MX example.com

# 查询域名的 NS 记录（域名服务器记录）
resolvectl query --type=NS example.com

# 查询域名的 TXT 记录
resolvectl query --type=TXT example.com

3. 绕过本地缓存进行查询

# 忽略 systemd-resolved 的缓存，直接向外部 DNS 查询
resolvectl query --cache=no example.com

4. 以 JSON 格式输出结果

# 查询 A 记录并以 JSON 格式输出，便于脚本处理
resolvectl query --type=A --json=pretty example.com

🔍 高级行为细节

• 搜索域逻辑 ：当你查询一个不含点的单标签域名 （如 wiki）时，resolvectl 会按照系统配置的搜索域列表，依次尝试解析 wiki.search.domain。除非你显式指定了 --search=no 或使用了 --type=/--class= 选项，这个逻辑才会被关闭。

• 国际化域名（IDNA） ：对于包含非 ASCII 字符的域名，resolvectl 在通过传统 DNS 查询时会自动进行 IDNA 转换。但通过 mDNS 或 LLMNR 查询时则不会。

• 与服务/加密密钥查询的区别 ：resolvectl 还提供了 service、openpgp、tlsa 等独立子命令，它们用于查询 DNS-SD 服务、OpenPGP 密钥和 TLSA 证书等特殊记录类型，其用法与 query 不同，需要区分。

🛠️ 常见问题排查

当 resolvectl query 失败时，可以关注以下错误信息：

• "No appropriate name servers or networks for name found" ：表示 systemd-resolved 没有找到可用于该域名的 DNS 服务器或网络路由。通常意味着目标网络接口没有配置 DNS 服务器，或者该接口没有可路由的 IP 地址-。

• "Lookup failed due to system error: Invalid argument" ：可能是 systemd-resolved 服务状态异常，尝试重启服务 sudo systemctl restart systemd-resolved 或清空缓存 sudo resolvectl flush-caches-。

• 查询超时（Timeout）：常见于 VPN 或复杂网络环境，可能是 DNS 服务器路由配置不正确，导致查询无法送达。

resolvectl 所使用的搜索域列表并非来自单一位置，而是由 systemd-resolved 从多个渠道动态汇总而成的。其来源主要包括全局配置、每个网络链路的配置（静态或动态）以及运行时配置。

📋 来源一：全局配置 (/etc/systemd/resolved.conf)

你可以在 /etc/systemd/resolved.conf 文件的 [Resolve] 节中使用 Domains= 选项来设置全局的搜索域-28。

• 配置方式 ：Domains= 是一个以空格分隔的域名列表，这些域名会作为解析单标签主机名时的搜索后缀-28。

• 处理顺序 ：搜索域会严格按照你指定的顺序 进行附加和尝试，直到某个域名能被成功解析-28。

• 兼容性回退 ：如果 resolved.conf 中未指定 Domains=，systemd-resolved 会尝试读取 /etc/resolv.conf 文件中的 search 或 domain 条目作为替代-28。

🔗 来源二：每个网络链路的配置

这是搜索域最丰富、最常见的来源。systemd-resolved 为每个网络接口（链路）维护独立的搜索域列表。

• 静态配置 (.network 文件) ：如果你使用 systemd-networkd，可以在 /etc/systemd/network/*.network 文件的 [Network] 节中，通过 Domains= 选项为特定接口指定搜索域-1。

• 动态配置 (DHCP) ：当接口通过 DHCP 获取地址时，DHCP 服务器通常会下发搜索域（domain-search 选项）。systemd-networkd 或 NetworkManager 会捕获这些信息，并将其传递给 systemd-resolved，作为该链路的动态搜索域-25。

• resolvectl domain 命令 ：你也可以使用 sudo resolvectl domain <接口名> <域名> 命令，在运行时临时 为某个接口添加或修改搜索域。这本质上是通过 D-Bus 直接配置 systemd-resolved-。

🔄 来源三：其他运行时来源

除了上述主要来源，systemd-resolved 还会从其他系统服务接收 DNS 配置信息，例如通过 D-Bus 接口设置的配置。

⚖️ 优先级与顺序

当多个来源都配置了搜索域时，systemd-resolved 会如何处理呢？

1. 全局 vs. 链路 ：通常，与特定链路关联的搜索域（来自 .network 文件或 DHCP）会与全局配置的搜索域合并。在解析单标签域名时，这些搜索域会按照一定的内部优先级顺序被逐一尝试。

2. 顺序敏感性 ：无论是全局的 Domains= 还是链路级的配置，搜索域的处理顺序都非常关键，它会严格按照配置文件中定义的顺序来追加后缀进行解析尝试。

3. 已知限制 ：需要注意的是，根据社区反馈，systemd-resolved 在某些版本中可能会忽略你在单个接口内指定的顺序，而使用字母顺序。如果你发现搜索域的顺序未按预期生效，这是一个潜在的排查点。

💡 如何查看当前生效的列表

要查看 systemd-resolved 当前实际使用的搜索域列表，最直接的方法是运行以下命令：

resolvectl status

该命令的输出会为每个网络接口列出其生效的 Search Domains（搜索域）和 Routing Domains（路由域）。此外，系统也会将当前生效的搜索域列表写入 /run/systemd/resolve/stub-resolv.conf 文件中（如果你的 /etc/resolv.conf 是指向它的符号链接），该文件会始终保持最新状态。

总结来说，resolvectl 的搜索域列表是一个动态聚合的结果，其来源优先级大致为：运行时配置 > 链路动态配置 (DHCP) > 链路静态配置 (.network) > 全局配置 (resolved.conf) > /etc/resolv.conf。

💎 总结

resolvectl query 是一个功能丰富的 DNS 诊断和查询工具，它不仅能完成基础的域名/IP 互查，还能通过丰富的选项查询特定记录类型、控制查询行为（如缓存、搜索域）并输出结构化数据，是排查现代 Linux 系统 DNS 问题时的首选命令。

resolvectl service详解

resolvectl service 是 resolvectl 中用于服务发现 的专用子命令。与解析单个主机名或 IP 地址的 resolvectl query 不同，它的核心目标是发现网络中特定类型服务的位置和配置信息 ，主要依据 DNS-SD (RFC 6763) 和 SRV (RFC 2782) 标准实现。

📝 基本语法

resolvectl service [[NAME] TYPE] DOMAIN

根据你提供的参数数量（1到3个），resolvectl 会执行不同深度的查询。

🔍 参数详解与查询行为

传递三个参数：NAME TYPE DOMAIN

这是最完整的 DNS-SD 查询方式。

• NAME ：服务实例的名称，例如 "My Printer"。

• TYPE ：服务类型，遵循 _service._protocol 的格式，例如 _ipp._tcp（IPP 打印服务）或 _xmpp-server._tcp（XMPP 服务）。

• DOMAIN ：服务所属的域名，例如 example.com。

• 行为 ：执行完整的 DNS-SD 风格的 SRV 和 TXT 查询 。这意味着它不仅会查找服务的主机名和端口 （SRV 记录），还会获取服务的元数据（TXT 记录），比如打印机是否支持彩色打印等信息。

传递两个参数：TYPE DOMAIN

这是一种简化的 SRV 查询方式。

• TYPE：同上，服务类型。

• DOMAIN：同上，域名。

• 行为 ：仅执行 SRV 查询 ，不请求 TXT 记录。这用于发现某个域下所有指定类型的服务实例。

传递一个参数：DOMAIN

这是一种更简化的 SRV 查询方式。

• DOMAIN ：这里需要你提供一个已经包含服务类型前缀 的完整域名，例如 _ipp._tcp.example.com。

• 行为 ：对该域名执行 SRV 查询，同样不包含 TXT 记录。

⚖️ 与 resolvectl query 的核心区别

特性	resolvectl service	resolvectl query
主要目的	服务发现（在哪里？提供什么？）	名称解析（域名对应哪个 IP？）
核心协议	DNS-SD, SRV	DNS (A, AAAA, MX, etc.)
典型输入	服务类型 + 域名（如 _http._tcp example.com）	主机名或 IP 地址（如 example.com）
查询记录	SRV, TXT	A, AAAA, MX, NS, TXT 等
输出结果	服务的主机名、端口、元数据	IP 地址或主机名

💡 实用示例

场景一：发现网络中所有 XMPP 服务器

resolvectl service _xmpp-server._tcp example.com

这会返回 example.com 域下所有 XMPP 服务的 SRV 记录，包括它们的主机名和端口。

场景二：查询特定打印机的详细信息

resolvectl service "My Printer" _ipp._tcp example.com

这会执行完整的 DNS-SD 查询，返回该打印机的主机名、端口以及 TXT 记录中包含的元数据（如支持的文档格式、色彩模式等）。

⚙️ 相关选项

• --service-txt=BOOL ：控制是否解析 TXT 记录。默认值为 yes。设置为 no 可以强制在传递三个参数时也不查询 TXT 记录。

• --service-address=BOOL ：控制是否将 SRV 记录中的主机名进一步解析为 IP 地址。默认值为 yes。

⚠️ 注意事项

• 服务类型的格式 ：务必遵循 _service._protocol 的格式，例如 _http._tcp 或 _ipp._tcp。这是 DNS-SD 的标准。

• 单标签域名 ：与 query 不同，service 命令不会 应用搜索域逻辑。你提供的域名必须能够被 systemd-resolved 正确解析。

• 权限 ：service 命令是只读查询，通常不需要 sudo 权限。

💡 其他可用的测试目标

resolvectl service _xmpp-server._tcp jabber.org

除了 jabber.org，你还可以尝试以下公开服务来验证 resolvectl service 的功能：

服务类型	示例域名	说明
_xmpp-server._tcp	jabber.org	公共 XMPP 服务器，通常有 SRV 记录
_sip._tcp	sip2sip.info	SIP 服务，部分提供商发布 SRV 记录
_ldap._tcp	example.com	企业环境常见，但公共域名不一定有

🔧 服务类型 (TYPE)：遵循 _service._protocol 格式

TYPE 参数是标准化的，其格式固定为 _service._protocol，例如 _http._tcp 或 _ipp._tcp。其中：

• _service 是服务的名称（如 http, ipp, ssh）。

• _protocol 是传输层协议，通常是 _tcp 或 _udp。

这是 DNS-SD (RFC 6763) 和 SRV (RFC 2782) 标准规定的格式。

💡 常见服务类型示例

以下是一些在实际网络环境中常见的 DNS-SD 服务类型示例，供你参考：

服务类型 (TYPE)	描述
_http._tcp	Web 站点
_https._tcp	安全 Web 站点 (HTTPS)
_ftp._tcp	FTP 文件传输
_ssh._tcp	SSH 远程终端
_sip._udp	SIP 电话服务
_imap._tcp	IMAP 邮件访问
_ipp._tcp	互联网打印协议 (IPP) 打印机
_printer._tcp	UNIX/LPD 打印机
_airplay._tcp	Apple AirPlay 设备
_googlecast._tcp	Google Chromecast 设备
_daap._tcp	iTunes 音频共享
_smb._tcp	Microsoft Windows 网络共享

总结来说，你无法"枚举全部"服务实例名称，因为它们由服务提供者自定义；而服务类型虽然有完整的官方注册表，但列表极其庞大，正确的做法是根据你要查找的具体服务，去 IANA 注册表中进行检索。

resolvectl status详解

resolvectl status 是诊断 Linux 系统 DNS 问题的核心工具，它能清晰地展示 systemd-resolved 服务当前生效的全局与各网络接口的 DNS 配置。当你不带任何子命令直接运行 resolvectl 时，它默认执行的就是 status。

📝 基本语法

resolvectl status [LINK...]

你可以指定一个或多个网络接口名（如 eth0、wlan0），只查看特定接口的状态。如果不指定，则显示所有接口的完整信息。

📊 输出结构详解

resolvectl status 的输出通常分为两大部分：Global （全局设置）和 Link（按接口设置）。

🌐 Global 部分

这部分显示不针对特定接口的全局 DNS 解析配置。

字段	含义
Protocols	启用的解析协议。+ 表示启用，- 表示禁用。例如 +LLMNR 表示启用了链路本地多播名称解析。
DNSSEC	DNSSEC 验证状态。格式为 设置/支持情况。例如 DNSSEC=no/unsupported 表示未启用且上游服务器不支持。
resolv.conf mode	指出 /etc/resolv.conf 如何被管理。stub 表示它是一个指向 systemd-resolved 存根解析器（127.0.0.53）的符号链接。
DNS Servers / Current DNS Server	全局配置的 DNS 服务器列表，以及当前实际在使用的那一个。
DNSSEC NTA	配置的 DNSSEC 负信任锚（Negative Trust Anchors）列表，用于临时禁用特定域名的 DNSSEC 验证。

🔗 Link 部分

这部分针对每个网络接口（如 eth0、wlan0）分别显示其 DNS 配置。

字段	含义
Link N (interface)	接口的索引号和名称。
Current Scopes	当前该接口用于解析的协议范围，如 DNS、LLMNR/IPv4、mDNS 等。
Protocols	该接口上启用的协议。+DefaultRoute 表示该接口的 DNS 服务器被用作默认路由。
DNSSEC	该接口的 DNSSEC 设置状态，格式为 设置/支持情况。
Current DNS Server / DNS Servers	该接口当前使用的 DNS 服务器，以及其完整的服务器列表。
DNS Domain	该接口的搜索域或路由域。~. 通常表示这是一个用于解析所有域名的"默认路由"。
Default Route	指示该接口的 DNS 服务器是否被用作默认路由（yes/no）。

💡 常用选项

选项	说明
LINK	指定一个或多个网络接口名称，只显示这些接口的状态。
--all	显示所有接口，包括那些没有配置 DNS 的接口。
--json=FORMAT	以 JSON 格式输出结果，便于脚本处理。FORMAT 可以是 short 或 pretty。
--no-pager	不分页，直接输出所有内容，适合重定向到文件或通过管道传递。

💎 总结与排查思路

resolvectl status 是排查 DNS 问题的起点。通过它，你可以快速确认：

• 哪个接口 正在处理 DNS 查询（看 Current Scopes 和 Default Route）。

• 正在使用哪些 DNS 服务器 （看 Current DNS Server 和 DNS Servers）。

• DNSSEC 和 DoT 等安全功能是否生效。

• 搜索域和路由域是否按预期配置。

当你遇到解析问题时，建议先运行 resolvectl status 查看整体配置，再针对特定接口使用 resolvectl status <接口名> 进行深入分析。

resolvectl statistics详解

resolvectl statistics 是用于查看 systemd-resolved 解析器运行时统计信息的命令。它提供了关于 DNS 事务、缓存性能和 DNSSEC 验证的详细数据，是评估解析器工作效率和排查性能问题的重要工具。

📝 基本语法

resolvectl statistics

该命令不需要任何参数。与只读的 status 不同，statistics 展示的是动态累积的计数器，反映了自上次统计重置以来的运行情况。

📊 输出字段详解

resolvectl statistics 的输出主要分为以下几个部分：

全局状态

• DNSSEC supported by current servers : 指示当前配置的 DNS 服务器是否支持 DNSSEC。yes 表示支持，no 表示不支持。

Transactions（事务）

• Current Transactions: 当前正在进行的 DNS 查询事务数量。

• Total Transactions: 自统计重置以来处理的 DNS 查询事务总数。一个复杂查询（如涉及 CNAME 或 DNSSEC）可能产生多个事务。

Cache（缓存）

• Current Cache Size: 当前缓存中存储的 DNS 记录条目总数（包括正向和负向记录）。

• Cache Hits: 查询在缓存中直接命中的次数。

• Cache Misses: 查询未命中缓存、需要向外部服务器发起的次数。

• 缓存命中率计算 : Cache Hits / (Cache Hits + Cache Misses)。高命中率表示缓存效率高。

Failure（失败统计）

• Total Timeouts: 查询超时的总次数，反映网络或上游 DNS 服务器的问题。

• Total Timeouts (Stale Data Served): 在超时情况下，使用过期缓存数据响应客户端的次数。

• Total Failure Responses: 收到失败响应（如 SERVFAIL、NXDOMAIN）的总次数。

• Total Failure Responses (Stale Data Served): 在收到失败响应时，使用过期缓存数据响应的次数。

DNSSEC Verdicts（验证结果）

• Secure: DNSSEC 验证成功的次数。数据真实可信。

• Insecure: 数据被确认为未签名且合法（如上游域名未启用 DNSSEC）。

• Bogus : DNSSEC 验证失败，数据可能被篡改。这是一个需要警惕的信号。

• Indeterminate: 无法完成验证（如缺少必要的密钥或算法不支持）。

⚙️ 相关命令与选项

• resolvectl reset-statistics : 重置所有统计计数器为零。此操作需要 root 权限（使用 sudo）。

• resolvectl flush-caches : 清空本地 DNS 缓存。执行后，Current Cache Size 会变为 0。

💡 实用示例与排查思路

1. 验证缓存是否生效

# 1. 清空缓存
sudo resolvectl flush-caches

# 2. 查看初始状态（缓存大小应为 0）
resolvectl statistics

# 3. 查询一个域名（第一次查询，应产生 Cache Miss）
resolvectl query example.com

# 4. 再次查询同一域名（应产生 Cache Hit）
resolvectl query example.com

# 5. 查看统计（Cache Hits 应增加）
resolvectl statistics

2. 排查性能问题

• Cache Misses 极高，Cache Hits 极低 ：缓存可能未生效。检查 /etc/systemd/resolved.conf 中 Cache= 是否被注释或设置为 no。

• Total Timeouts 持续增长：表明与上游 DNS 服务器的连接不稳定。检查网络连通性或更换 DNS 服务器。

• Bogus 计数不为零：表明 DNSSEC 验证失败。这可能意味着 DNS 污染或中间人攻击，需要立即排查网络环境。

💎 总结

resolvectl statistics 提供了 systemd-resolved 运行状况的关键量化指标。通过关注缓存命中率 和 DNSSEC 验证结果 ，可以快速判断解析器的健康状态和性能瓶颈。在排查 DNS 问题时，建议与 resolvectl status 结合使用，前者提供动态数据，后者展示静态配置。

resolvectl reset-server-features 详解

resolvectl reset-server-features 是一个用于重置 systemd-resolved 对上游 DNS 服务器功能级别认知的管理命令。它并不清空域名缓存，而是让解析器"忘记"之前学习到的服务器能力信息，并在下一次查询时重新探测。

📝 命令概述与语法

该命令的语法非常简单，不接受任何参数：

resolvectl reset-server-features

它的核心作用是清除 systemd-resolved 所记录的所有关于上游 DNS 服务器功能级别的信息 。当解析器与某个 DNS 服务器通信时，它会逐步探测并记录该服务器支持的高级特性（例如 EDNS0、DNSSEC 等）。执行此命令后，这些学习到的信息会被全部丢弃，解析器将在下一次需要与这些服务器通信时，从最高功能级别开始重新探测。

🔐 权限要求

此操作需要超级用户（root）权限 。与清空缓存类似，这是对系统级守护进程的管理操作，普通用户无法执行。因此，使用时必须加上 sudo：

sudo resolvectl reset-server-features

⚙️ 底层实现机制

该命令通过 D-Bus 系统总线与 systemd-resolved 服务进行通信。在 systemd-resolved 的 D-Bus 接口 org.freedesktop.resolve1.Manager 上，存在一个名为 ResetServerFeatures() 的方法。resolvectl reset-server-features 命令的本质，就是通过 D-Bus 调用这个方法来触发重置操作。

💡 典型使用场景

此命令主要用于调试和恢复 DNS 解析行为。

1. 解决 DNS 解析异常（常见）

当 systemd-resolved 错误地记录了某个上游 DNS 服务器的能力（例如，误判其不支持 DNSSEC 或 EDNS0），可能导致解析失败或返回不完整的结果。此时，重置服务器特性可以让解析器重新探测，从而恢复正常。有用户报告，在遇到"网络连接受限"的问题时，执行 sudo resolvectl reset-server-features 后，域名解析立即恢复正常。--

2. 与 flush-caches 配合进行彻底排查

在诊断复杂的 DNS 问题时，通常建议先清空缓存，再重置服务器特性，以确保后续的查询是在一个全新的、无历史干扰的基线上进行的。例如：

# 先清空本地缓存
sudo resolvectl flush-caches
# 再重置上游服务器的特性记录
sudo resolvectl reset-server-features
# 最后执行查询进行测试
resolvectl query example.com

多个社区排查案例都推荐这个操作顺序。

3. 排查 EDNS0/TCP 回退等问题

在处理与 EDNS0 缓冲区大小或 TCP 回退相关的 bug 时，重置服务器特性是标准的复现步骤。例如，有 Ubuntu bug 报告要求在执行查询前先运行 flush-caches 和 reset-server-features，以观察解析器是否使用了 TCP 回退。

⚠️ 注意事项

• 与 flush-caches 的区别 ：flush-caches 清除的是域名解析结果 的缓存；reset-server-features 清除的是解析器对上游服务器能力的记忆。两者作用对象完全不同，不可混用。

• 重置后行为 ：重置后，systemd-resolved 会在下一次查询时重新开始"学习"过程。这可能会带来微小的首次查询延迟，因为需要重新探测服务器特性。

• 持久性问题 ：此命令重置的是运行时状态 。如果网络配置发生变化，systemd-resolved 通常也会自动忘记已学到的服务器信息。因此，它主要是一种手动调试手段，而非持久的配置变更。-

• 旧版本命令 ：在 systemd v239 之前的旧版本中，对应的命令是 systemd-resolve --reset-server-features。systemd-resolve 已被 resolvectl 取代。

💎 总结

resolvectl reset-server-features 是一个轻量级的调试工具 ，用于强制 systemd-resolved 重新评估上游 DNS 服务器的能力。它不涉及缓存清除，主要解决因解析器错误记忆服务器特性而导致的解析异常。在执行时需使用 sudo，并常与 flush-caches 配合使用以建立干净的排查基线。