DNS is an indispensable basic service on the internet, and the loading speed, resolution accuracy, and even CDN scheduling effects that users experience when accessing websites are closely related to DNS caching mechanisms. Many website owners encounter problems where changes to DNS resolution don't take effect across the entire network for a long time, or users still access the old IP address. This is precisely where DNS cache refresh and TTL settings come into play. Understanding the generation and propagation path of caching, as well as the rules of TTL, is crucial for controllable, stable, and low-latency website deployment, server address adjustments, or migrations.

　　The DNS resolution process seems simple—enter a domain name, resolve to an IP address—but the actual behind-the-scenes process involves root name servers, top-level domain servers, authoritative DNS servers, local recursive DNS servers, and browser and system-level caches. The cache exists at multiple nodes, and any failure to update at any level will lead to asynchronous resolution results. Therefore, refreshing the cache is not a single action but requires understanding the entire chain.

　　When a user accesses a domain name, the browser first checks its cache. If the cache hasn't expired, it returns directly without requesting an external DNS server. Secondly, there's the operating system's local caching, such as the DNS Client Service in Windows, or nscd or systemd-resolved in Linux. A request is only sent to the recursive DNS server if the current cache has expired or doesn't exist. The recursive server then searches the authoritative DNS level by level, storing the results in the cache according to the Time-To-Live (TTL). This ensures faster speeds for subsequent user accesses. The core design of this entire process is to reduce redundant queries, improve resolution efficiency, and reduce the query pressure on the authoritative DNS.

　　While caching means faster resolution, it also introduces synchronization latency. When a website changes servers or modifies DNS records, the cache at each level may still retain the old IP address, causing access problems for some users. Therefore, refreshing the DNS cache effectively allows different levels to discard old caches as quickly as possible and re-request the authoritative server.

　　TTL is a key parameter for the validity period of the DNS cache. Each record has its own TTL value, measured in seconds. A longer TTL (Time To Live) means longer cache validity but slower DNS updates; a shorter TTL means more timely updates but increases the number of recursive server requests, slightly increasing latency. Therefore, TTL settings need to balance stability and flexibility. Common default TTL values ​​are 3600 seconds (1 hour), 14400 seconds (4 hours), and 86400 seconds (1 day). If a website doesn't frequently change DNS settings, a longer TTL can reduce DNS load and improve access efficiency. However, when planning a website migration or CDN switch, it's recommended to reduce the TTL to 300 seconds or even 60 seconds several hours in advance to ensure real-time DNS updates for users during the switch.

　　TTL is not an immediately effective parameter; it only affects the new cache lifecycle after modification and does not immediately invalidate the old cache. Therefore, many people mistakenly believe that adjusting the TTL will "instantly refresh all DNS records," which is incorrect. For truly fast updates, the TTL needs to be lowered in advance, and the old cache should be allowed to expire naturally before making changes; otherwise, the propagation delay will still exist. When DNS resolution is not updated, cache refresh can be performed at multiple levels. Browser cache can be refreshed by clearing browsing history, using incognito mode, or using keyboard shortcuts. Operating system-level DNS cache can be cleared via commands, such as `ipconfig /flushdns` on Windows, `sudo dscacheutil -flushcache` or `sudo killall -HUP mDNSResponder` on macOS, and `systemd-resolve` or a restart of `nscd` depending on the service. Network operator DNS cache cannot be actively cleared; it can only be cleared after the TTL expires. Authoritative DNS servers themselves do not cache, so configuration changes take effect immediately, but there is a propagation delay in the caches of other nodes.

　　The reasons for ineffective cache refresh or resolution conflicts are usually related to the coexistence of multiple DNS services. For example, a user might modify the resolution using a local hosts file, but the browser might still use DNS over HTTPS for resolution, resulting in inconsistent results. Or, a website administrator might modify an A record but forget to delete the old AAAA record, causing IPv6 users to still access the old server. Similarly, some CDN platforms have independent caching policies, and node missynchronization can also lead to inconsistent target IPs. Therefore, when troubleshooting cache updates, it's crucial not to focus solely on the local system but also to verify the recursive DNS and CDN cache status.

