resolved.conf 中文手册

一个空格分隔的 IPv4 与 IPv6 地址列表。用作系统的全局DNS服务器。 DNS请求将被首先发送给 systemd-networkd.service(8) 中针对特定连接设置的DNS服务器或者由外部程序在运行时设置的DNS服务器，然后才会发送给此处设置的全局DNS服务器。 出于兼容性考虑，如果未设置此选项，那么将使用 /etc/resolv.conf 中的DNS服务器(如果其中确实配置了DNS服务器的话)。 此选项的默认值为空。

一个空格分隔的 IPv4 与 IPv6 地址列表。用作系统的替补DNS服务器。 在 systemd-networkd.service(8) 中 针对特定连接配置的任何DNS服务器的优先级都高于此选项中设置的DNS服务器， 也高于上述 DNS= 中设置的DNS服务器，同样也高于 /etc/resolv.conf 中设置的DNS服务器。 所以，此选项所设置的DNS服务器仅在实在找不到可用DNS的情况下才会被使用。 若未设置此选项，则使用程序内置的默认DNS服务器列表。

一个空格分隔的域名列表。 在解析不含"."的域名时，将被用作域名后缀，以将这些域名转化为FQDN(全限定域名)。 这些后缀将会严格按照这里设置的顺序依次尝试，直到解析成功。 出于兼容性考虑，如果未设置此选项， 那么将使用 /etc/resolv.conf 中列出的搜索域(如果其中确实配置了搜索域的话)。 此选项的默认值为空。

如果指定的域名带有 "~" 前缀， 那么表示它不是一个搜索域，而是一个"路由域"，也就是仅用于将指定的域名查询请求 优先路由到上文 DNS= 设置的全局DNS服务器上去。 注意，如果不存在针对特定连接的DNS服务器，那么 "~" 语法没有任何实际效果。 特殊值 "~." 表示将所有DNS查询请求 优先路由到上文 DNS= 设置的全局DNS服务器上去 (前面的波浪号表示这是一个"路由域"，后面的点表示DNS根域(也就是所有域名的后缀))。

必须设为 "resolve" 或布尔值。 控制本机对LLMNR(Link-Local Multicast Name Resolution, RFC 4795)的支持。 设为 yes 表示完全支持 LLMNR responder 与 resolver ； 设为 no 表示彻底不支持 LLMNR ； 设为 "resolve" 表示仅支持 LLMNR resolver 而不支持 LLMNR responder ； 注意， systemd-networkd.service(8) 中还有针对特定连接的LLMNR设置。 对于某个特定的连接来说，LLMNR 将仅在针对该连接的设置与全局设置都开启的情况下， 才会开启。

必须设为布尔值或特殊值 "resolve" ，用于控制本机对组播DNS(RFC 6762)的支持。 设为 yes 表示完整的支持组播DNS的 responder 与 resolver 角色。 设为 no 表示完全禁止组播DNS。 设为 "resolve" 表示仅支持解析(resolver)而不支持应答(responder)。 注意， systemd-networkd.service(8) 还支持针对每个网络连接单独设置对组播DNS的支持。 对于某个特定的网络连接来说，只有全局开启了对组播DNS的支持，并且同时也针对该连接开启了组播DNS支持的情况下， 才能在此连接上使用组播DNS 。

必须设为布尔值或特殊值 "allow-downgrade" 。 设为 yes 表示使用 DNSSEC 机制 检查所有 DNS 应答的有效性(多播DNS 与 LLMNR 除外)。 如果某个DNS应答被鉴定为无效， 那么上层应用将会得到一个"查询失败"的结果。 注意，这意味着 DNS 服务器必须支持 DNSSEC 。 如果某个 DNS 服务器不能正确支持 DNSSEC ， 那么从该 DNS 服务器接收到的所有应答都将被视为无效应答。 设为 "allow-downgrade" 表示： 如果某个 DNS 服务器不能正确支持 DNSSEC ， 那么将不使用 DNSSEC 机制检查该 DNS 应答的有效性。 注意， 这将导致 DNSSEC 机制形同虚设，从而造成安全漏洞。 设为 no 则表示彻底禁用 DNSSEC 机制。

注意，因为 DNSSEC 需要 额外查询更多的 DNS 数据，所以，开启此选项会减慢 DNS 查询速度。

