UTC 時間 2023 年 7 月 9 日星期日凌晨，我們觀察到大量 DNS 解析失敗（佔整個亞太地區所有 DNS 查詢的 7%），這是由 Verisign .com 和 .net 頂層網域 (TLD) 名稱伺服器的無效 DNSSEC 簽名造成的。這導致該地區 Cloudflare 上網際網路內容的訪客出現連線錯誤。
Verisign 名稱伺服器的本機執行個體開始在亞太地區使用過期的 DNSSEC 簽名進行回應。為了補救影響，我們已將指向 Verisign 的上游 DNS 查詢重新路由到美國西海岸，並由後者傳回有效簽名。
我們已經與 Verisign 聯繫，以獲取有關根本原因的更多資訊。在他們的問題得到解決之前，我們將繼續對前往 .com 和 .net TLD 名稱伺服器的 DNS 流量進行重新路由，這可能會導致該地區 .com 和 .net 下網域的第一個訪客的延遲略有增加。
背景
要透過 Cloudflare 網路代理網域流量，從 Cloudflare 資料中心的角度來看，涉及 Domain Name System (DNS) 的兩個元件：外部 DNS 解析和上游或源站 DNS 解析。
為了理解這一點，讓我們看一下透過 Cloudflare 的網路進行代理的網域名稱 blog.cloudflare.com，並假設它設定為使用 origin.example 作為來源伺服器：
此處，在公用解析程式（如 1.1.1.1 或 8.8.8.8）代表訪客向 blog.cloudflare.com 傳送 DNS 查詢並傳回一組 Cloudflare Anycast IP 位址的過程中，會進行外部 DNS 解析。這可確保訪客的瀏覽器知道向何處傳送 HTTPS 請求來載入網站。在後台，您的瀏覽器會執行類似如下的 DNS 查詢（尾部的點表示 DNS 根區域）：
（您的電腦內部實際上並沒有使用 dig 命令；我們用它來說明該過程）然後，當下一個最近的 Cloudflare 資料中心收到對 blog.cloudflare.com 的 HTTPS 請求時，它需要從來源伺服器擷取內容（假設沒有快取）。
$ dig blog.cloudflare.com. +short
104.18.28.7
104.18.29.7Cloudflare 可以透過兩種方式到達來源伺服器。如果 Cloudflare 中的 DNS 設定包含 IP 位址，那麼我們可以直接連線到源站。在某些情況下，我們的客戶使用 CNAME，這意味著 Cloudflare 必須執行另一個 DNS 查詢才能獲取與 CNAME 關聯的 IP 位址。在上面的範例中，blog.cloudflare.com 有一條 CNAME 記錄，指示我們查看 origin.example 中的 IP 位址。在此次事件中，只有具有此類 CNAME 記錄且造訪 .com 和 .net 網域名稱的客戶可能會受到影響。
需要在進行上游或源站 DNS 解析的過程中，由 Cloudflare 對網域 origin.example 進行解析。此時，Cloudflare 資料中心需要執行如下所示的輸出 DNS 查詢：
DNS 是一種分層通訊協定，因此遞迴 DNS 解析程式（通常為想要解析網域名稱的人處理 DNS 解析）需要與多個相關的名稱伺服器通訊，直到最終從網域的權威名稱伺服器獲得答案（假設沒有快取 DNS 回應）。外部 DNS 解析和源站 DNS 解析過程也是如此。以下是源站 DNS 解析的範例：
$ dig origin.example. +short
192.0.2.1從本質上講，DNS 是一個公用系統，最初發佈時沒有任何方法來驗證 DNS 流量的完整性。因此，為了防止有人假冒 DNS 回應，引入了 DNS 安全擴展 (DNSSEC)，作為驗證 DNS 回應是否確實來自所聲稱來源的方法。這是透過在現有 DNS 記錄（如 A、AAAA、MX、CNAME 等）旁邊產生加密簽名來實現的。透過驗證 DNS 記錄的關聯簽名，可以驗證所請求的 DNS 記錄是否確實來自其權威名稱伺服器，並且在途中沒有被更改。如果無法成功驗證簽名，遞迴解析程式通常會傳回一個錯誤，表明簽名無效。這正是周日發生的事情。
事件時間表和影響
我們的記錄顯示，在 UTC 時間 2023 年 7 月 8 日（星期六） 21:10，亞太地區多個 Cloudflare 資料中心在上游 DNS 解析過程中發生第一例 DNSSEC 驗證錯誤。來自 .com 和 .net 類型 NSEC3（一種用於證明不存在 DNS 記錄的 DNSSEC 機制）的 TLD 名稱伺服器的 DNS 回應似乎包含無效簽名。大約一小時後，UTC 時間 22:16，第一個內部警示響起（只有當問題持續一段時間後才會發出警示），但錯誤率仍處於所有上游 DNS 查詢的 0.5% 左右。
幾個小時後，錯誤率上升，受影響位置約 13% 的上游 DNS 查詢失敗。事件發生期間，該百分比持續波動，範圍為亞太地區受影響 Cloudflare 資料中心上游 DNS 查詢的 10-15%，以及所有 DNS 查詢（外部和上游解析）的大約 5-7% 。
最初似乎只有一個上游名稱伺服器存在 DNS 解析問題，但經過進一步調查，發現該問題分佈範圍更廣。最終，我們能夠確認 .com 和 .net 的 Verisign 名稱伺服器在亞太地區的部分 DNS 查詢上傳回過期的 DNSSEC 簽名。根據我們的測試，其他名稱伺服器位置可以正確傳回有效的 DNSSEC 簽名。
作為回應，我們將 DNS 流量重新路由至 Verisign 美國西部地點的 .com 和 .net TLD 名稱伺服器 IP 位址。在進行此變更後，問題極為快速地消退，源站解析錯誤率恢復到正常水平。
所有時間均為 UTC 時間：
2023-07-08 21:10 我們的源站 DNS 解析記錄中出現了第一例 DNSSEC 驗證錯誤。
2023-07-08 22:16 亞太資料中心首次內部警示響起，表明我們的測試網域上出現源站 DNS 解析錯誤。此時其他網域的錯誤很少。
2023-07-09 02:58 自第一次發生以來，錯誤率已大幅增加。宣佈發生了網路事件。
2023-07-09 03:28 DNSSEC 驗證問題似乎被溯源到單個上游提供者。單個上游在向我們回傳時出現問題並不異常，在這種情況下，我們的記錄主要顯示來自解析到此特定上游的網域的錯誤。
2023-07-09 04:52 我們意識到 DNSSEC 驗證問題範圍更廣，並影響多個 .com 和 .net 網域。驗證問題繼續僅限於亞太地區，並且似乎是間歇性的。
2023-07-09 05:15 此時，透過常用的遞迴解析程式（如 8.8.8.8 和 1.1.1.1）進行的 DNS 查詢不會傳回無效的 DNSSEC 簽名。使用本機存根解析程式的 DNS 查詢繼續傳回 DNSSEC 錯誤。
2023-07-09 06:24 來自新加坡 .com 和 .net Verisign 名稱伺服器的回應包含過期的 DNSSEC 簽名，但來自其他位置的 Verisign TLD 名稱伺服器的回應沒有問題。
2023-07-09 06:41 我們聯絡 Verisign 並通知他們有關過期 DNSSEC 簽名的事情。
2023-07-09 06:50 為了補救影響，我們透過 IPv4 將 .com 和 .net Verisign 名稱伺服器 IP 的 DNS 流量重新路由到美國西部 IP。這立即導致錯誤率大幅下降。
2023-07-09 07:06 我們還透過 IPv6 將 .com 和 .net Verisign 名稱伺服器 IP 的 DNS 流量重新路由到美國西部 IP。這導致錯誤率降至零。
2023-07-10 09:23 重新路由仍在進行，但亞太地區簽名過期的底層問題仍未得到解決。
2023-07-10 18:23 Verisign 回覆我們，確認他們在當地的網站「提供過時的資料」，並解決了這些問題。
錯誤的技術說明及其發生的原因
正如概述中提到的，此事件的根本原因是 .net 和 .com 區域的 DNSSEC 簽名過期。過期的 DNSSEC 簽名將導致 DNS 回應被解譯為無效。使用者觀察到這個錯誤有兩種主要情況：
外部 DNS 解析的 CNAME 展平。這是我們的權威名稱伺服器嘗試傳回 CNAME 記錄目標解析的 IP 位址而不是 CNAME 記錄本身的情況。
源站 DNS 解析的 CNAME 目標查閱。當 HTTPS 請求傳送到 Cloudflare Anycast IP 位址時最常使用，我們需要確定將請求轉寄到哪個 IP 位址。如需更多詳細資料，請參閱 Cloudflare 的運作原理。
在這兩種情況下，DNS 查詢在幕後都會透過內部遞迴 DNS 解析程式來查閱主機名解析的內容。該解析程式的目的是快取查詢、最佳化未來查詢並提供 DNSSEC 驗證。如果此解析程式的查詢由於某種原因失敗，我們的權威 DNS 系統將無法完成上述兩個過程。
事件期間，遞迴解析程式無法驗證以 .com 和 .net 結尾的網域之 DNS 回應中的 DNSSEC 簽名。這些簽名以 RRSIG 記錄的形式與其他相關 DNS 記錄一起傳送。它們一起形成一個資源記錄集 (RRset)。每個 RRSIG 都有相應的欄位：
如您所見，有效負載的主要部分與簽名及其相應的中繼資料相關聯。每個遞迴解析程式不僅負責檢查簽名，還負責檢查簽名的到期時間。遵守到期時間十分重要，這樣可以避免為已經用舊金鑰簽名的 RRset 傳回回應，因為到那個時候，舊金鑰可能已經洩露了。
在此事件中，.com 和 .net TLD 區域的權威營運商 Verisign 偶爾會在亞太地區的 DNS 回應中傳回過期簽名。因此，我們的遞迴解析程式無法驗證相應的 RRSet。最終，這意味著一定比例的 DNS 查詢將傳回 SERVFAIL 作為對我們權威名稱伺服器的回應代碼。這反過來又會導致嘗試連線到 Cloudflare 上網域的使用者遇到連線問題，由於我們無法解析受影響網域名稱的上游目標，因此不知道將代理的 HTTPS 請求傳送到上游伺服器的何處。
補救措施和後續步驟
在確定根本原因後，我們就開始研究解決問題的不同方法。我們得出的結論是，解決這個區域性問題的最快方法是停止使用通往 Verisign 名稱伺服器的本機路由。這意味著，在撰寫本文時，我們在亞太地區發往 Verisign 名稱伺服器的傳出 DNS 流量現在穿越太平洋並最終到達美國西海岸，而不是由更近的名稱伺服器提供服務。由於 DNS 的性質以及 DNS 快取的重要作用，這所產生的影響比您最初預期的要小。頻繁查閱的名稱將在第一次請求後進行快取，每個資料中心只需要進行一次即可，因為我們共用並集中本機 DNS 遞迴程式快取，以最大限度地提高其效率。
理想情況下，我們將能夠立即修復該問題，因為它也可能影響到該地區的其他人，而不僅僅是我們的客戶。因此，我們將努力改善與其他提供者的事件通訊渠道，以確保 DNS 生態系統在此類問題上保持穩健。在出現此類緊急問題時，能夠迅速聯繫到其他可以採取行動的提供者至關重要。
結論
這次事件再次表明了 DNS 故障的影響有多大，以及這項技術對於網際網路的重要性。我們將研究如何改進我們的系統，以便在將來再次發生此類問題時能更有效、更快速地偵測和解決問題。
雖然 Cloudflare 不是造成此問題的原因，並且我們確信我們不是唯一受此影響的人，但我們仍然對我們的客戶以及所有在此次事件期間無法存取網際網路內容的使用者表示歉意。
更新：UTC 時間 2023 年 7 月 11 日（星期二）22:24:21_，_Verisign 發布了一則公告，提供了更多詳細資料：
上週，在我們將新加坡的一個 DNS 解析站點從一個提供者遷移到另一個提供者的過程中，我們意外地失去了管理存取權限以及向該站點提供變更和 DNS 更新的能力。按照我們的標準程序，我們停用了前往受影響站點的所有傳輸連結。不幸的是，一個對等互連路由器仍然處於作用中狀態，由於那裡缺乏連線性，我們的團隊並沒有立即注意到。
上週末，這引發了一個問題，由於該網站上的 DNSSEC 簽名開始過期，可能影響了該地區一些網際網路使用者存取某些 .com 和 .net 網域的能力。透過關閉該站點的對等互連路由器電源，撤回 Anycast 路由公告，並將流量導向到其他站點，該問題得到了解決。
我們正在更新我們的流程和程序，並將努力防止此類問題在將來再次發生。
我們在全球擁有 200 多個站點，建立了強大的備援，新加坡站點也是其中一個。該問題對 .com 和 .net 全球核心解析沒有影響。對於已經受到影響的人，我們深表歉意。