Log for Ubuntu 台灣社群

#無關ubuntu #網路討論

DNS 回應裡到底該先出現 CNAME，還是 A 紀錄？ （★ 109 分）

Cloudflare 表示，2026-01-08 對公共 DNS 遞迴解析器 1.1.1.1 的例行更新，原本只是為了降低快取實作的記憶體用量，卻意外引爆全球一波 DNS (Domain Name System，網域名稱系統) 解析失敗。主因不是攻擊或機房停擺，而是回應封包中資源紀錄 RR (Resource Record，資源紀錄) 的排序被「微小地改變」：部分用戶端實作假設 CNAME (Canonical Name，別名紀錄) 必須出現在答案區段最前面，一旦順序顛倒就會判定沒有答案。這個變更在 2025-12-02 進入程式碼、12-10 進測試環境，2026-01-07 晚間開始全球部署，01-08 18:19 UTC (Coordinated Universal Time，世界協調時間) 宣告事件並回復版本，19:55 回復完成後影響結束。

文章用 CNAME 鏈解釋問題如何發生：查詢 `www.example.com` 可能得到多段別名，最後才落到 A 紀錄 (IPv4 位址紀錄) 或 AAAA 紀錄 (IPv6 位址紀錄)。遞迴解析器會把鏈上的每一段以各自的 TTL (Time-To-Live，快取存活時間) 快取起來；當鏈的一部分過期時，只需重新解析過期那段，然後把「仍有效的 CNAME 鏈」與「新解析出的 A/AAAA」合併回一個回應。Cloudflare 為了減少記憶體配置與拷貝，把原本「先放 CNAME、再放 A/AAAA」的合併邏輯，改成直接把 CNAME 追加到既有答案清單尾端，導致某些情況下 CNAME 反而出現在 A/AAAA 之後。對採「逐筆序列掃描」的用戶端來說，它們會用「目前期待的名稱」去比對每筆紀錄，先看到不符合的 A 會被忽略，等看到 CNAME 才更新期待名稱，但此時清單已經掃完，於是回應被當成空的。受影響案例包含 Linux 常用的 glibc (GNU C Library，GNU C 函式庫) `getaddrinfo` 解析流程，以及部分設定使用 1.1.1.1 的 Cisco 乙太網路交換器，其 DNSC 行程甚至會因此進入重開機迴圈；相對地，systemd-resolved 這類會先把所有答案收集成可查詢集合、再依名稱搜尋追鏈的實作則不受影響。

Cloudflare 進一步把矛頭指向標準文字的「歷史性含糊」。DNS 核心規範 RFC 1034 (Request for Comments，網際網路標準文件) 在描述遞迴回應時用到「possibly preface」這種非強制語氣，且年代早於 RFC 2119 對 MUST/SHOULD 等規範用語的標準化；同時，RFC 對 RRset (Resource Record Set，同名同型別同類別的一組紀錄) 只明確說「同一個 RRset 內順序不重要」，卻沒有清楚規定「不同 RRset 在同一個答案區段的相對順序」，讓 CNAME 與 A/AAAA 的排列空間出現灰色地帶。文章也指出，即使都放在前面，CNAME 鏈本身若不是照鏈順序排列，序列掃描同樣會斷鏈。就實作者責任而言，RFC 提到遇到 CNAME 會「重啟查詢」，但那多以完整解析器為前提；實務上多數應用程式使用的是 stub resolver (簡化版本機解析器，如 glibc)，未必照該模型處理。Cloudflare 最終決定尊重既有生態：回復原排序，未來也打算固定讓 CNAME 依序出現在其他答案之前，並提出 IETF (Internet Engineering Task Force，網際網路工程任務組) Internet-Draft，希望把「答案區段需有序」正式寫進可落地的標準。

Hacker News 討論多把此事視為 Hyrum’s Law（使用者夠多時，任何可觀察行為都會被依賴）在基礎網路協定上的示範，並延伸到 Postel’s Law（傳送要保守、接收要寬鬆）是否仍適用：有人主張「寬鬆接收」會縱容更糟的送出行為，甚至認為應該「盡早失敗」；也有人認為可寬鬆但要有警告期，隨即遭反問「像 DNS 這種協定要把警告放哪裡」。不少留言質疑 Cloudflare 竟未用 glibc 這類最常見用戶端做相容性測試；也有人替其解釋，測試可能只驗證紀錄「存在」而非「順序」，加上標準文字不夠硬，使得排序檢查未被寫成斷言。另有一派直指 RFC 1034 的句子其實不含糊，「possibly」是在說 CNAME 不一定存在、但存在就應該放前面；不過即便爭論標準解讀，許多人仍認同 Cloudflare 的務實結論：面對難以更新的舊設備，只能配合既成事實。討論也觸及營運面：回復部署耗時約 1 小時 28 分鐘，有人慶幸它不至於更快、並強調全球變更（含回復）也該分批觀察；另有人建議除提新草案外，應考慮對舊 RFC 提 errata (勘誤) 或在被取代文件上加醒目提示。最後，還有讀者趁機吐槽「It’s always DNS」：例如 SERVFAIL（伺服器失敗）無法區分是遞迴端故障或權威端出錯，EDE (Extended DNS Error，延伸 DNS 錯誤) 也難完全解；以及 search path 造成大量 NXDOMAIN（不存在網域）嘗試、加上遞迴與快取解析器（如 Unbound）層層重試，讓上游流量看起來像被放大攻擊。

