題幹與適用場景
這道通用技術題考察網路基礎與排障方法。重點是區分「權威紀錄已改變」與「遞迴解析器或用戶端仍快取舊答案」，不要把 DNS 當成即時全網廣播。
面試官考察什麼
- 能否說清 stub resolver、遞迴解析器與權威伺服器的職責。
- 能否正確解釋 TTL、負快取與不同紀錄類型的獨立快取。
- 能否用多地點、多解析器查詢定位快取層或委派問題。
- 能否設計可回滾的 DNS 切換計畫，而非只執行清快取。
回答前需要釐清的問題
先確認修改的是 A、AAAA、CNAME 還是 NS 委派；新舊位址是否都健康；問題是所有使用者還是特定電信商、地區或網路；變更前 TTL、SOA 負快取參數與 DNSSEC 狀態為何；應用是否還固定解析結果或使用連線池。
30 秒回答架構
我會先直接查詢權威伺服器確認新紀錄，再從多個公共遞迴解析器與受影響網路查詢並比較 TTL。若權威已更新，舊答案通常來自快取或較長的上游 TTL；若權威沒更新，則檢查委派、區域發布與自動化。切換前降低 TTL 並提前等待舊 TTL 到期，切換時保留雙活，驗證後再下線舊位址。
分步驟深入解答
1. 畫出實際查詢鏈路
應用通常先經過瀏覽器或系統 stub resolver，再詢問遞迴解析器；快取未過期時直接回覆，否則沿根、頂級網域與權威伺服器查詢。權威伺服器保存區域的事實紀錄，每層都可能有自己的快取與刷新時間。
2. 用 TTL 與負快取解釋時間
TTL 越長，快取命中越多、查詢壓力越低，但變更生效更慢。已快取的舊答案通常要等 TTL 歸零；負面回應也可能依 SOA 參數快取，導致剛建立的紀錄仍回覆不存在。不同紀錄類型與解析器的剩餘 TTL 要分別觀察。
3. 設計可重複的排查命令
先向權威伺服器查詢，確認區域與委派一致；再從多個遞迴解析器、地區與網路查詢相同名稱、類型與 flags，記錄答案、TTL、回應碼與時間。對比「權威正確、遞迴舊」「權威不一致」「只有用戶端舊」三種模式。
4. 排除 DNS 以外的舊位址
HTTP 代理、CDN、應用設定、連線池、服務發現或 hosts 檔案也可能繼續使用舊位址。檢查實際命中的 IP、TLS 憑證、回應標頭與負載平衡日誌，確認問題確實發生在解析階段。
5. 規劃安全切換
切換前把 TTL 降到業務允許的較低值，並提前等待原 TTL 視窗結束；新舊端點同時可用。切換後按地區與解析器監控答案分布、錯誤率與真實流量，保留舊端點直到風險視窗結束。若出現問題，應用層降級或雙活可先止損。
高品質示範回答
我會先確認權威伺服器的紀錄與委派是否一致，再從多個遞迴解析器和受影響網路查詢同一名稱，記錄答案與剩餘 TTL。權威已更新而遞迴仍回覆舊位址，代表快取尚未過期；權威不一致則檢查區域發布、NS 或自動化；只有少數裝置異常時再查系統快取、hosts、代理與連線池。TTL 決定舊答案還能使用多久，負快取也會影響新建紀錄，因此我不會承諾固定傳播時間。正式切換前降低 TTL 並等待視窗，維持新舊端點雙活，切換後觀察真實流量與錯誤率。
常見錯誤
- 說 DNS 傳播「幾分鐘一定完成」，忽略既有 TTL。
- 只清自己的電腦快取，不能代表遞迴解析器狀態。
- 只查一個公共 DNS，無法發現地區或委派差異。
- 修改 A 紀錄卻忘記 AAAA、CNAME、NS 或 DNSSEC。
- 權威更新就立刻關閉舊服務，沒有雙活與回滾視窗。
追問及應對
為什麼新建紀錄仍回覆 NXDOMAIN？
上游可能快取了負回應，依 SOA 負快取參數保留。先確認權威紀錄存在，再等待負快取到期。
TTL 已調低，為什麼舊答案仍在？
降低 TTL 只影響之後取得的快取，既有快取仍按舊 TTL 倒數。也要確認改到正確的紀錄、區域與權威伺服器。
能否強制所有使用者刷新 DNS？
無法控制所有遞迴解析器和用戶端。應用提前降 TTL、雙活、應用層路由與監控降低風險。
如何判斷是 IPv6 導致舊服務？
分別查詢與測試 A、AAAA，記錄用戶端實際連線的位址族。若 AAAA 仍指向舊端點，單獨修正它。