面試題：如何安全遷移 HTTPS/SVCB DNS 記錄並驗證用戶端相容性？
題目
為同時提供 HTTP/2、HTTP/3 的網域設計 HTTPS（SVCB）記錄遷移方案，要求支援灰度、回滾，並能定位解析器、用戶端與憑證設定不一致造成的故障。
場景與限制
權威 DNS 由多家供應商託管，舊用戶端仍只查詢 A/AAAA。新記錄不能影響不支援此類型用戶端的可用性；DNS TTL 為 300 秒，發布期間不可停機。
核心考點
考察是否理解 RFC 9460 的 AliasMode、ServiceMode、SvcPriority 與參數繼承，並能把 DNS 快取傳播、TLS 憑證、HTTP/3 協商和回滾組成可觀測發布流程。
參考解法
先保留既有 A/AAAA 與 TLS 設定，確認權威伺服器可回覆類型 65。需要頂點別名時使用 AliasMode（優先級 0 且目標名稱非根）；需要宣告 ALPN、連接埠或備援端點時使用 ServiceMode。先在低流量子網域發布 alpn=h2,h3，觀察解析成功率、握手錯誤與協定分布，再擴大到主網域。
忽略 HTTPS 記錄的用戶端仍應依 A/AAAA 連線。回滾時撤回新記錄並等待舊 TTL 加上遞迴解析器保留時間，不能假設刪除權威記錄後快取立即消失。
關鍵細節
SvcPriority=0 代表 AliasMode；ServiceMode 應使用非零優先級。目標主機必須有相符憑證，port、alpn 等鍵要與監聽器及防火牆一致。變更前後都從多個遞迴解析器查詢，並以支援及不支援類型 65 的用戶端對照。
常見誤區
把 HTTPS 記錄當成 CNAME 而刪除 A/AAAA；只驗證本地快取；把 h3 宣告當成伺服器已能完成 QUIC；忽略憑證 SAN 與 AliasMode 目標名稱；用單一地區成功率代表全球傳播。
評估標準
優秀答案能畫出權威 DNS、遞迴解析器、用戶端和 TLS 終點的資料流，明確灰度指標、回滾時間窗與相容性矩陣，並指出優先級及參數錯誤各自的現象。一般答案只給一條記錄，無法解釋舊用戶端與快取行為。
追問
如何驗證 AliasMode 目標名稱與憑證關係？
查詢別名目標的 A/AAAA 與 HTTPS 記錄，確認用戶端最終連線的主機名稱符合憑證名稱限制，並在 TLS 日誌核對 SNI。
若只有部分地區出現 HTTP/3 失敗，先查什麼？
按遞迴解析器、Anycast DNS 節點和電信商拆分採樣，比較 HTTPS 記錄、UDP 443 可達性、QUIC 版本與憑證鏈，而非立即全面回滾。
何時不應發布 alpn=h3？
當 QUIC 監聽、憑證、路徑 MTU 或防火牆尚未在目標網路驗證時，先只宣告穩定協定，端到端指標達標後再加入 h3。