systemd-resolved.service 中文手册

译者:金步国


版权声明

本文译者是一位开源理念的坚定支持者,所以本文虽然不是软件,但是遵照开源的精神发布。

其他作品

本文译者十分愿意与他人分享劳动成果,如果你对我的其他翻译作品或者技术文章有兴趣,可以在如下位置查看现有的作品集:

联系方式

由于译者水平有限,因此不能保证译文内容准确无误。如果你发现了译文中的错误(哪怕是错别字也好),请来信指出,任何提高译文质量的建议我都将虚心接纳。


手册索引 . 指令索引systemd-231

名称

systemd-resolved.service, systemd-resolved — 网络名字解析服务

大纲

systemd-resolved.service

/usr/lib/systemd/systemd-resolved

描述

systemd-resolved 为本地应用程序提供了网络名字解析服务。 它不但提供了传统的 DNS/DNSSEC 解析与本地缓存功能,还提供了 LLMNR 解析(resolver)与应答(responder)的功能。 本地应用程序可以通过三种方式提交网络名字解析请求:

  • 第一种,通过D-Bus总线上的本地全功能API systemd-resolved (详见 API Documentation)。 这是首选方法,因为它是异步的并且功能最全。 此种方式可以正确返回 DNSSEC 的有效状态,以及支持 link-local 网络所必需的地址的网口范围(interface scope)。

  • 第二种,通过 glibc 的 getaddrinfo(3), gethostbyname(3) 等相关API(RFC3493)。 这些API受到了广泛的支持(包括非Linux平台)。此种方法不能检查 DNSSEC 的有效状态,并且是同步的。 此种方法由 glibc Name Service Switch (nss(5)) 支持。 必须使用 glibc NSS 模块 nss-resolve(8) 才能让 glibc NSS 使用 systemd-resolved 提供的名字解析功能。

  • 第三种,通过 systemd-resolved 在本地回环网口 127.0.0.53 上提供的本地DNS服务器。 应用程序可以直接向 127.0.0.53 发送DNS请求,从而直接使用 systemd-resolved 提供的解析服务。 除非确实无法使用前面的 glibc NSS 或 D-Bus API 两种方法, 否则应该尽量避免使用此种方式, 因为无法将各种网络解析功能(例如 link-local 地址或 LLMNR Unicode 域名)全部映射到 单播DNS协议中。

DNS服务器来自于 全局配置文件(/etc/systemd/resolved.conf)、 针对单个连接的静态配置文件(/etc/systemd/network/*.network)、 针对单个连接的动态配置(从DHCP或其他系统服务得到的DNS服务器)。参见 resolved.conf(5)systemd.network(5) 以了解 systemd 自身的DNS服务器配置。为了提高兼容性, 仅在 /etc/resolv.conf 不是一个指向 /run/systemd/resolve/resolv.conf 的软连接的情况下, 才会从 /etc/resolv.conf 读取全局DNS服务器。

systemd-resolved 会为下列特殊域名合成DNS资源记录(RR):

  • 本机的主机名将按如下规则解析: 如果配置了本机IP地址,那么将被解析为所有本机IP地址(按范围排序)。 如果不存在本机IP地址,那么将被解析为本地回环上的 127.0.0.2 与 ::1

  • "localhost" 与 "localhost.localdomain" 以及所有以 ".localhost" 或 ".localhost.localdomain" 结尾的主机名, 都将被解析为 127.0.0.1 与 ::1

  • "gateway" 将被解析为所有当前路由表中的默认网关IP地址(按数字大小排序)。 通过给网关分配一个固定的名称, 方便了应用程序对网关地址的引用, 应用程序不再需要关心网络的具体配置。

  • /etc/hosts 中定义的映射关系。

在将查询请求发送到DNS服务器与LLMNR接口时, 遵守下面的规则:

  • 对 "localhost" 系列特殊域名的查询 永远不会发送到网络上去。

  • 不含"."的域名将被使用LLMNR协议发送到所有 具备IP多播能力的本地接口上。 对 IPv4 地址的查询将只通过 LLMNR 在 IPv4 上查询; 对 IPv6 地址的查询将只通过 LLMNR 在 IPv6 上查询。 对本机的主机名、"gateway" 以及 /etc/hosts 中定义的域名的查询 永远不会发送到 LLMNR 接口。

  • 含有"."的域名将被按照DNS协议发送到所有 配置了DNS服务器的本地网络接口上。如果配置了全局DNS服务器, 还会被发送到全局DNS服务器上。 从 link-local 地址范围发起的查询永远不会被发送到DNS服务器。

如果查询被发送到了多个接口, 那么将只返回第一个成功的应答。 如果所有接口上的查询全部失败, 那么将只返回最后一个失败的应答。

针对特定网络接口配置的域名会影响对域名查询的路由。 如果查询的主机名的尾部与某个针对特定网络接口配置的域名相匹配, 那么此查询将只会被发送到与其匹配的网络接口。 详见 systemd.network(5) 手册。

参见 resolved D-Bus API Documentation 以了解 systemd-resolved 所提供的编程接口。

/etc/resolv.conf

有三种处理 /etc/resolv.conf 文件(参见 resolv.conf(4)) 的方式:

  • 创建 /etc/resolv.conf 软连接,并将其指向 /usr/lib/systemd/resolv.conf 文件(其中仅设置了单独一个 127.0.0.53 DNS服务器)。 这是推荐的首选方式。

  • 创建 /etc/resolv.conf 软连接, 并将其指向由 systemd-resolved 实时更新的 /run/systemd/resolve/resolv.conf 文件。 注意,此文件中只包含所有已知的全局DNS服务器,而不包含针对特定网络接口设置的DNS服务器。 注意,应用程序不应该直接使用 /run/systemd/resolve/resolv.conf 文件, 而是应该继续使用 /etc/resolv.conf 文件。 使用这种方式,所有绕过本地 DNS API 的客户端也将同样绕开 systemd-resolved 服务, 直接使用已知的DNS服务器。

  • 由其他软件包或系统管理员维护 /etc/resolv.conf 的内容。 在这种情况下, systemd-resolved 将会从中读取全局DNS配置。 也就是说,systemd-resolved 只是一个读取 /etc/resolv.conf 配置文件的使用者, 而非此文件的提供者。

注意,上述三种处理方式是自动感知的(不需要特别的配置),完全取决于 /etc/resolv.conf 是否为软连接, 以及软连接指向的目标。

信号

SIGUSR1

systemd-resolved 将所有的DNS资源记录缓存 转储到系统日志中。

SIGUSR2

systemd-resolved 刷新所有缓存。 除非出于调试目的,否则一般不需要这么做。 因为 systemd-resolved 会在网络配置发生变化时自动刷新缓存。

参见

systemd(1), resolved.conf(5), dnssec-trust-anchors.d(5), nss-resolve(8), systemd-resolve(1), resolv.conf(5), hosts(5), systemd.network(5), systemd-networkd.service(8)