👥 38 則討論、評論 💬
https://news.ycombinator.com/item?id=46681611

88

我一直都忘記做筆記了

網域的設定方面，以前查半天的資料才知道怎麼設定DNS

OzLabs 成員全數離開 IBM

OzLabs 是一個澳洲自由軟體開發者組織，該組織成員負責了許多知名的開放原始碼專案，如 Samba、rsync、Linux PPP、Linux netfilter、Linux Advanced Power Management (APM) 與 OpenBMC。該組織成立於 1999 年，由 Linuxcare 聘請 Andrew Tridgell 負責籌組。Linuxcare 在 2001 年的動盪導致大多數成員離開，他們加入 IBM Linux Technology Center，從事 PowerPC Linux 及相關專案。但截至 2026 年 1 月，所有成員都已離開 IBM，結束 OzLabs 與 IBM 長達 25 年的合作關係。
https://lwn.net/Articles/1055051/

https://lwn.net/Articles/1055051/

可在使用者空間 (userspace) 進行 PCIe 裝置模擬的 Linux 核心框架 （★ 105 分）

PCIem 是一套用 C 撰寫的 Linux 核心框架，目標是在沒有實體硬體的情況下，讓開發者能開發與測試 PCIe (Peripheral Component Interconnect Express，高速周邊互連匯流排) 裝置的驅動程式。它透過在核心中建立「看起來像真的」合成 PCIe 裝置，讓主機作業系統與既有的正式版驅動程式在不改動邏輯的前提下直接掛載；真正的裝置行為則交由使用者空間 (userspace) 撰寫的「PCI shim」來實作，等於把「做出一張卡」變成可快速迭代的軟體開發工作。

在架構上，PCIem 於核心端提供 /dev/pciem 介面，負責把合成裝置註冊進 PCI 匯流排、維護 PCI 設定空間 (PCI config space)、建立與管理 BAR (Base Address Register，基底位址暫存器) 對映，並處理中斷機制如 IRQ (Interrupt Request)、MSI (Message Signaled Interrupts) 與 MSI-X。資料傳輸方面它提供 DMA (Direct Memory Access，直接記憶體存取) 機制，並可感知 IOMMU (Input-Output Memory Management Unit，I/O 記憶體管理單元) 的存在以處理位址轉換與限制，同時也涵蓋 P2P DMA (peer-to-peer DMA，裝置對裝置的直接 DMA) 並用白名單控管可互通的對象。它還引入以 CPU 監看點 (watchpoint) 偵測存取的事件驅動設計，以及模組化的 PCI capability 架構，讓合成裝置能更貼近真實硬體的行為。

專案展示了多個「用真實驅動去驅動不存在的卡」的例子：例如 ProtoPCIem card 把裝置初始化與命令處理放在 QEMU (機器模擬器) 端，主機上跑的驅動程式對裝置的讀寫會被轉送到 QEMU，最後能跑軟體算圖的 DOOM，甚至支援 OpenGL 1.x 的一些遊戲。作者也提到做過簡單的 NVMe (Non-Volatile Memory Express) 控制器原型，用 malloc 配出 1GB 的「碟」就能讓 Linux 的 nvme 區塊裝置驅動正常掛上，進而格式化、掛載與建立檔案/資料夾。由於裝置的出現與移除只需要開啟或關閉使用者空間 shim，測試修改可以反覆快速進行；授權則以 MIT 為主，部分檔案採 MIT/GPLv2 雙授權。

Hacker News 討論普遍認為這對驅動與硬體研發是「迭代速度」上的巨大提升，作者也補充典型情境包含：在尚未拿到晶片前先把 NVMe/RAID/NIC (Network Interface Card，網路介面卡) 驅動雛形寫好、對既有驅動做資安測試、刻意注入故障來驗證容錯（例如模擬裝置異常、甚至在不關機下從匯流排消失），以及把功能/行為測試放進 CI/CD (Continuous Integration/Continuous Delivery，持續整合/持續交付) 於一般伺服器上跑。也有人拿 FPGA (Field-Programmable Gate Array，現場可程式化閘陣列) 原型卡當對照：FPGA 在時序與真實性上更好，但硬體板卡與工具鏈成本高；相對地，PCIem 以免費、在 userspace 快速試驗為賣點。另一些留言延伸到「用另一台裝置當 PCIe 端點」的想像（例如 Raspberry Pi 或可做 endpoint mode 的 ARM/STM32MP2 類晶片），並討論 x1 通道頻寬限制下哪些工作負載仍可行；也有人補充 Linux 其實已有 nvme-pci-endpoint-target 這類把裝置假扮成 NVMe 的既有路徑。關於更進階的應用如把主機 GPU 切分給 VM (virtual machine，虛擬機器)，作者回應正在探索類似 passthrough 的可能性，但難點在於裝置解除綁定、IOMMU 與中斷路由重設等核心子系統協作。討論串也岔到 PCIe 是否未來 5–10 年仍值得投資，較多人的看法是短期不易被取代（即使未來走向光纖連接，協定與生態也可能長期延續），並有人提醒：許多驅動 bug 只在特定時序或裝置回應異常時才會爆出，這類可控的合成裝置對除錯與測試特別有價值。

👥 30 則討論、評論 💬
https://news.ycombinator.com/item?id=46689065