代理 DNS TTL 與故障轉移驗證：避免陳舊閘道造成中斷
代理閘道本身可能完全正常，用戶端卻仍連到已退役的位址。常見原因不是權威記錄，而是壽命更長的下游快取、負回應、解析失敗快取，或仍被重用的連線池。本指南把這些隱藏狀態轉化為可驗收的切換門檻。
權威 TTL 只是起點
正向回應會快取位址；不存在的名稱也有負快取；暫時解析失敗可能被快取；遞迴解析器在上游故障時還可能傳回陳舊但曾有效的回應。即使 DNS 已更新，應用程式仍可能長期重用既有通訊端。
RFC 2308 規範負快取，RFC 8767 描述陳舊 DNS 資料服務，RFC 9520 明確解析失敗快取要求。可靠遷移必須驗證這四類行為，不能只看控制台中的 TTL。
繪製完整解析路徑
- 作業系統與語言執行環境快取；
- 本機存根解析器與遞迴解析器；
- 瀏覽器、JVM、容器和服務網格；
- 本機解析與代理端解析；
- 分開的 A 與 AAAA 記錄；
- HTTP keep-alive、HTTP/2、QUIC 與連線池；
- 主代理及備援代理閘道名稱；
- 受限目標必須使用的 fail-closed 控制。
安全重疊視窗應依據最長的實測壽命，而不是最短的設定 TTL。
建立安全測試區
使用自有測試網域和兩個無害端點。端點 A 代表舊閘道，端點 B 代表新閘道；各自傳回不含敏感資訊的唯一標記。不要透過中斷正式網域或存取未授權系統來測試。
八步驗證流程
1. 建立乾淨基線
只清除具文件依據的測試快取，啟動新用戶端程序並連續請求。記錄解析器、位址家族、命中端點、查詢耗時、連線是否重用和時間戳記。
2. 測量正向快取到期
先讓記錄指向 A，穩定後改為 B。按固定間隔從各代表性執行環境和地區探測。驗收標準是所有新連線都在核准視窗內轉向 B。
3. 測試負快取
查詢刻意不存在的測試名稱，隨後建立它，測量各用戶端持續傳回不存在的時間。本機解析與代理端解析模式都要涵蓋。
4. 測試解析失敗快取
在隔離的測試解析器中模擬暫時上游故障，恢復後測量用戶端復原時間。重試必須有上限，且不能放大解析器負載。
5. 識別陳舊回應
在已有有效快取時暫時隔離權威測試來源，確認遞迴解析器是否傳回陳舊資料、持續多久，以及會對遷移造成什麼影響。它能提高可用性，也會延長舊閘道的安全保留期。
6. 分別驗證 A 與 AAAA
分別修改 IPv4 和 IPv6 記錄。確認兩個位址家族都能收斂並接受健康檢查，避免單一故障位址家族默默吸收大量流量。
7. 排空連線池
使用長壽命 HTTP/2、QUIC 和 keep-alive 連線重複切換。DNS 收斂不會遷移已建立的連線，因此必須定義最大連線壽命和受控排空流程。
8. 證明 fail-closed
對必須經過授權代理的工作負載，在測試環境移除所有允許端點。用戶端應明確停止並回報錯誤，不能退回直連或未核准閘道。
更安全的遷移時間線
至少在計畫切換前一個原 TTL 週期降低 TTL。重疊期間同時保留新舊閘道。修改記錄後觀察新連線收斂並排空舊連線；只有最長實測快取與連線壽命都結束後，才能退役舊閘道。
驗收門檻
- 所有目標地區的新連線均在視窗內收斂；
- 負快取與暫時失敗快取按限制恢復；
- 陳舊回應行為已測量並計入重疊期；
- IPv4 與 IPv6 都通過可用性和身分檢查；
- 解析故障期間重試量受控；
- 舊連線排空且無請求遺失；
- 沒有授權代理時，受限工作負載維持 fail-closed。
切換前檢查清單
- [ ] 解析路徑與快取責任方已記錄
- [ ] 遷移時間線保留原 TTL 週期
- [ ] 正向、負向、失敗與陳舊快取測試通過
- [ ] IPv4 與 IPv6 已分別測試
- [ ] 最大連線壽命與排空策略已驗證
- [ ] 回復記錄與閘道容量已就緒
- [ ] 告警可區分 DNS、連線、TLS 與應用程式錯誤
常見問題
切換前五分鐘降低 TTL 是否足夠？
只有舊 TTL 和所有下游快取都已到期才可能足夠，否則用戶端仍可依原壽命保留舊回應。
DNS 查詢成功是否證明代理故障轉移有效？
不能。連線池可能仍連著舊閘道，代理端解析結果也可能與本機解析不同。
是否應停用陳舊 DNS 回應？
不應一概停用。它能在解析器故障時維持可用性，但必須測量持續時間並計入閘道退役計畫。
相關 98IP 指南
合規說明
僅測試你擁有或已獲授權的網域、解析器、代理閘道和端點。限制請求頻率、保留稽核記錄，並遵守目標服務條款與適用的資料保護規則。
來源說明：網際網路工程任務組，RFC 2308，1998 年 3 月；RFC 8767，2020 年 3 月；RFC 9520，2023 年 12 月。
