多 DNS 供應商架構：構建抗 DDoS 攻擊的域名解析防線

背景：IoT 僵屍網絡引爆超大規模 DDoS 攻擊

2016 年 10 月，針對 DNS 服務商 Dyn 的三波 Mirai 僵屍網絡攻擊，導致 Amazon、PayPal、Reddit、GitHub 等巨頭服務大面積不可用。攻擊利用受感染 IoT 設備發起海量 DNS 查詢請求，癱瘓權威服務器。Dyn 技術副總裁 Phil Stanhope 披露，攻擊還包含利用 Linux 內核 3.x 版本 SYN cookie 全局鎖缺陷的 TCP SYN 洪水攻擊，導致多核服務器退化為單核性能。Linux 4.x 通過每 CPU 核心局部鎖修復該問題。

DNS 解析鏈路與攻擊面分析

一次完整 DNS 查詢經過：根服務器 → 頂級域 (TLD) 服務器 → 權威服務器。中間解析器會根據 TTL 緩存結果。權威服務器被 DDoS 癱瘓，將導致整個域名無法解析，業務直接中斷。

單一供應商的脆弱性

商業 DNS 供應商雖提供多節點冗余（如 dig/drill 可見多條 NS 記錄），但同一供應商節點共享底層基礎設施，遭遇大規模攻擊時全軍覆沒風險極高。

核心策略：多 DNS 供應商部署

實施要點

1. 雙邊 NS 記錄：在註冊商處同時配置供應商 A 和供應商 B 的 NS 記錄，所有記錄作為響應返回。
2. NS 順序打亂：確保響應中兩家供應商 NS 交替排列，避免解析器連續重試同一供應商失效節點。
3. 數據同步：使用 API 或區域傳送 (AXFR/IXFR) 保持雙邊區域數據一致。

輔助防禦手段

流量清洗

引入第三方清洗服務（Akamai、Arbor Networks、Verizon 等），在流量進入權威服務器前過濾惡意請求，僅放行合法流量。

Anycast 路由

多地部署同 IP 地址的權威服務器，BGP 路由自動將查詢導向最近節點。節點失效時，路由層面自動切換至健康節點，無需修改 DNS 記錄。

TTL 策略優化

• 平時設置較長 TTL（如 1 小時）減少權威服務器壓力，利用緩存提速
• 攻擊預警或切換供應商前，降低 TTL（如 60 秒）加速生效
• 避免 TTL 過短導致緩存失效放大查詢量

組織協作：NetOps + DevOps + SecOps + SRE

Stanhope 強調：未來抗 DDoS 需跨職能協作。網絡團隊負責 Anycast/BGP，開發團隊實現 DNS API 自動化切換，安全團隊監測威脅情報，SRE 保障 SLA 與演練機制。

總結：分層防禦體系

DNS 是互聯網的「電話簿」，其可用性直接決定業務生死。多供應商架構不是可選項，而是生產級系統的必修課。