macOS 26 破壞了包含 .internal 在內的自定義 DNS 設定

背景

隨著 macOS 系統更新，開發者社群發現新版本（討論中提及為 macOS 26，實則對應 Darwin 核心版本 24 或 macOS 15 之後的更新）在 DNS 處理機制上出現了重大變動。這項變動導致長期以來被開發者廣泛使用的 /etc/resolver/ 自定義 DNS 解析功能失效，直接衝擊到依賴 dnsmasq 或自定義頂級域名（如 .internal 或 .local）進行本地開發與 Docker 容器通訊的工作流程。

社群觀點

針對這次 DNS 功能的失效，社群內部的反應呈現出技術層面的除錯建議與對 Apple 系統封閉化的不滿。部分資深用戶指出，透過 /etc/resolver/ 設定補充 DNS 的做法其實早已被視為過時，Apple 官方更傾向於讓開發者使用 scutil 工具來管理系統配置。雖然 scutil 的操作相對繁瑣，且設定往往儲存在二進位的 plist 檔案中，但這似乎是目前系統架構下較為「正規」的路徑。有使用者分享了具體的替代方案，建議將自定義 DNS 伺服器（如 CoreDNS 或 dnsmasq）的監聽埠號從預設的 53 改為 5300 或其他非特權埠號，以避開 macOS 內建網路分享功能的衝突，並在設定檔中明確指定埠號，這在某些測試案例中被證明是有效的權宜之計。

除了技術性的修補建議，討論中也爆發了對 macOS 系統穩定性與開發環境友善度的激烈爭論。有開發者抱怨 macOS 佔用特定埠號（如 5000 或 8080）的行為極其「業餘」，甚至會干擾 Docker 構建過程中的封包，導致雜湊值不匹配等難以排查的問題。這種「系統服務侵佔開發資源」的現象，讓部分用戶感到 Apple 正在逐漸失去對專業開發者的吸引力。更有激進的觀點認為，Apple 應該將硬體與軟體業務拆分，因為其自研晶片的效能雖強，但作業系統的封閉性與對核心模組的限制，讓使用者感覺並未真正擁有自己的裝置。

此外，這份 Bug 報告本身也引發了關於人工智慧輔助寫作的倫理討論。由於報告中出現了「macOS 25」這種明顯錯誤的版本號（疑似混淆了作業系統版本與核心版本），部分社群成員對使用大型語言模型（LLM）撰寫技術報告表示反感。批評者認為，如果作者連基本的版本資訊都沒有校對，那麼報告中其他技術細節的準確性也令人懷疑。這種「不負責任的自動化寫作」被視為對閱讀者時間的不尊重，甚至可能導致開發者社群與官方溝通時的信任危機。

延伸閱讀

在討論過程中，有使用者提到可以嘗試使用 scutil 進行診斷與配置，這是目前 macOS 處理系統網路設定的核心工具。另外，針對本地開發環境的 DNS 路由需求，CoreDNS 與 dnsmasq 仍是社群推薦的工具，但在新版系統下可能需要調整監聽埠號以維持運作。對於受影響的用戶，建議在 Apple 發布正式修復補丁前，謹慎評估是否進行系統更新。