前言：這算是一篇學習筆記，如有錯誤，請透過郵件聯絡我！ 封面圖使用ChatGPT DALL·E 3 模型生成
這幾天我在研究Qubes OS ，這是一個主打隱私隔離的作業系統。 Qubes OS通過虛擬機（稱為Qube）來隔離不同的操作環境和功能，例如網路和應用操作是分別在不同的Qube中運行。
我這次的使用場景使用到4個Qube，分別是sys-net、sys-firewall、sys-vpn及APP VM
-
sys-net是負責與真實網路硬體（例如有線或無線網卡）直接互動的VM，也就是最底層接入外部網際網路的部分。它負責管理物理網路流量，並提供給上層VM使用。 在此架構中，Net VM通常是最不信任的環境，因為其直接接觸外部網路，存在攻擊風險。
-
sys-firewall（防火牆VM）只負責處理網路監控和過濾工作，不執行應用程式，降低攻擊面。 需要為它設置Net VM處理網路流量的進出，在這個場景中是設為sys-net。
-
sys-vpn配置VPN服務（像是WireGuard），負責加密與轉發所有從APP VM發出的流量，確保所有網路通訊經過VPN隧道。 而他的Net VM則是設為sys-firewall。
-
APP VM（應用虛擬機）是實際執行應用程式的VM，其Net VM設定為前述的VPN VM，因此所有APP VM流量皆會先進入sys-vpn，再到sys-firewall，最後通過sys-net存取外部網路。
在我的使用場景中，我在sys-vpn中使用了Wireguard作為VPN，並指定了我自架的DNS伺服器，目的是透過自架的DNS解析局域網域名，便於連進我自架的服務。
我原本使用的局域網局域名是以.local作為頂級域名。
然而，問題出現了：不管我怎麼設置，甚至APP VM的DNS請求都引導到sys-vpn解析，系統仍然會出現name resolution錯誤。
一查之下1後發現，這問題與.local這個頂級域名的特殊用途有關。
.local是根據網路標準（RFC 6762）保留給多播 DNS（mDNS）使用的本地鏈路名稱空間。 多播 DNS 不同於傳統 DNS，它使用 UDP 5353 多播封包直接在同一局域網路中尋找服務或設備，因此避免了傳統 DNS 伺服器的參與。
白話來說，傳統DNS就像你問大樓管理員：「柚子的房間在幾號？」這個管理員知道每個人住哪裡，幫你找房號（IP地址），要去問那個管理員才知道答案。
但是 mDNS 就像你在一個公眾場合，你直接喊「柚子在哪？」，柚子就會自己回答你，大家都能知道他的位置。這樣不用找管理員，也很快能知道答案。
常見使用mDNS的裝置例如：
- 智能家居設備
- 印表機
- 局域網內的文件共享或服務自動發現
- 蘋果（Apple）的產品
但延伸出的問題就是安全性較低，因為mDNS的查詢和回應沒有身份驗證和加密，容易被局域網內其他設備截取或攻擊，尤其在公共或不安全的網路環境中風險較高。
而Qubes OS 啟用了 systemd-resolved ，這套服務會監控並攔截對 .local 域的 DNS 查詢，嘗試使用 mDNS 解析，這也導致 .local 查詢無法正常被轉發給傳統 DNS。這也是為什麼我上面進行了許多嘗試都無法成功。
最後我選擇的解決方法是：不使用.local作為局域網的頂級域名。
選擇如.lan、.home、.private、.corp、.network、.site或.internal等其他非全球域名系統中使用的私有頂級域名，確保DNS會用標準解析方式進行。
儘管還是有保留使用.local作為頂級域名的其他方案，但就如同上述所說的，.local主要用於服務自動發現，這也導致安全性與地址衝突的問題。
於是我又花了將近兩個小時重新整理了 home lab 中所有關於本地域名的設定… 但也好，早發現總比晚發現好。
透過郵件回覆
