一個空格分隔的 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 4794[1])的支持。 設爲 yes 表示完全支持 LLMNR responder 與 resolver ； 設爲 no 表示徹底不支持 LLMNR ； 設爲 "resolve" 表示僅支持 LLMNR resolver 而不支持 LLMNR responder ； 注意， systemd-networkd.service(8) 中還有針對特定連接的LLMNR設置。 對於某個特定的連接來說，LLMNR 將僅在針對該連接的設置與全局設置都開啓的情況下，纔會開啓。

必須設爲布爾值或特殊值 "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 requires knowledge of "trust anchors" to prove data integrity. The trust anchor for the Internet root domain is built into the resolver, additional trust anchors may be defined with dnssec-trust-anchors.d(5). Trust anchors may change at regular intervals, and old trust anchors may be revoked. In such a case DNSSEC validation is not possible until new trust anchors are configured locally or the resolver software package is updated with the new root trust anchor. In effect, when the built-in trust anchor is revoked and DNSSEC= is yes, all further lookups will fail, as it cannot be proved anymore whether lookups are correctly signed, or validly unsigned. If DNSSEC= is set to "allow-downgrade" the resolver will automatically turn off DNSSEC validation in such a case.

Client programs looking up DNS data will be informed whether lookups could be verified using DNSSEC, or whether the returned data could not be verified (either because the data was found unsigned in the DNS, or the DNS server did not support DNSSEC or no appropriate trust anchors were known). In the latter case it is assumed that client programs employ a secondary scheme to validate the returned DNS data, should this be required.

It is recommended to set DNSSEC= to yes on systems where it is known that the DNS server supports DNSSEC correctly, and where software or trust anchor updates happen regularly. On other systems it is recommended to set DNSSEC= to "allow-downgrade".

In addition to this global DNSSEC setting systemd-networkd.service(8) also maintains per-link DNSSEC settings. For system DNS servers (see above), only the global DNSSEC setting is in effect. For per-link DNS servers the per-link setting is in effect, unless it is unset in which case the global setting is used instead.

Site-private DNS zones generally conflict with DNSSEC operation, unless a negative (if the private zone is not signed) or positive (if the private zone is signed) trust anchor is configured for them. If "allow-downgrade" mode is selected, it is attempted to detect site-private DNS zones using top-level domains (TLDs) that are not known by the DNS root server. This logic does not work in all private zone setups.

默認值是 no

必須設爲布爾值。 默認值 "yes" 表示緩存先前已經解析成功的域名直到緩存過期，以避免重複查詢。 注意，關閉緩存不但浪費網絡流量，更容易造成訪問延遲，尤其是在使用了DNSSEC的時候。

注意，對於IP地址爲 127.0.0.1 或 ::1 之類的本機DNS來說，DNS緩存總是關閉的。 這樣做是爲了避免不必要的多次緩存。