Why do DNS resolution times for domain names vary, sometimes fast and sometimes slow?

　　Have you ever encountered this situation: you've changed the DNS records in your domain control panel, but after several hours, refreshing the page doesn't help. You ask a friend, who says, "I can access it, no problem." Even more frustrating is that you can access it using mobile data, but not on your home Wi-Fi. This phenomenon of "some people can access it while others can't" is caused by DNS resolution taking time.

　　To be honest, when I first started learning about DNS, I always thought that changing records would be instantly synchronized worldwide. It wasn't until I changed my server IP and waited two whole days with some users still reporting that their websites were inaccessible that I started seriously investigating the issue. Later, I realized that the varying speeds of DNS resolution taking effect aren't a problem with the service provider, but rather determined by the design mechanism of the entire DNS system.

　　To understand why the take-off time varies, you first need to understand a core concept—TTL. TTL stands for Time To Live, which defines how long a DNS record can survive in a cache server, measured in seconds. For example, if you set the TTL (Time To Live) of an A record to 3600 seconds, it means that after receiving this record, DNS servers worldwide will store the result on their servers for one hour. During this hour, no matter how you change the record on the authoritative DNS server, those servers will not query for the new record; instead, they will directly use the old cached record to respond to the user.

　　This is like posting a group announcement in WeChat saying "Meeting next Wednesday." People in the group see this and write it down in their memos, setting a reminder for "next Wednesday." The next day, you change your mind and want to change it to "next Thursday," but those who already have "next Wednesday" in their memos will continue to believe it's still next Wednesday unless they change their own records. TTL is like this "memo expiration date"—within the expiration period, the DNS server won't ask if you've changed it; it will only query again after the expiration date.

　　This explains why the effect of a changed DNS record isn't instantaneous. Theoretically, the longest time a modified or deleted DNS record is in effect is the TTL value before the modification. If you previously set it to 86,400 seconds (24 hours), it means that after making the change, in the worst case scenario, you have to wait 24 hours for all global caches to expire before the new record fully takes effect. This is why many people feel that changing their DNS settings is slow—it's not that the operation is slow, but rather that the TTL (Time To Live) determines the "shelf life" of the old cache.

　　The theoretical logic of TTL is clear, but reality is much more complex than theory. The actual effective time depends not only on the TTL you set, but also on how the local DNS servers of thousands of ISPs worldwide handle that TTL.

　　These local DNS servers are the caching nodes closest to the user, and each ISP manages its own caching policy. Most ISPs do respect the TTL value you set on the authoritative DNS, but some will "act on their own." Some ISPs, in order to reduce the burden on their own servers, will enforce a minimum caching time, such as 300 seconds or 600 seconds. Regardless of whether the TTL set on your authoritative DNS is 60 seconds or 120 seconds, it will cache according to its own lower limit. Even more egregiously, some ISPs' DNS servers completely ignore TTL (Time-To-Live), caching records for popular domains only every two or three days before updating them. This "lazy" behavior means that after you change a record, users in certain regions may not see the change for a long time.

　　Furthermore, even within the same ISP, caching strategies can differ between different cities and even different data centers. This explains why the same domain name might take effect within half an hour for users in Guangzhou, while users in Chengdu might wait several hours or even a whole day—because the local DNS servers in the two cities operate independently, and their cache refresh times differ.

　　Besides the ISP's local DNS cache, several other layers of caching are at work simultaneously. DNS resolution is essentially a multi-layered query process: after you enter a domain name, the request passes through the browser cache, the operating system cache, the local DNS server cache, and finally reaches the authoritative DNS server. Each layer caches its results, and the expiration time for each layer's cache may differ.

　　For example, after you change a DNS record, the new record on the authoritative DNS server takes effect immediately; the newly added record is almost instantly available at the authoritative DNS level. But what about the user's side? The browser cache might still be using the old IP address, the operating system cache might also be storing the old IP address, and the local DNS server cache might not have been refreshed for hours. These three layers of caching are stacked together, each with its own independent timer. The time it takes for the user to see the new IP address depends on when the "slowest" layer of caching expires.

　　For example, you change your IP address, but your local DNS server keeps returning the old IP address because the TTL (Time To Live) hasn't expired. You painstakingly clear your browser and operating system caches, but the local DNS server still shows the old address, and the webpage still won't open. This is why some people are confused—they've done everything, so why is it still not working? Because the root of the problem isn't on your end, but in the caching layer at your ISP.