为了确保数据完整性， DNSSEC 必须预先知道一些信任锚(相当于域的公钥)。 systemd 已经内置了 Internet 根域名服务器的信任锚(Trust anchor)， 不过，系统管理员还可在 dnssec-trust-anchors.d(5) 中添加更多的信任锚。 如果信任锚过期或被撤销，那么 DNSSEC 验证机制就会失效， 此时必须配置新的信任锚，或者通过更新 systemd 软件包来更新 Internet 根域名服务器的信任锚。 实际上，当内置的根域名服务器信任锚已经失效， 并且 DNSSEC=yes 时， 所有的DNS查询都将会失败， 因为此时已经无法验证DNS应答的可靠性了； 但是如果 DNSSEC=allow-downgrade ， 那么将会自动关闭 DNSSEC 验证机制。

查询DNS数据的客户端程序将会被通知： (1)其所发出的DNS查询请求是否可以使用DNSSEC机制进行验证； (2)返回的应答是否无法使用DNSSEC机制进行验证(原因有三： DNS服务器返回的应答不含签名、DNS服务器本身不支持DNSSEC扩展、 DNS服务器返回的应答中的签名在本地找不到对应的信任锚)。 如果出现第(2)种情况(无法使用DNSSEC验证返回的应答)， 那么客户端程序 必须能够自己验证DNS应答的可靠性。

强烈建议 在已知DNS服务器支持DNSSEC扩展的系统上设置 DNSSEC=yes 并且及时更新信任锚。 对于其他系统，则建议设置为 DNSSEC=allow-downgrade 。

除了此处的全局 DNSSEC 设置，在 systemd-networkd.service(8) 中还支持针对每个连接进行 DNSSEC 设置。 对于前文提及的系统全局DNS服务器来说，仅参照此处的全局 DNSSEC 设置。 对于专门针对单个连接设置的DNS服务器来说， 优先参照针对该连接的 DNSSEC 设置 (仅在未设置时才参照此处的全局设置)。

私有DNS区域通常不支持DNSSEC验证， 除非专门为其配置了反向信任锚(私有区域未签名) 或者正向信任锚(私有区域已签名)。 如果选择了 "allow-downgrade" 模式， 那么将会尝试使用DNS根服务器所不知道的顶级域去检测私有DNS区域。 注意， 这个逻辑并不总是适用于所有的私有区域配置。

默认值是 "allow-downgrade"

设为 "opportunistic" 表示 优先尝试通过 DNS-over-TLS 发送DNS查询请求， 如果DNS服务器不支持TLS，那么就禁用 DNS-over-TLS 。 注意，这种模式仍然存在"降级"攻击的安全漏洞。 设为 "no" 表示 完全禁用 DNS-over-TLS ， 仅使用不安全的传统 UDP 方式发送DNS查询请求。

因为 DNS-over-TLS 需要额外的数据包建立安全连接， 所以相比不安全的传统 UDP 方式 需要消耗更多的查询时间。

注意，因为解析程序目前尚不能对服务器进行认证， 所以仍然存在"中间人"攻击的安全漏洞。

除了这里的全局 DNSOverTLS 设置之外， systemd-networkd.service(8) 还有针对每个连接的 DNSOverTLS 设置。 对于系统的全局DNS服务器来说， 仅使用这里的全局 DNSOverTLS 设置。 但对于针对每个连接设置的DNS服务器来说， 则优先使用针对每个连接的 DNSOverTLS 设置(仅在未设置时继承全局设置)。

默认值为 "no"

必须设为布尔值。 默认值 "yes" 表示缓存先前已经解析成功的域名直到缓存过期，以避免重复查询。 注意，关闭缓存不但浪费网络流量，更容易造成访问延迟， 尤其是在使用了DNSSEC的时候。

注意，对于IP地址为 127.0.0.1 或 ::1 之类的本机DNS来说，DNS缓存总是关闭的。 这样做是为了避免不必要的多次缓存。

可设为 "yes"(默认值), "no", "udp", "tcp" 之一。 "udp" 表示本地存根DNS服务器将在 127.0.0.53 的 53 端口上监听 UDP 请求； "tcp" 表示在 127.0.0.53:53 上监听 TCP 请求； "yes" 表示在 127.0.0.53:53 上同时监听 UDP 与 TCP 请求； "no" 表示禁止监听。

注意，如果 127.0.0.53:53 已被其他程序占用， 那么本地存根DNS服务器将会自动放弃监听。

接受一个布尔值。默认值 "yes" 表示在向DNS服务器发送查询请求之前，优先查询 /etc/hosts 文件。