systemd-resolved 添加 local 搜索域后把主机名发往单播 DNS

为了让短主机名 printer 自动补成 printer.local，在 resolved.conf 中加入 Domains=local，结果查询被送到普通 DNS 服务器，返回 NXDOMAIN。即使已经设置 MulticastDNS=yes，也没有按预期用 mDNS 找到局域网设备。

systemd-resolved 的搜索域属于单播 DNS 机制。把 local 明确配置为搜索域或路由域，会允许这类名字走单播 DNS；它不能用来实现 mDNS 的短名补全。下面针对使用 systemd-resolved 的 Linux 主机，检查命令需要提供 resolvectl 的版本。该行为在 systemd 254 中存在，当前配置规则仍保留这一区分。

先用完整的 .local 名字区分问题

printer.local 是示例，应替换为设备实际发布的名称：

resolvectl status
resolvectl query printer.local
resolvectl --protocol=mdns query printer.local

第一条显示全局和链路上的 DNS 域及 mDNS 状态。后两条分别观察默认查询和仅允许 mDNS 的查询；结果中的协议与接口信息比单看“解析失败”更有用。

--protocol=mdns 只限制可用协议，不会强行打开被禁用的 mDNS，也不会让不支持组播的网络突然可用。如果这一条也失败，还需确认全局与当前链路均允许 mDNS、设备确实发布该名称，以及它们处于可达的组播链路。此时仅删除搜索域还不足以证明修复。

如果完整名字能通过 mDNS 查询，而短名失败，不要继续添加 local 搜索域。让应用使用完整的 printer.local；是否支持某种短名还受应用使用的解析接口及其他名称机制影响。

从配置来源删除误加的 local 项

查看 resolvectl status 中 Global 和各 Link 的 DNS Domain。重点找 local、local. 以及只用于路由的 ~local；还要检查是否有更具体的 .local 子域被显式交给单播 DNS。

这些设置可能来自 /etc/systemd/resolved.conf、其 drop-in、网络连接配置或 DHCP，不能只改一个文件就认定最终状态已经改变。先记录当前完整域列表和配置来源，保留已有的公司域、VPN 分流域及其他搜索后缀。

例如原来自己维护的全局配置是：

[Resolve]
Domains=~. local.
MulticastDNS=yes
LLMNR=no

如果其中 local. 只是为了给 mDNS 名称补后缀，而 ~. 原本用于其他单播 DNS 路由，应在这个配置来源中只去掉 local.，保留：

[Resolve]
Domains=~.
MulticastDNS=yes
LLMNR=no

这不是适用于所有机器的通用配置。不要把 ~. 额外加到没有它的网络中，也不要把整个域列表清空。列表型设置可能由多个文件累积，另加一个不含 local 的配置片段不一定能撤销其他来源；应修正实际提供错误项的位置，再查看有效状态。

如果 .local 本来就是公司现有的单播 DNS 区域，删除路由可能破坏它。先确认这台机器需要访问的是 mDNS 设备还是单播区域，再决定配置；同一个后缀混用两套名称体系容易产生冲突，应按现有网络设计处理，不能仅凭后缀修改。

应用配置，并检查实际程序

修改全局 resolved 配置前保存原文件。通过系统现有方式重启 systemd-resolved 后重新查询状态；重启会短暂影响名称解析，应在允许的时间进行。由 NetworkManager、systemd-networkd 或 DHCP 提供的链路设置，则应在对应管理来源修正并应用，避免下一次连接时又被写回来。

不建议用 resolvectl revert 作为删除某一个域名的快捷操作。它会重置该链路的多项 DNS 配置，影响范围大于移除一个错误搜索项。

重新执行完整名称的默认查询与 mDNS 限定查询，确认地址、接口和协议符合预期，再让原应用使用这个完整名称连接。dig 直接指定普通 DNS 服务器得到 NXDOMAIN，不能证明 mDNS 设备不存在；反过来，resolvectl 成功也不能证明绕过系统解析器的应用一定使用同一路径。

若默认查询恢复但应用仍失败，继续检查该应用自己的解析方式和配置，避免再把 local 加回搜索域。回退时恢复本次改动的原配置并按同一管理方式应用，随后同时核验原有单播域和局域网设备访问。仅恢复文件而不重新应用，不能改变当前有效状态。