題幹與適用場景
團隊計畫透過 SVCB/HTTPS DNS 記錄發布 HTTPS 服務繫結資訊，例如 ALPN、連接埠、別名目標與安全參數。請說明記錄選擇、優先級、別名鏈、快取、舊客戶端相容、DNSSEC 與失敗回退。核心考察 DNS 服務繫結與漸進部署，歸為 general。
面試官考察點
- 區分通用 SVCB 與 HTTP 專用 HTTPS 記錄。
- 正確解釋
SvcPriority、TargetName與參數鍵。 - 處理別名模式、服務模式、多記錄選擇與循環。
- 識別舊 resolver、快取與 DNSSEC 驗證差異。
- 設計可觀測灰度與安全回退。
回答前需要釐清的問題
- 客戶端和 resolver 版本是否支援 HTTPS/SVCB 查詢？
- 要發布 ALPN、HTTP/3、連接埠，還是 ECH 參數？
- DNSSEC 驗證失敗時客戶端如何處理？
- TTL、權威發布流程與回滾窗口是多少？
- 舊客戶端是否必須保留 A/AAAA 與憑證路徑？
30 秒回答框架
「我先依 RFC 9460 選擇 HTTPS 或 SVCB 模式，明確優先級、目標名與參數鍵。發布前驗證 resolver 與客戶端矩陣，保留傳統 A/AAAA 與預設 HTTPS 路徑。以低 TTL 灰度，觀測查詢成功率、協議協商與連線失敗；DNSSEC 驗證失敗或參數不支援時回退。回滾要等待快取窗口。」
分步驟深入解答
第一步：選擇記錄類型
RFC 9460 定義 SVCB 與 HTTPS。HTTPS 面向 HTTP origin，SVCB 可表達通用服務繫結。先確認場景與支援矩陣，不把 HTTPS 記錄當任意應用設定中心。
第二步：解釋優先級與模式
SvcPriority 表達服務選擇優先級；別名模式導向另一個目標名，服務模式在目前 owner name 提供連線參數。多筆記錄要驗證選擇、非法參數與循環。
第三步：保留相容路徑
舊 resolver 或客戶端可能忽略新記錄，只查詢 A/AAAA。保留傳統記錄、憑證與預設連接埠，避免用刪除舊路徑強迫升級。
第四步：處理快取與回滾
TTL、負快取和預取會延遲變更。灰度可縮短 TTL，但回滾仍按最長快取窗口規劃，並記錄 serial、批次與生效時間。
第五步：考慮 DNSSEC 與隱私參數
DNSSEC 驗證錯誤可能讓解析失敗。ECH 等功能只是引導資訊，不能宣稱單獨隱藏所有流量元資料；密鑰輪換與過期要有失效策略。
第六步：設計灰度和觀測
按區域、網域或 resolver 類型分批。記錄查詢占比、參數解析、HTTP/3 協商、連線失敗、回退比例、快取命中和 DNSSEC 錯誤。
第七步：驗證回滾
測試非法參數、別名循環、不可達目標、過期簽章與錯誤連接埠，確認回退或明確失敗。生產回滾要等待 TTL 窗口，再比較錯誤預算。
高品質示範回答
「我會依 RFC 9460 區分 HTTPS 與通用 SVCB，明確別名或服務模式，並核對優先級、目標名與參數鍵。建立 resolver、瀏覽器、SDK 和 DNSSEC 矩陣，保留 A/AAAA、憑證與預設 HTTPS。灰度時降低 TTL，觀察查詢、HTTP/3、連線失敗與回退比例。測試舊客戶端、未知參數、循環、DNSSEC 失敗和錯誤連接埠，回滾按最長快取窗口執行。」
常見錯誤
- 把 DNS 當即時控制面 → 快取造成延遲 → 按最長 TTL 設計。
- 刪除 A/AAAA → 舊客戶端中斷 → 保留傳統路徑。
- 忽略優先級和循環 → 選擇錯誤 → 做規範驗證。
- 只測新瀏覽器 → 漏掉真實回退 → 建立矩陣。
- 把 ECH 當完整隱私 → 忽略側信道 → 說清楚邊界。
追問及應對
追問一：SVCB 與 HTTPS 怎麼選？
HTTPS 針對 HTTP origin，SVCB 更通用；依協議和客戶端支援選擇。
追問二：舊客戶端看不到記錄怎麼辦？
保留 A/AAAA、憑證與預設路徑，讓舊客戶端照原流程連線。
追問三：刪除記錄能立即回滾嗎？
不能，遞迴快取和負快取會延遲收斂，須等待窗口並觀測。
追問四：如何證明可用性沒有下降？
比較前後連線成功率、解析延遲、協商結果、回退比例與各客戶端錯誤率。