題幹與適用場景
公司希望降低 SMTP STARTTLS 降級和中間人風險，計畫為發信網域發布 DNSSEC 與 TLSA 記錄。現有收件方並非全部支援 DANE，憑證還需要定期輪換。請設計 MX 發現、TLSA 驗證、相容降級、輪換、監控和事故回滾。
面試官考察點
- 是否理解 SMTP DANE 依賴 DNSSEC、MX 目標和 TLSA 記錄，而非只看憑證授權機構。
- 能否區分 opportunistic DANE、強制 TLSA、MTA-STS 與 TLS 報告的職責。
- 能否設計 TLSA 記錄生成、TTL、憑證輪換和 DNSSEC 失敗處理。
- 是否能把投遞成功率、降級、驗證失敗和收件網域相容性納入灰度。
回答前需要釐清的問題
- 目標是保護發信網域、收信網域，還是兩者？發信 MTA 是否驗證對端？
- DNSSEC 簽名鏈、DNS 解析器和快取是否可靠？
- 目前收件網域支援 DANE、MTA-STS 或僅支援 STARTTLS 的比例如何？
- 憑證由 CA 簽發還是自簽，輪換窗口和回滾窗口多長？
- 失敗時允許延遲投遞，還是必須明文降級？
30 秒回答框架
發信 MTA 先按 MX 找到目標主機，再透過 DNSSEC 驗證 TLSA 記錄，按 selector、matching type 和 association data 檢查 TLS 憑證或公鑰。DNSSEC 驗證失敗或 TLSA 不匹配時不能當作普通 STARTTLS 成功；依策略延遲或拒絕投遞。上線先監控模式，再灰度網域，配合 MTA-STS 和 TLS 報告觀察失敗，輪換採用重疊記錄與可回滾窗口。
分步驟深入解答
第一步：釐清協定鏈路
SMTP 發信方從收件網域的 MX 記錄得到傳輸主機，連線後協商 STARTTLS。DANE 使用 DNSSEC 保護的 TLSA 記錄把網域、連接埠和目標憑證或公鑰關聯起來。它不是把 MX 名稱直接當成憑證主機名，也不能繞過 TLS 握手和主機名規則。
第二步：選擇 TLSA 記錄語意
TLSA 的 certificate usage、selector 和 matching type 共同決定匹配對象。記錄可以匹配完整憑證、SubjectPublicKeyInfo 或其摘要；選擇越寬鬆，輪換和相容越容易，約束越強則控制力更高。記錄必須準確表達實際部署鏈，不能只複製目前憑證指紋而不考慮備用金鑰。
第三步：設計 DNSSEC 與 TTL
確認 DNSSEC 從父區到 TLSA 的驗證鏈，監控簽名過期、DS 變更和解析錯誤。TTL 影響輪換傳播與撤銷速度，應為雙記錄重疊預留時間。DNSSEC 驗證失敗、SERVFAIL 和 NXDOMAIN 要與「沒有 TLSA」區分，避免快取或解析器故障觸發錯誤降級。
第四步：做相容策略
對支援 DANE 的目標執行 TLSA 驗證；不支援的目標可按網域策略使用 MTA-STS、普通 STARTTLS 或排隊等待。強制策略不應悄悄回退明文。將失敗原因、目標網域、DNSSEC 狀態和重試時間寫入投遞佇列與 TLS 報告，避免只顯示「連線失敗」。
第五步：執行憑證與金鑰輪換
先發布新舊 TLSA 記錄，再部署新憑證或公鑰，等待 TTL 和觀察窗口後移除舊記錄。每一步都要驗證從多個解析器和 MTA 看到的結果。若使用摘要匹配，記錄生成工具、演算法和輸入；輪換失敗時恢復舊記錄和舊憑證，不能只恢復應用設定。
第六步：灰度與可觀測性
先選內部或低風險收件網域進入監控模式，再逐步啟用強制驗證。監控投遞成功率、TLSA 命中、DNSSEC 失敗、憑證不匹配、佇列年齡和明文降級次數。TLS 報告按網域聚合並脫敏，不能把收件人地址和完整郵件元資料暴露給第三方。
第七步：事故處理與驗證
演練 DNSSEC 簽名過期、TLSA 誤發布、憑證提前輪換、MX 變更、解析器故障和對端不支援。故障時凍結強制發布、延長佇列重試並回滾 DNS 或憑證；驗證恢復後再解除凍結。用獨立 MTA 和多個公共解析器確認鏈路，不能只在單機測試。
高品質示範回答
我會把 MX、DNSSEC、TLSA 和 SMTP TLS 分成可觀測步驟：發信 MTA 解析 MX，驗證 DNSSEC，再按 TLSA 的 usage、selector 和 matching type 檢查對端憑證或公鑰。DNSSEC 失敗或 TLSA 不匹配時依網域策略拒絕或延遲，不靜默降級明文。上線先監控、再灰度強制，結合 MTA-STS 和 TLS 報告統計相容性。輪換先發布新舊重疊記錄，再部署新憑證，等待 TTL 後刪除舊記錄；保留 DNS 與憑證回滾路徑，並演練簽名過期、MX 變更和解析器故障。
常見錯誤
- 把 DANE 當成只檢查 CA 憑證或只檢查 MX 主機名。
- DNSSEC 驗證失敗時直接按普通 STARTTLS 或明文繼續。
- 輪換時先刪舊 TLSA，再部署新憑證，造成大量投遞失敗。
- 只在單個遞迴解析器和發信機上驗證，沒有考慮快取傳播。
- TLS 報告包含收件人地址和完整郵件元資料，造成新的隱私風險。
追問及應對
追問一：DANE 和 MTA-STS 如何選擇？
DANE 依賴 DNSSEC 與 TLSA，適合能驗證 DNSSEC 的 MTA；MTA-STS 透過 HTTPS 發布策略並依賴 CA 憑證。兩者可並存，按對端能力和營運邊界選擇，不能把一個當成另一個的降級替代。
追問二：TLSA 匹配公鑰還是憑證？
由 selector 和 matching type 決定。選擇公鑰或摘要可減少憑證鏈變化影響，但必須保留正確的輸入、演算法和輪換記錄，避免產生錯誤摘要。
追問三：DNSSEC SERVFAIL 時能明文投遞嗎？
若網域策略要求 DANE，不能把驗證失敗當作無策略；應延遲或拒絕並告警。只有明確允許的相容策略才可走替代路徑，並記錄降級。
追問四：如何回滾一次錯誤的 TLSA 發布？
恢復舊 TLSA 與舊憑證，確認權威 DNS、快取 TTL 和多個遞迴解析器都收斂，再解除佇列凍結。保留錯誤記錄、影響網域和恢復時間，作為稽核與復盤依據。
追問五：如何證明沒有明文降級？
按目標網域記錄 TLS 協商結果、TLSA 狀態和降級計數，定期從獨立 MTA 驗證；將明文嘗試視為高優先級告警，並與 TLS 報告和投遞日誌交叉核對。