題幹與適用場景
為多租戶 SaaS 設計權威 DNS 控制面。使用者提交 A、AAAA、CNAME、TXT 等記錄，系統要校驗衝突、生成 zone 版本，通知權威節點並支援 AXFR/IXFR、DNSSEC、灰度、回滾與稽核。
面試官考察點
- 能否區分控制面、權威資料面和遞迴解析器。
- 是否以不可變 zone 版本和原子發布保證一致性。
- 是否理解 SOA serial、NOTIFY、AXFR/IXFR 的關係。
- 是否設計租戶隔離、權限、DNSSEC 金鑰與錯誤發布防護。
- 是否能處理節點落後、部分發布、負快取和回滾。
回答前需要釐清的問題
確認 zone 數量、寫入速率、傳播 SLO、DNSSEC、節點地域、授權模型、審批要求及舊節點是否只支援 AXFR。若未指定，假設全球多活權威叢集和分鐘級可見性。
30 秒回答框架
控制面寫入規範化記錄庫，按 zone 生成不可變版本並靜態校驗，再由發布器原子替換權威節點。SOA serial 遞增，NOTIFY 觸發 IXFR，無法增量時回退 AXFR。每次發布有狀態、稽核與回滾指標；DNSSEC、租戶權限和傳播監控是門禁。
分步驟深入解答
1. 劃分控制面和資料面
控制面保存租戶、zone、記錄和版本；權威資料面只回答已發布版本。遞迴解析器不在寫入鏈路內，TTL 會造成可見性延遲。版本包含 canonical zone、SOA serial、checksum、簽名狀態和發布目標。
2. 設計寫入與校驗
交易寫入候選版本，校驗名稱、TTL、類型、CNAME 衝突、委派邊界和租戶配額。批量變更使用冪等 request id 與 optimistic version，防止編輯器互相覆蓋；失敗不產生可發布版本。
3. 原子生成與發布
發布器生成 zone 結構並執行語法、委派、循環和 DNSSEC 校驗，通過後寫入內容定址物件並計算 checksum。節點以版本指標原子切換，避免新舊資料混合。
4. 傳播協定與落後節點
主節點遞增 serial 並發送 NOTIFY；從節點優先 IXFR，無增量鏈或校驗失敗時請求 AXFR。節點回報 serial、checksum 和簽名狀態。落後節點按可用性策略摘除或服務舊版本，不能靜默返回空 zone。
5. TTL、負快取與回滾
TTL 控制遞迴快取，NXDOMAIN 也會負快取。先讓新目標可用再調整 TTL；刪除記錄不能立即清除外部快取。回滾切換到已驗證舊版本並遞增 serial，不能重用舊 serial。
6. 安全與租戶隔離
使用細粒度 RBAC、zone 授權、審批和雙人保護；內部 API 要驗證與防重放。DNSSEC 金鑰放在 KMS/HSM，簽名失敗阻斷發布。稽核保存操作者、請求、版本、serial 和結果，不保存租戶秘密。
7. 觀測與故障演練
監控發布延遲、serial 差異、IXFR/AXFR 比例、簽名錯誤、SERVFAIL、NXDOMAIN、查詢成功率和地域分布。演練主節點故障、網路分區、增量鏈缺失、錯誤 zone、金鑰輪換和回滾。
高品質示範回答
我會讓控制面保存租戶隔離的不可變 zone 版本，權威節點只服務一個已驗證版本。寫入校驗名稱、TTL、CNAME 衝突、委派和配額，批量請求帶冪等 id 與樂觀版本。發布器產生 canonical zone，通過語法、DNSSEC 和 checksum 後原子切換。
主節點遞增 serial 並 NOTIFY，從節點優先 IXFR，失敗時 AXFR。節點回報 serial、checksum 和簽名狀態；TTL 與負快取決定外部可見性，回滾用新 serial。RBAC、審批、KMS/HSM、稽核、SERVFAIL 與 serial 監控，以及分區和金鑰演練構成門禁。
常見錯誤
- 把遞迴快取延遲當作控制面失敗。
- 直接編輯共享 zone 檔案造成半寫入。
- 認為 NOTIFY 等於已完成傳播。
- IXFR 失敗時返回空 zone。
- 回滾重用舊 serial。
- 讓租戶操作 DNSSEC 私鑰。
- 缺少 NXDOMAIN 和 SERVFAIL 監控。
追問及應對
追問一：為什麼必須遞增 SOA serial？
節點與快取用 serial 判斷版本新舊；回滾也要用更高 serial，避免被視為舊版本。
追問二：IXFR 找不到增量怎麼辦？
請求 AXFR；失敗時保留已驗證版本並告警，不服務空 zone。
追問三：節點落後很多版本怎麼辦？
比較 serial 與 checksum，摘除流量或服務舊版本，再用 AXFR 追平並抽樣驗證。
追問四：DNSSEC 簽名失敗能否先發布明文？
若 zone 契約要求簽名，就阻斷發布並修復金鑰或簽名鏈，不能靜默降級。