Many people encounter this situation when accessing websites: the domain name has just had its DNS resolution changed, others can access it normally, but they are still redirected to the old server, or even cannot open the website at all. In this case, someone often suggests "clearing the DNS cache." But what exactly is a DNS cache? What is the difference between a browser DNS cache and a system DNS cache? Why does clearing the browser cache sometimes not work? To truly understand these questions, we need to start with the DNS resolution process itself.

　　When we enter a domain name in the browser address bar and press Enter, the computer doesn't immediately ask the public DNS server "which IP address this domain name corresponds to," but rather goes through a series of lookups from nearest to furthest. The purpose of this is singular: to improve access speed and reduce unnecessary network requests. In this process, the DNS cache plays a crucial role, and the cache doesn't exist in just one place, but is distributed across multiple levels. The most easily perceived by ordinary users are the browser DNS cache and the system DNS cache.

　　Let's start with the browser DNS cache. Modern browsers maintain an internal DNS cache to improve page loading speed. When you first access a domain name through your browser, the browser initiates a DNS lookup and obtains an IP address. This result isn't used only once; it's temporarily stored in the browser's internal cache. For a period of time afterward, whenever you access the same domain name again, the browser can retrieve the IP address directly from its cache without having to query the operating system or an external DNS server.

　　This caching mechanism significantly improves the user experience. Reducing the DNS lookup allows web pages to establish connections faster, especially noticeable on frequently visited websites. However, browser DNS caching also has its limitations. First, caches are independent between different browsers. Domains you access in Chrome are not automatically synchronized to Edge, Firefox, or other browsers. Second, browser caches typically have a short lifespan, and their implementation varies. Some browsers strictly adhere to the TTL value in the DNS records, while others set an internal upper or lower limit.

　　More importantly, browser DNS caching is only effective for the browser itself. If you're using command-line tools like ping, curl, or certain desktop software, they don't read the browser's DNS cache; instead, they rely directly on the operating system's DNS resolution results. This explains why sometimes "the browser opens, but ping fails," or "the command line resolves, but the browser fails to access the site."

　　Next, let's look at the system DNS cache. The system DNS cache is an operating system-level cache with a broader scope than the browser's. Whether it's a browser, instant messaging software, update programs, or background services, as long as they call the system's DNS resolution interface, they will ultimately be affected by the system DNS cache.

　　In Windows systems, the DNS Client service maintains a DNS cache table. Whenever the system successfully resolves a domain name, the result is recorded and reused within its TTL (Time-To-Live). While Linux and macOS implement this differently, they are essentially similar: they both store a copy of the resolution result locally to reduce reliance on external DNS servers.

　　The advantages of the system DNS cache are also obvious. On the one hand, caching can significantly reduce the number of DNS queries and improve overall network response speed; on the other hand, in cases of network instability or occasional DNS server unavailability, caching can ensure that some domain names can still be accessed normally. However, it is also one of the common causes of the "resolved DNS changes but access unchanged" problem.

　　Many beginners have a misconception that as long as DNS resolution is changed in the domain control panel, it will immediately take effect everywhere. In reality, the entire propagation process is layered, from authoritative DNS servers to various levels of recursive DNS, and then to the local system cache. Even if the public DNS has returned a new IP, as long as the old record is still retained in the local system DNS cache, the system will prioritize using the cached result and will not actively query again.

　　The browser DNS cache and the system DNS cache are not completely equivalent. Typically, the browser will first check its own cache; if a match is found, it will use it directly; if not, it will send a DNS query request to the operating system. Upon receiving the request, the operating system will first check the system DNS cache; if a match is found, it will return the result directly; if not, it will continue to query the configured DNS server. In other words, browser caching is a "sub-caching" layer above system caching.

　　Because of this hierarchical structure, some seemingly strange but actually reasonable phenomena can occur. For example, if you clear the system DNS cache but find that the browser is still accessing the old IP address, this is because the browser's internal DNS cache has not yet expired; conversely, if you simply restart the browser and find the problem solved, it's because the browser cache was cleared, while the system cache itself remained unchanged.

　　In practical use, when to focus on browser DNS caching and when to focus on system DNS caching depends on the problem's manifestation. If only one browser experiences abnormal access, but switching to another browser works immediately, the browser's own DNS cache or browser extensions are usually the first suspects. If all browsers and software experience abnormal access to the same domain, but it works fine on another computer, then the system DNS cache or local DNS configuration should be the focus of investigation.

　　For website owners and system administrators, understanding these two levels of caching is particularly important. For example, when migrating servers, switching CDNs, or modifying DNS records, it's common to encounter situations where "I've already switched everything, but the customer is still accessing the old site." Often, the problem isn't a DNS configuration error, but rather that the customer's local system DNS cache hasn't been refreshed. In such cases, instead of repeatedly checking server configurations, it's better to guide users to refresh their DNS cache or patiently wait for the TTL to expire.

　　It's important to note that DNS caching doesn't always strictly adhere to the TTL. Different operating systems and browsers have subtle differences in implementation, sometimes with minimum or maximum cache duration limits. This is why, even with a short TTL, a small number of users might still access old IPs for extended periods.

　　From a security perspective, DNS caching is a double-edged sword. Proper caching can improve performance, but if the cache is corrupted or hijacked, users can be redirected to incorrect servers. Therefore, operating systems and browsers perform checks on the source and validity of DNS caches and provide the ability to refresh or clear the cache to recover from anomalies.

　　In summary, browser DNS caching focuses more on improving the access efficiency of individual browsers, with a smaller scope and faster updates, but it is highly independent; system DNS caching, on the other hand, is the infrastructure of the entire system, with a wider impact and higher stability, but it is also more "stubborn" when problems arise. Only by clarifying the scope and priority of these two can we quickly determine which layer the problem lies at when encountering resolution-related issues, rather than blindly taking action.