註冊資料一改，運作正常的網路為何可能消失？

想像一下，你的服務透過行動網路仍能正常使用，另一個網路上的客戶卻已無法連上。伺服器沒有故障，線路也都接著。一種可能的解釋是：某筆紀錄變更後，另一個網路不再接受通往你所用位址的路由。

缺少的那一環，是紀錄與路由器之間的決策。當系統利用資料庫的變更建立篩選規則或評估路由宣告時，這項變更就可能影響連線。要理解故障，就得沿著這條鏈追查。「註冊資料有誤」只是診斷的起點。

紀錄變更影響路由的接受與否時，實體連線仍可能完好。應循著證據與接收政策追查。

首先，問清楚是哪一筆紀錄變了

IP 前綴是一段位址區塊。自治系統編號，簡稱 ASN，用來識別與其他網路交換路由的網路。BGP 則是這些網路用來宣告自己能到達哪些目的地的協定。

在這種交換之外，還有幾類相關紀錄。它們回答的是不同問題：

• 註冊紀錄：某個位址區塊登記在哪個組織名下，以及應聯絡誰。RIPE 資料庫文件區分了資源註冊、路由資訊與聯絡紀錄，即使它們存放在同一個資料庫中。
• 網際網路路由註冊資料庫（IRR）紀錄：營運商可以利用這些資訊，建立願意接受的路由清單。紀錄描述的是預期的路由安排；它本身並不宣告路由。
• 資源公鑰基礎設施（RPKI）紀錄：其中包括經簽署的路由來源授權，稱為 ROA。驗證器據此產生資料，用來檢查來源網路與允許的前綴長度。

過期的聯絡電子郵件不會直接撤回 BGP 路由。供應商產生的篩選規則若漏掉一條路由，卻可能使該供應商不再接受它。把兩者都稱為「無效的註冊資料」，會掩蓋真正重要的差異。

一筆紀錄如何導致路由被拒絕

假設一家供應商根據 IRR 資料建立客戶路由的篩選規則。以下是一種可能的故障順序：

1. 某筆路由紀錄被移除，或客戶的路由集合不再包含它。
2. 供應商下次建立篩選規則時，漏掉了這條路由。
3. 新規則傳到供應商的路由器，路由器因而拒絕客戶的宣告。
4. 如果沒有可用的替代路徑，依賴這條路徑的人就會失去存取能力。

只有這些資料實際被用來建立該篩選規則，這條因果鏈才會發生。NTT DATA 公開的路由註冊政策提供了一個具體例子，說明如何根據 IRR 建立客戶篩選規則並自動更新。政策也記載了拒絕 RPKI Invalid 路由及排除相衝突 IRR 紀錄的做法。這些都是可辨識的運作機制，並非註冊機構掌握的一個通用斷網開關。

RPKI 的「Invalid」究竟代表甚麼

來源驗證會將正在宣告的路由與經過驗證的授權資料比對。RFC 6811定義了三種結果：

• Valid（有效）：至少有一筆涵蓋該路由的授權，同時符合來源 ASN，並允許宣告中的前綴長度。
• Invalid（無效）：存在涵蓋該路由的授權資料，但沒有任何一筆同時符合這兩個條件。
• NotFound（未找到）：沒有授權資料涵蓋該路由。

例如，網路 A 宣告的一條路由，如果與它相符的授權消失，而網路 B 的一筆涵蓋授權仍在，就可能變成 Invalid。如果已沒有任何涵蓋授權，結果則是 NotFound。這裡的「Invalid」是路由驗證的結果，不是對所有權或機構正當性的裁決。來源驗證也不會認證路由宣稱經過的整條路徑。

接下來才是營運商設定的政策。RFC 8481將設定驗證狀態與依狀態採取行動分開：政策必須由營運商設定。設定為拒絕 Invalid 路由的網路，隨後就可能拒絕這項宣告。註冊資料的修改與拒絕路由，是透過這套機制連起來的；它們不是同一件事。

為何有些人會先失去存取能力

各個網路不會在同一時間使用完全相同的篩選規則、供應商或資料。RFC 7115說明了 RPKI 快取可能持有不同的資料視圖，更新傳到路由器也沒有一個統一且有保證的時間間隔。

在開頭的例子中，一個網路可能已根據變更後的資料採取行動，另一個網路卻仍有獲接受的路徑。因此，局部中斷是可能的。但這不能證明某次特定中斷是由註冊資料造成：工程師仍須檢查受影響的路由、實際使用的資料，以及拒絕它的決策。

在改動更多東西之前，先找出斷在哪一環

有助於恢復服務的問題很具體：哪個系統不再接受哪項宣告，為甚麼？營運商可以與供應商逐步查明：

1. 辨識宣告。記錄受影響的前綴與來源 ASN，並檢查預期的路由是否仍在宣告。
2. 找出拒絕發生的位置。將供應商已安裝的篩選規則與驗證結果，和該路由作比對。問清楚是哪個資料來源、哪次更新產生了這項決策。
3. 保留證據。保存相關紀錄、觀察結果與時間戳記，以便區分錯誤更新與未經授權的宣告。
4. 修正並驗證。協調所需的精確紀錄或設定修正，確認修正已傳到使用這些資料的系統，並從先前無法連線的網路測試存取。

全面停用驗證，也會移除對錯誤宣告的防護。實務上的工作是恢復正確的證據與預期的路由，再驗證結果。僅僅成功修改資料庫，並不能證明客戶已能重新連線。

更深一層的問題：有用的證據可能變成集中的權力

技術鏈條在這裡與盧恒的論點相交。管理者不必轉送任何人的封包，也能影響他們的可達性。如果其他系統依賴它所控制的紀錄，它的決定就可能讓遠在其辦公室之外的營運商與客戶付出代價。

在第65篇筆記〈運行代碼優先〉中，盧恒主張，協調必須以運作中網路的需求為界。維護紀錄的角色不能自行擴張為永久的政治授權。一筆紀錄經過簽署，回答的是關於該聲明的技術問題；這並不確立治理所有受其影響者的權利。

他的提案不只是改善申訴程序。共同規則應保障唯一性、可驗證的控制權及互通性，同時由參與者在本地驗證狀態，決定採用哪些相容變更。另設一個擁有無限否決權的委員會，只會讓同樣的問題換個名字重現。

連續性需要一條其他網路也能使用的退出路徑

可行的替代方案必須延續可信的紀錄、安全聲明與運作關係。其他網路必須能驗證並使用這些紀錄。單純複製資料庫，不會讓它們接受替代者；宣告獨立，也不會修復一條被拒絕的路由。

第72篇筆記明確提出預期成果：準確的紀錄、運作的連續性，以及真正離開失能協調者的能力。實際挑戰在於建立這種能力，同時不失去讓獨立網路得以互通的共同唯一性與相容性。

這份註冊狀態匯出指南探討這項工作中攜帶紀錄的部分。它是過渡的一個組成部分，還須配合驗證、營運商採用及連續性測試。

趁服務仍正常運作時做好準備

請團隊從一個重要位址區塊的紀錄出發，一路追查到依賴它的供應商與客戶。誰能修改每筆紀錄？誰使用它？如果目前的管理者無法提供服務，或其地位受到爭議，該如何更正錯誤？

要跨組織釐清這些答案，需要時間。故障前找到答案，就有行動的餘地；停機時才摸索，代價便由客戶承擔。迫切的工作，是趁連續性仍可獲得保障時，建立實際的獨立能力。

接著閱讀第65篇筆記：運行代碼優先，了解盧恒關於協調應以運作中的網路、本地驗證及自願採用為基礎的完整論述。