原文: [https://blog.cloudflare.com/o...]
譯: 時序

“FB不會當機，不是嗎？”，我們想了幾分鐘這個問題

今天2021.10.4 16:51 UTC，我們建了一條標題為“FB DNS 查詢返回SERVFAIL”的單子，因為我們擔心我們的DBS 1.1.1.1出現了問題。但當我們要在我們的的[公共狀態]頁面釋出狀態時我們發現可能有更嚴重的問題正在發生。

社交媒體迅速發酵報導了這件事同時我們的工程師也確認了。FB以及它的關聯服務WhatsApp與Instagram也全宕了。它們的DNS域名停止瞭解析，它們的基礎設施IP也不可用了。那就像是有人將他們的資料中心同時“拔了網線”，讓他們從網際網路上消失了。

這怎麼會發生呢？

會會BGP

BGP的全名是邊界閘道器協議(Border Gateway Protocol)。它是一種用來在網際網路上的自主Autonomous系統(AS)與路由資訊交換資訊的協議。巨大的的路由讓網際網路可以讓路由快速更新連通的列表來傳遞網路包到目標地址。沒有BGP，網際網路路由不知道怎麼做，網際網路就不工作了。

網際網路基本上就是一堆網路中的網路，它是被BGP協議劃分。BGP讓一個網路(這裡是指FB)來向網際網路中的其他網路告知其的存在。由於我們前面提到FB沒有廣播它的存在，ISP服務商和其他網路不知道如何能找到FB的網路，所以它就不可用了。

每個獨立的子網都有一個ASN：(Autonomous System Number)。一個Autonomous系統(AS)都是一個使用了單獨內部路由策略的獨立網路。一個AS可以生成字首（表明它們控制一組IP地址），其也可以傳送字首（表明它們知道如果抵達一組特定的IP地址）。

Cloudflare的ASN是AS13335.每個ASN都要使用BGP宣告它的字首路由到網際網路；不然的話，沒有人知道如何連上並查詢我們。

我們的[學習中心]有對於[BGP]和[ASN]如何工作的很好的資料。

這是一張簡化的圖，你能看到網際網路有6個autonomous系統，2條一個資料包可以用來從開始點到結束點的路由。 AS1->AS2->AS3是最快的，AS1->AS6->AS5->AS4->AS3是最慢的，但如果第一條路出問題了也可以走。

在1658UTC我們注意到FB停止向路由廣播它們的DNS字首。這表示，至少FB的DNS伺服器不可用了。由於這個原因Cloudflare的1.1.1.1的DNS無法回答對於facebook.com或instagram.com的IP地址查詢。
route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>

route-views>show ip bgp 129.134.30.0/23
% Network not in table
route-views>
同時，其他的FB IP地址仍然是可路由的，但由於沒有FB的DNS相關資訊基本沒什麼用：
route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
Paths: (24 available, best #14, table default)
Not advertised to any peer
Refresh Epoch 2
3303 6453 32934

217.192.89.50 from 217.192.89.50 (138.187.128.158)
  Origin IGP, localpref 100, valid, external
  Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402
  path 7FE1408ED9C8 RPKI State not found
  rx pathid: 0, tx pathid: 0

Refresh Epoch 1
route-views>

我們持續追蹤我們在全球網路中看到的BGP更新和宣告。在我們的這裡，收集的資料給了我們一個網際網路如何連線和流量在全球從哪來到哪去的檢視。

BGP更新的訊息告訴路由任何你對字首或整體的廣播都要撤銷字首。當檢查我們的時序BGP資料庫時可以清晰的看到我們從Facebook收到的一系列更新。通常這張圖很平靜：FB不會產生很多變更。

但在15:40 UTC我們看到從Facebook看到路由變更的尖峰。這就是問題開始的時候。

如果我們將路由宣告與撤銷分開看，我們能更清楚的看到問題。路由在插銷，Facebook的DNS伺服器在掉線，問題發生一分鐘後，Cloudflare工程師在一間屋子裡想確定為什麼1.1.1.1不能解析facebook.com的地址，並在擔心那是我們系統的一個問題。

由於這些撤銷事件，Facebook和它的站點很快的從網際網路斷開。

DNS受到影響

由於這個問題直接的影響，全世界的DNS解析停止解析它們的域名。
➜ ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @1.1.1.1 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
➜ ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @8.8.8.8 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
發生這個是因為DNS與網際網路上的其他系統一樣，有它自己的路由機制。當有人在瀏覽器開啟https://facebook.com後，DNS解析，響應域名查詢的請求並返回需要連線的IP地址，最初會檢查它的快取中是否存在並使用快取。如果沒有，則從域名伺服器上抓取答案，一般是由掌管它的實體來負責。

如果域名伺服器不可達或由於一些原因不能響應，則SERVFAIL會返回，瀏覽器則返回錯誤給使用者。

一樣的，我們的學習中心提供了DNS如何工作的[解釋]。

當Facebook停止通過BGP來廣播它們的DNS字首路由，我們和其他人的DNS服務就無法連線它們的域名伺服器。然後，1.1.1.1，8.8.8.8和其他主要的公共DNS伺服器開始發出（或快取的）SERVFAIL響應。

但這不是全部。現在人類行為和程式邏輯一起導致了其他指數效應。DNS請求產生了海嘯。

這個問題部分是由於app不接受返回的錯誤並開始重試，另一部分原因是終端使用者不管錯誤的請求並開始重刷頁面，或殺掉他們並重啟app，也造成了大量請求。

這是我們看到在1.1.1.1上的流量增加：

到這，由於Facebook和它的網站太大，我們的DNS處理比平時大30倍的查詢量並導致了其他平臺的延遲和超時問題。

幸運的是，1.1.1.1是打造成免費，快速（正如獨立DNS檢測工具DNSPerf證明的那樣），可擴充套件，我們可以保證服務的情況下最小的影響使用者。

我們DNS請求能保持到低於10ms。同時，p95和p99的百分位能看到響應時間的增加，很可能是由於失效的TTL需要重新請求Facebook域名伺服器併產生超時。DNS的超時時間限制在10秒是工程師預設的規則。

影響其他服務

人們開始轉向其他服務並想要知道到底發生了什麼。當Facebook不可用了，我們看到對Twitter，Signal和其他訊息，社交媒體平臺的DNS訪問量在增加。

我們能到從Facebook影響的ASN 32934在本次不可用對於WARP流量的負面影響。這張圖能看到從15:45 UTC到 16:45 UTC之間在每個國家與3小時前比流量是如何變化的。全世界WARP流量從Facebook網路進出的流量都消失了。