　　There's another situation even more frustrating than changing a DNS record: changing your DNS provider. For example, if you migrate from Alibaba Cloud's DNS to Cloudflare's DNS, you need to change the Nameserver address with your domain registrar. This takes much longer to take effect than changing a single DNS record.

　　Why? Because the top-level domain's DNS server caches the Nameserver information used by your domain. Different top-level domains have different caching times. DNS servers for .com top-level domains may cache domain name DNS server information for up to 48 hours, while the caching time for .cn top-level domains is typically 24 hours. This means that after you point your domain to a new DNS service provider, recursive DNS servers around the world need to obtain the new Nameserver information before they can query the new authoritative DNS server for the resolution record. The TTL (Time To Live) of Nameserver information is usually determined by the top-level domain and cannot be actively controlled. Therefore, it is an industry consensus that it takes up to 48 hours for changes to DNS servers to take effect globally.

　　Another easily overlooked phenomenon is that adding a new resolution record takes effect almost instantly; however, modifying an existing record requires waiting for the TTL to expire. There is a reason behind this difference.

　　When a new record is added, there is no cache of this record anywhere in the world. Therefore, when the first user queries, the local DNS server must follow the complete recursive path all the way to the authoritative DNS to obtain the new record and cache it. In other words, the new record is created from scratch, without any old cache blocking the way, so it takes effect quickly. Alibaba Cloud's official documentation clearly explains this: When adding a DNS record for the first time to a domain, the record takes effect immediately because the client's local DNS has never cached the domain's DNS information.

　　However, modifying or deleting existing records is different. Old records are cached on countless local DNS servers worldwide, each with its own TTL (Time-To-Live) timer. Only after the timer reaches zero and the cache expires will those servers query the latest record. How quickly a modification can be performed depends entirely on the previously set TTL. This is why many experienced website owners lower their TTL several days in advance before migrating servers—first reducing the TTL to 300 seconds or even 60 seconds, waiting for global DNS servers to update to the new TTL setting before modifying the DNS records. This way, the changes take effect in a few minutes at most, instead of a whole day.

　　If you have DNSSEC enabled to prevent DNS hijacking and pollution, the take-off time will be even longer. DNSSEC adds digital signatures to DNS records, and recursive DNS servers need to verify these signatures before returning the resolution results. When enabling DNSSEC, you first need to generate a DS record, then configure it with your domain registrar. After configuration, you need to wait anywhere from 5 minutes to 48 hours for DNSSEC to be fully enabled.

　　Furthermore, DNSSEC adds a signature verification step to each resolution process, introducing a small additional latency, especially during cold caching or the first query, where the latency increase is more noticeable. Therefore, if you prioritize fast resolution activation, DNSSEC is indeed a factor that needs to be weighed—security comes at a cost, speed comes at a cost, and the trade-off needs to be determined based on your business scenario.

　　After all this explanation, you're probably a little confused. Finally, here's a clear comparison to help you quickly assess your situation.

　　If you simply add a new DNS record (which didn't exist before), the activation time is basically real-time because your local DNS server hasn't cached this record before and needs to query the authoritative DNS. If you modify or delete an existing DNS record, the activation time depends on the TTL value before the modification. A TTL of 10 minutes theoretically means it will take effect globally within 10 minutes; a TTL of 24 hours means you'll have to wait 24 hours. However, it's important to note that some regional ISPs' local DNS servers may disregard your set TTL and forcibly extend the caching time, resulting in a longer actual effective time than the theoretical value. It could take up to 48 hours for the changes to take effect globally.

　　If you've changed your DNS server, i.e., modified the Nameserver address of a domain name, the effective time can also take up to 48 hours, as the TTL for top-level name servers caching domain name DNS server information is generally between 24 and 48 hours. For records with DNSSEC enabled, the effective time will be increased by an additional 5 minutes to 48 hours on top of the above, for DS record synchronization and trust chain establishment.

　　The varying speeds of DNS resolution effectiveness are not ultimately due to a particular service provider being "slow" or "unreliable," but rather because the DNS system was designed from the outset to use a caching mechanism in exchange for the efficient operation of the global internet. Caching allows DNS queries to be completed in milliseconds, at the cost of sacrificing the immediacy of updates. Understanding this trade-off helps you understand why you sometimes need to wait patiently and how to proactively manage this waiting process. Next time you encounter a situation where "the record has been modified but the webpage is still the old one", first check what the TTL is set, and then think about whether the local cache has been cleared. You will most likely find the answer.