假設網域的伺服器位址已經更改，但家裡開啟的是新網站，手機卻連到舊伺服器。兩部裝置即使輸入同一個名稱，若經過不同的 DNS 快取，結果也可能暫時不同。重新取得網頁的 HTTP 快取，與查出連線位址的 DNS 快取，首先就有不同的檢查對象。
本文沿著虛構的圖書館主機 www.library.example，說明名稱解析與快取的關係。範例名稱和時間表均為解說而設計，沒有測量真實服務的回應。目的是把 DNS 提供位址的過程、變更看似延遲的原因，以及名稱解析之後的失敗分開討論。
1. DNS 為每個名稱提供不同種類的答案
DNS 以不同種類的紀錄，提供與網域名稱關聯的資訊。A 表示 IPv4 位址，AAAA 表示 IPv6 位址，同一個名稱也可能有多個位址。CNAME 是指向另一個名稱的別名，MX 指示接收郵件的伺服器，NS 表示該區域的權威名稱伺服器。因此，即使查詢同一個名稱，要求的紀錄種類不同，答案也可能不同。
如 Cloudflare 的 DNS 紀錄說明所述，CNAME 的值是另一個名稱，而不是 IP 位址。若需要位址，可能還要繼續解析該名稱。另外，在 https://www.library.example/books 中，DNS 處理的主機名稱是 www.library.example。/books 這樣的路徑或網頁本文並不登錄在 DNS 中。設定 CNAME 也不會自動產生會改變瀏覽器網址列的 HTTP 重新導向。
2. 遞迴解析器如何找到權威伺服器
裝置的名稱解析功能通常會向設定好的遞迴解析器索取答案。所需資訊若已在快取中，遞迴解析器便使用它；若不足，就向其他 DNS 伺服器查詢，傳回最終答案或錯誤。DNS 術語標準 RFC 9499區分這種代為解析的角色，以及持有自己負責區域資料的權威伺服器。閱讀答案來源時，應先看伺服器是以哪種角色回應。
在沒有快取和中間轉送者的簡化流程中，解析器先從根伺服器得知頂級網域的伺服器，再從後者得知目標區域的權威伺服器，最後向權威伺服器取得所需紀錄或別名。並不是一部根伺服器保存所有網站的 IP 位址。實際上也可能從已儲存的委派資訊開始，或轉送給另一個解析器，所以不會在每次造訪時都必然重跑這整套順序。
3. TTL 是快取的剩餘時間，不是全世界的時鐘
紀錄的 TTL 是以秒傳遞的快取存活時間資訊。在一般的快取回應中，剩餘時間會隨儲存經過的時間而減少。例如，解析器在 10:00 儲存一筆 TTL 為 300 秒的位址，同一份資料在 10:02 被用來回應時，剩餘 TTL 約為 180 秒。以下時間表假設只有一個解析器，而且不重新查詢、不預先更新，也不提供過期回應。
| 虛構時間 | 權威伺服器上的位址 | 此解析器的處理 |
|---|---|---|
| 10:00 | 舊位址 | 以 TTL 300 秒儲存舊位址 |
| 10:01 | 改成新位址 | 儲存的資料仍剩 240 秒 |
| 10:03 | 新位址 | 在剩下的 120 秒內仍可重用舊位址 |
| 10:05 起的第一次查詢 | 新位址 | 假設重新查詢以取代過期資料，並取得新位址 |
其他解析器可能較晚才儲存這筆紀錄，也可能從未見過它。更新時間不一致，因此無法只靠一個 TTL，決定全球使用者同時切換的瞬間。快取也可能在到期前丟棄資料，而重新整理網頁不會連共享解析器裡的資料都刪除。TTL 是理解 DNS 回應重用的線索，不是整個網頁連線或畫面更新的時間上限。
4. 何時降低 TTL，以及「不存在」答案的快取
先前以 TTL 3,600 秒取得舊位址的快取，不會因管理者現在把 TTL 降到 60 秒，就立即收到這項變更。若位址變更已有計畫，應預先調整 TTL，並考慮仍按舊有較長期限保存的回應會留多久。較低 TTL 可能讓變更更常被確認，但也增加查詢負擔和對權威伺服器的依賴。與其對所有服務套用相同的短數字，不如連同變更計畫和故障處理一起考量。
表示名稱不存在的 NXDOMAIN，或名稱存在但沒有所要求紀錄種類的 NODATA，也可能被快取。負向快取標準 RFC 2308規定，以權威伺服器 SOA 紀錄的 TTL 和 SOA 的 MINIMUM 值兩者中較小者，作為否定回應的快取存活時間。因此，即使剛加入原本不存在的主機，先前「不存在」的答案仍可能留存。只看新 A 紀錄的 TTL，便以為那個答案的期限也相同，可能就會漏掉原因。
5. 固定相同名稱、種類與伺服器來確認
確認紀錄應一起寫下查詢的精確名稱、A 或 AAAA 等種類、查詢的 DNS 伺服器，以及時間。在已安裝 dig 的環境中，可以用 dig example.com A 指定名稱與種類。調查實際問題時，應把 example.com 換成自己要確認的主機。這個指令只是操作方式的例子，並非本文實際執行或測量回應時間的紀錄。
一起查看回應狀態，以及 ANSWER 中的名稱、種類、值和 TTL。對同一個解析器重複相同查詢，觀察 TTL 是否減少，但不能因數值增加就立即判定出錯。資料可能預先更新過，也可能是多個快取節點中的另一個節點回應。把 A 與 AAAA 的結果分開記錄而不混在一起，更容易辨識是哪一類位址出現差異。
管理者可以用相同名稱和種類，比較正在使用的遞迴解析器與管理區域權威伺服器的答案。若有差異，再依序檢查快取剩餘時間、權威伺服器之間的資料一致性和委派設定。不要把單一公開解析器的答案概括為所有使用者的狀態。企業網路的內部 DNS 或瀏覽器獨立的 DNS 設定，都可能改變查詢路徑，因此比較時也要記錄連線環境。
6. 分開閱讀 DNS 錯誤、連線錯誤與例外
NXDOMAIN 是名稱不存在的回應，NODATA 則是沒有所要求紀錄種類的情況。SERVFAIL 不同，它表示伺服器未能處理查詢；逾時則是在指定等待時間內沒有收到答案的觀察。不能把它們全部解讀成「網域被刪除了」。先保留是否有回應碼、向哪個伺服器查詢的資訊，才能決定下一個確認對象。
TTL 過後仍看到舊答案，不一定違反規則。RFC 8767 的 serve-stale 方式定義了在無法向權威伺服器更新資料的例外情況下，利用過期資訊提高可用性的方法。這不表示所有解析器都以相同設定使用它。因此，不宜只靠單一 TTL 斷言變更何時生效，而應確認實際使用解析器的行為。
最後，即使正常查得位址，也不保證能成功連上網站。通往該位址的網路、TLS 憑證、網頁伺服器與應用程式，是不同的後續階段。若 DNS 回答了預期位址，但頁面仍無法開啟，應把調查移到下一個連線階段。將名稱解析答案與網頁回應分別記錄，有助於在清除頁面快取或任意更動 DNS 設定之前，更精確地縮小失敗位置。