改了 DNS 記錄，為什麼還有人看到舊網站？看懂 TTL 與快取 / Why Your DNS Change Is Not Live Yet: TTL and Caching
現象：改是改了，答案還是舊的 / The record changed, yet old answers persist
假設你把網站搬到新主機，在 DNS 管理介面把 A 記錄改成新 IP，自己測試也正常；幾分鐘後同事回報，看到的還是舊網站。先別急著把記錄改第二次：可能不是改失敗，而是查詢本身沒有走到你修改的那台伺服器。
Suppose you move a site to a new host and update its DNS A record in the management console; your own test works, yet minutes later a colleague reports the old site is still being served. Do not rush to edit the record a second time: the change may not have failed — the query itself may never have reached the server you edited.
在終端機輸入網址，多數情況不是直接去問「管這個網域的伺服器」，而是交給遞迴解析器代問，例如寬頻業者的解析器或公共 DNS。依 RFC 1034，DNS 定義了快取所取得資料的程序；解析器替很多使用者共用同一份答案，你問到的可能是幾分鐘前別人問過的副本，而不是最新狀態。[1]
When you type a hostname, you are usually not addressing the servers that manage the zone directly. A recursive resolver asks on your behalf — the resolver of your broadband provider or a public DNS, for example. RFC 1034 defines procedures for caching retrieved data, so a resolver serves the same copy of an answer to many users: what you receive may be a copy fetched minutes ago for somebody else, not the latest state. [1]
快取的餘命由 TTL 決定 / TTL governs a cache copy’s life
每筆資源記錄都帶有一個 TTL，也就是可以快取的秒數。RFC 1035 解釋：TTL 指明這筆記錄「可以被快取多久，之後應再向來源查證」。因此在 TTL 歸零之前，解析器可以直接用快取回覆你；這不是故障，而是規格明文允許的行為。[2]
Every resource record carries a TTL, the number of seconds it may be cached. RFC 1035 explains that the TTL specifies “a time interval that the resource record may be cached before the source of the information should again be consulted”. Until that interval runs out, a resolver may answer directly from its cache; that is behavior the specification explicitly allows, not a malfunction. [2]
RFC 1034 同時說明，TTL 由資料所在區域的管理者設定；同一份記錄的舊快取會在不同節點各自到期，「全世界都換成新值」是一段分布的時間，不是單一開關。文件並建議：如果可以預期變更，先調低 TTL 再改記錄，能減少過渡期的不一致；已經送出去的快取，不會因為你當下調小而提前消失。[1]
RFC 1034 also notes that the TTL is assigned by the administrator of the zone that owns the data. Old cached copies expire at different times in different places, so “the whole internet uses the new value” is a spreading interval rather than a single switch. The same RFC recommends that when a change can be anticipated, the TTL be reduced in advance to minimize inconsistency during the change; a copy already handed out does not vanish just because you lower the TTL now. [1]
還有個容易忽略的角落：查「不存在」也會被快取。依 RFC 2308，解析器對 NXDOMAIN 這類負面回應同樣可能快取一段時間；所以剛建好的新網域馬上查，看到「查不到」，也可能是上一輪查詢留下的負面快取，而不是記錄真的還沒出現。[3]
There is a corner that is easy to overlook: “not found” is cached too. RFC 2308 states that resolvers may also cache negative answers such as NXDOMAIN for a period of time. If a newly created domain is queried immediately and appears missing, what you see can be negative cache from an earlier query rather than a record that has not appeared yet. [3]
唯讀對照：分清楚該等還是該改 / Read-only checks: wait or edit?
排查用唯讀查詢就夠。在 Linux 或 macOS 上，先用管理台或 whois 找出網域的名稱伺服器，再直接查權威端：dig @ns1.example.com example.com A，看回的是不是新值；接著不加 @ 普通 dig example.com，看答案裡的 TTL 是否在逐秒遞減——若是快取回覆，數字通常會小於設定值。Windows 沒有 dig 時，nslookup example.com ns1.example.com 可做同樣對照。這些指令只查詢不寫入；本文未對特定網域執行查詢，各解析器的回覆細節也可能不同。
Read-only queries are enough for diagnosis. On Linux or macOS, find the zone's name servers from your console or whois, then query the authoritative side directly: dig @ns1.example.com example.com A tells you whether it already answers with the new value. Then run a plain dig example.com without the @ part and watch the TTL in the answer tick down second by second — a cached reply typically carries a smaller number than the configured one. On Windows without dig, nslookup example.com ns1.example.com gives a comparable view. These commands only query; this article ran nothing against a specific domain, and resolver reply details can differ.
# Linux/macOS；Windows 可用 nslookup 取代 / on Windows, nslookup is the fallback
dig @ns1.example.com example.com A # 直接問權威端 / ask the authoritative side
dig example.com # 看快取回覆的 TTL 是否倒數 / watch the cached TTL tick down
nslookup example.com ns1.example.com # Windows 平台對照 / Windows-side comparison回到那通「還是舊網站」的回報：現在可以分清楚，是權威端還沒改對，要再修正記錄；還是某個節點的快取還沒到期，只需等 TTL 過去。下次計劃搬家，趕在變更前先把 TTL 調小，再改記錄，換軌的時間就會平滑得多。
Back to the report “the old site is still up”: you can now tell apart “the authoritative side still has the wrong record”, which needs a fix, from “a cache somewhere has not expired yet”, which only needs time. Next time you plan a move, lower the TTL in advance, then change the record — the switchover becomes much smoother.
留言
張貼留言