systemd-resolved 如何處理單標籤 dns 查找請求?
我查看了 systemd-networkd 和 systemd-resolved:
我對一些詞感到困惑:
- systemd-resolved.service(8)
使用 LLMNR 協議將單標籤名稱路由到所有能夠進行 IP 多播的本地介面。查找以每個介面域之一結尾的主機名將專門路由到匹配的介面。
- systemd.network(5)
“搜尋”和“僅路由”域都用於路由 DNS 查詢:查找以這些域結尾的主機名(因此,如果列出了任何“搜尋域”,也將單標籤名稱)路由到為此介面配置的 DNS 伺服器。
我的問題是:對於具有配置了“搜尋域”和啟用 LLMNR 的一堆介面的主機,單標籤查找請求將去哪裡?
我的困惑的更多細節:
- 如果介面配置了搜尋域“mydomain”並且禁用了 LLMNR,是否會將任何單標籤查找請求路由到該介面?
- 如果介面配置了搜尋域“mydomain”並啟用了 LLMNR,並且對“xyz”的查找請求進入,那麼通過 LLMNR 的“xyz”和通過指定 dns 伺服器的“xyz.mydomain”是否都會發生?
這個問題需要很長時間才能解釋。簡短(不精確)的描述是:
單標籤查找請求會去哪裡?
單標?(not
localhost
et al.):始終使用 LLMNR 系統。多標籤?:到每個介面的DNS伺服器。失敗時(或如果未配置),發送到全球 DNS 伺服器。
是的,一般順序如systemd-resolved.service(8) BUT中所述:
查找路由可能會受到配置每個介面域名的影響。有關詳細資訊,請參閱systemd.network(5)。
將systemd.network(5)設置為 DNS 解析的附加資源。
並且,從 RFC 4795了解:
由於 LLMNR 僅在本地鏈路上執行,因此不能將其視為 DNS 的替代品。
序列(簡化)是:
- 本地配置的主機名解析為按其範圍排序的所有本地配置的 IP 地址,或者 - 如果沒有配置 - IPv4 地址 127.0.0.2(在本地環回上)和 IPv6 地址 ::1(這是本地主機)。
- 主機名“localhost”和“localhost.localdomain”(以及任何以“.localhost”或“.localhost.localdomain”結尾的主機名)被解析為 IP 地址 127.0.0.1 和 ::1。
- 主機名“_gateway”被解析為……
- 中定義的映射
/etc/hosts
包括(前後)。- 如果要搜尋的名稱沒有點(類似名稱
home.
有點),則由 LLMNR 協議解析。LLMNR 查詢在埠 5355 上發送和接收。 RFC 4795
- 某些域後綴(如“.local”,參見完整列表)的多字(一個點或多個)名稱
systemd-resolve --status
是通過 MulticastDNS 協議解析的。- 根據每個介面的systemd.network(5)
Domains=
中的列表檢查多詞名稱,如果匹配,則使用該介面的 DNS 伺服器列表。- 其他多標籤名稱被路由到所有配置了 DNS 伺服器的本地介面,加上全域配置的 DNS 伺服器(如果有的話)。
#編輯
你的問題的標題是:
systemd-resolved 如何處理單標籤 dns 查找請求?
所以,我的答案
systemd-resolved
完全集中在上面。現在你問:
- 如果介面配置了搜尋域“mydomain”並禁用了 LLMNR,是否會將任何單標籤查找請求路由到該介面?
- 如果介面配置了搜尋域“mydomain”並啟用了 LLMNR,並且輸入了“xyz”的查找請求,那麼通過 LLMNR 的“xyz”和通過指定的 dns 伺服器的“xyz.mydomain”是否都會發生?
那些似乎是
systemd-resolved
排他性的。讓我們嘗試分析它們:
- LLMNR 禁用?如何?我可以問嗎?通過使用類似於
systemd-resolved
systemctl mask systemd-resolved
? _如果
systemd-resolved
禁用/停止,則沒有使用LLMNR(很可能,除非您安裝 Avahi、Apple bonjour 或類似程序)但可以肯定的是,這超出了systemd-resolved
配置範圍。在這種情況下,我們應該問:當名稱解析失敗時會發生什麼?(因為沒有伺服器來回答它)。這是在
nsswitch
(文件/etc/nsswitch.conf
)中配置的。Ubuntu(作為 Debian)的預設配置包含以下行:hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
這意味著(用 nsswitch 的說法):
- 首先檢查
/etc/hosts
文件。如果沒有找到,繼續。- 嘗試
mdns4_minimal
(Avahi 等人),僅當名稱以 .local 結尾時,它才會嘗試通過多播 DNS 解析名稱。如果找到但沒有找到這樣的 mDNS 主機,mdns4_minimal 將返回 NOTFOUND。對 NOTFOUND 的預設名稱服務切換響應是嘗試下一個列出的服務,但是$$ NOTFOUND=return $$entry 會覆蓋它並停止名稱未解析的搜尋。如果 mdns4_minimal 返回 UNAVAIL(未執行)然後轉到 dns。
情節加深了每個人都想成為第一個解決名字的人,每個人都提出自己做所有的決議。
- 中的
dns
條目實際上首先nsswitch
呼叫nss-resolve
它替換 nss-dnsnss-resolve 是 GNU C 庫 (glibc) 的 GNU 名稱服務切換 (NSS) 功能的外掛模組,使其能夠通過 systemd-resolved(8) 本地網路名稱解析服務解析主機名。它取代了傳統上通過 DNS 解析主機名的 nss-dns 外掛模組。
這將取決於
DOMAINS=
一般的幾個條目和/或通過文件的/etc/systemd/resolved.conf
每個介面。/etc/systemd/network
這在EDIT條目上方進行了解釋。了解 sytemd-resolved 可能會在 nsswitch 中的 dns 條目之前自行查詢 dns 伺服器。 4. 如果尚未找到(沒有
[notfound=return]
條目),請嘗試 DNS 伺服器。如果名稱不以 .local 結尾,則或多或少會立即發生,或者根本不以 .local 結尾。如果您刪除$$ NOTFOUND=return $$條目,nsswitch 將嘗試通過單播 DNS 定位未解析的 .local 主機。這通常是一件壞事,因為它會將許多此類請求發送到永遠無法解析它們的 Internet DNS 伺服器。顯然,這種情況經常發生。 5. final
myhostname
充當 localhost、主機名、.local 和其他一些基本名稱的最後*解析器。如果在與上述相同的列表中
systemd-resolved
有一個LLMNR=no
集合,則應用但仍然能夠解析和應用設置(全域或每個介面)。/etc/systemd/resolved.conf``systemd-resolved``localhost``DOMAINS=
了解systemd-resolved 中有 LLMNR 設置,systemd-networkd 中也有 per-link LLMNR 設置。 連結。
#這一切是什麼意思?除非配置非常具體,否則很難確定會發生什麼。您將不得不禁用服務並嘗試(在您的電腦上使用您的配置)會發生什麼。
#Q1
如果介面配置了搜尋域“mydomain”並禁用了 LLMNR,是否會將任何單標籤查找請求路由到該介面?
是的,當然可以。禁用 LLMNR 只會阻止本地解析(不會詢問本地(是:.local)網路上的其他伺服器)但該名稱的解析必須找到答案(即使是否定的)所以它可能(如果沒有NOTFOUND =return entry,例如)發生在開始解析
mylocalhost.mylocaldomain
時聯繫匹配介面的 DNS 伺服器以解析,並且在“搜尋域”中mylocalhost
有一個條目。籠統mylocaldomain
地回答幾乎是不可能的,變數太多了。#Q2
如果介面配置了搜尋域“mydomain”並啟用了 LLMNR,並且輸入了“xyz”的查找請求,那麼通過 LLMNR 的“xyz”和通過指定的 dns 伺服器的“xyz.mydomain”是否都會發生?
不**,如果所有配置都正確**,單個標籤名稱“xyz”應該只由 LLMNR 解析,即使被詢問,DNS 伺服器也不應該嘗試解析它。嗯,這就是理論。但是 DNS 系統必須解析
com
(顯然,否則網路會像現在這樣崩潰)。但是有一個簡單的解決方法:詢問com.
,它有一個點,它是一個 FQDN。NOERROR
在任何情況下,如果伺服器沒有足夠的關於標籤的資訊並且解析應該繼續使用根伺服器(對於) ,則 DNS 伺服器應該回答(帶有空 A(或 AAAA).
)。或者對於它知道不存在的域使用 NXDOMAIN(避免進一步解決的最佳答案)。控制這種情況的唯一安全方法是擁有本地 DNS 伺服器並選擇要解析的名稱和不解析的名稱。