　　Understanding the propagation path of DNS caching allows for controllable DNS changes. For example, if a website needs to switch servers in the early morning, the TTL can be adjusted to 300 seconds 24 hours in advance, and the authoritative DNS can be confirmed to have been modified before the old cache expires naturally. After the switch is complete, the TTL can be adjusted back to 3600 seconds or higher to ensure stability. This avoids issues such as "unable to connect to server" or "certificate error" caused by visitors accessing the old IP, and also prevents data from being written to the old machine, causing business disruption.

　　Furthermore, a shorter TTL is not always better, especially for high-traffic websites. A low TTL causes the recursive DNS to frequently query the authoritative DNS, and improper configuration can even lead to DNS amplification attacks or bandwidth waste. Recommended latency values ​​for general business operations are as follows: 24 hours for static content websites, 1 hour for dynamic content or occasional business changes, and 10-300 seconds for cross-datacenter scheduling services such as GSLB. Adjustments may be made temporarily during special periods such as e-commerce promotions or large-scale business migrations.

　　Besides TTL, modern DNS also supports mechanisms such as CDN split-line resolution, regional autonomous DNS, and authoritative cluster synchronization. Therefore, cache updates also involve the DNS service provider's refresh mechanism. Some DNS platforms offer manual refresh of the entire network cache to overwrite recursive node caches, but their principle is mostly to simulate a large number of recursive requests to trigger overwriting, rather than actually controlling the ISP's cache, and therefore is not absolutely reliable.

　　If users still receive the old IP address, it may be due to ISP DNS hijacking or abnormal caching on the recursive server. In this case, changing the DNS resolution server, such as switching to public DNS servers like 8.8.8.8, 1.1.1.1, or 223.5.5.5, can quickly verify whether it is a DNS caching issue.

　　For cross-border websites, it's crucial to be aware of the differences between international and domestic DNS caching. Sometimes, the update speeds of Chinese ISPs' DNS and overseas recursive server caches differ, leading to inconsistent access behavior. If necessary, global DNS lookup tools can be used to confirm the propagation situation, such as `dig +trace`, `nslookup`, or online DNS resolution testing platforms.

　　Once the caching logic is clearly understood, website owners can not only correctly manage DNS changes but also avoid business failures due to incorrect TTL settings, improving overall network controllability. In actual operation and maintenance, DNS is not simply about configuring domain name resolution; it's a fundamental service requiring strategic planning, understanding of propagation cycles, and long-term maintenance in conjunction with the network architecture.

　　Frequently Asked Questions

　　Q1: Why do some users immediately benefit from DNS resolution changes while others still access the old IP address?

　　A1: Because caching exists at different levels, the remaining TTL for each node differs. Some users' local, browser, or ISP DNS is still using the old cache and needs to wait for the TTL to expire before refreshing.

　　Q2: Does setting TTL to 0 mean no caching?

　　A2: Not all nodes strictly adhere to TTL=0. Some recursive DNS servers enforce a minimum cache period, such as 60 seconds. Therefore, TTL=0 cannot guarantee immediate nationwide synchronization, but it does significantly shorten caching time.

　　Q3: How long after reducing TTL can I safely modify DNS records?

　　A3: You must wait at least until the old TTL has completely expired. For example, if the original TTL was 86400 seconds (1 day), even after changing it to 300 seconds, you must wait 24 hours before modifying DNS records. Otherwise, users will still have old cached records.

　　Q4: How can I determine if the DNS cache has truly been refreshed?

　　A4: You can use `dig domain.com @dns_ip` to specify different DNS servers for querying, such as testing 8.8.8.8, 1.1.1.1, your local DNS, and your ISP's DNS. If the returned IPs match, the cache synchronization is successful.

　　Q5: What if I've cleared the browser and system cache, but still can't access the old IP address?

　　A5: This could be due to an outdated DNS from your ISP. Try switching to a public DNS server or using an overseas node for verification. It could also be caused by CDN caching, not a DNS caching issue.

　　Q6: How should I set the TTL during website migration?

　　A6: Recommended process: Lower the TTL 24 hours before migration -> Wait for the old cache to expire -> Perform the migration and modify the DNS records -> Verify that it takes effect across the entire network -> Adjust the TTL back to the normal value.