How to adjust the TTL value for domain name resolution? Techniques for balancing activation speed and DNS query pressure.

　　TTL is something you see every day in your domain name resolution backend—that little box with 600 defaults and "seconds" written on it. Most people see the default value, are too lazy to change it, and just save it. Some people are impatient and change it to 60; others, wanting to play it safe, change it to 86400. Frankly, very few can honestly say, "I've thought this through carefully."

　　TTL isn't a huge deal, but it's not insignificant either. If you set it correctly, no one will praise you; if you set it wrong and encounter a problem wanting to switch IPs, you'll know what "time drags on forever" truly means.

　　TTL, short for Time To Live, in the context of domain name resolution, refers to the cache time of DNS records on your local DNS server (i.e., your ISP's DNS, public DNS, such as 114.114.114.114 or 8.8.8.8).

　　For example, if you point the A record of www.example.com to 1.2.3.4, and set the TTL to 3600 seconds... When a user visits your website, their local DNS resolver retrieves the result 1.2.3.4. Instead of immediately discarding it, it caches it for one hour. During this hour, if another user (or the same user visits again) queries the IP address of www.example.com, the local DNS simply retrieves the cached result and sends it back, without ever querying your authoritative DNS again.

　　Therefore, the core functions of TTL (Time To Live) are twofold: first, to control the speed at which DNS resolution takes effect (how long it takes for a record change to take effect globally); and second, to control the query load on the authoritative DNS server (the longer the cache, the fewer queries).

　　These two are inherently contradictory. For fast results, the TTL must be short; for reduced DNS load, the TTL must be long. Adjusting the TTL essentially involves finding the balance between these two.

　　You need to be aware of the different roles within the caching chain.

　　TTL is not something you set and then strictly enforce 100% everywhere. The DNS resolution chain is as follows:

　　User browser → Operating system DNS cache → Local recursive DNS server (ISP/public DNS) → Root DNS → Top-level domain DNS → Your authoritative DNS

　　Each layer in this chain may have caching capabilities. The TTL you set for the authoritative DNS is a "recommended value" for the local recursive DNS, and most will adhere to it. However, some ISP DNS servers may not follow this rule and force a longer TTL, regardless of your settings. There's also the browser's own DNS caching (Chrome caches for about 60 seconds), which you can't control, so just be aware of it.

　　Therefore, adjusting the TTL affects the vast majority of law-abiding local recursive DNS servers. Those that don't follow the rules are not discussed here, nor can they be.

　　Scenario 1: Relatively stable business with few major changes

　　If your website server IP doesn't change frequently, CDN doesn't switch often, and domain name resolution configuration is stable, then there's absolutely no need to set a short TTL. Using a short TTL in this case only increases the number of queries to the authoritative DNS and incurs higher resolution costs; it offers no other benefits.

　　In such scenarios, a TTL setting of 3600 seconds (1 hour) to 86400 seconds (24 hours) is reasonable. I've seen many people set it to 600 seconds (10 minutes), thinking, "What if I need to change it?" But in reality, you won't change it even once a year, so setting it so short is a waste of resources. It's not that 10 minutes would cause much loss, it's just unnecessary.

　　If the business scale is relatively large, with millions of daily active users, the number of queries to the authoritative DNS directly affects stability and cost. In that case, a longer TTL setting is preferable, such as 12 hours or even 24 hours. Since the configuration won't be changed, the longer the cache, the more friendly it is to the authoritative DNS.

　　Scenario Two: Frequent Operational Changes and IP Switching

　　Some businesses are quite flexible, with servers frequently scaling up and down. Newly deployed machines with changed IPs require DNS switching, or A/B testing requires traffic switching. In this case, you certainly don't want to wait several hours to see the effects after changing the DNS.

　　In this scenario, lowering the TTL in advance is standard operating procedure. For example, if you know you're going to switch IPs tonight, several hours or even a day in advance, change the TTL from 3600 to 60. Wait until the old cache is almost expired before modifying the A record. After doing this, the new IP should resolve to most locations within a minute or two.

　　Important: Pay close attention to the order: lower the TTL first, wait for the old cache to expire, then modify the record. Many people do it the other way around, changing the IP first and then remembering they haven't changed the TTL, resulting in waiting an hour for it to take effect, causing frustration. Changing the TTL itself only takes effect after the original TTL expires, so it needs to be done in advance.

　　Scenario 3: Connecting to a CDN or Switching CDN Providers

　　When connecting to a CDN, the CDN will give you a CNAME domain. You need to change the original A record to the CNAME. How is TTL handled during this process?

　　If your original TTL is long, such as 24 hours, and you want to see quick results after integrating the CDN, the safest approach is to shorten the TTL (e.g., to 300 seconds) before proceeding. Wait 24 hours (until the original TTL has fully expired) before switching from A records to CNAME records. This way, if there are any configuration issues with the CDN, you can quickly roll back. It's standard practice to wait for the original TTL period to expire before switching, rather than rushing.

　　If the CDN has been running for a while and the business is stable, the TTL can be adjusted back to a moderate value, such as 600 seconds or 1800 seconds. In a CDN scenario, most traffic passes through CDN nodes, and the pressure on DNS resolution is relatively distributed. Setting the TTL to 30 minutes to 1 hour is common, avoiding being too passive during switching and avoiding unnecessary burden on the DNS server.

　　What's a suitable TTL setting? Here's a reference range:

　　There's no single answer, but here are a few reference ranges based on your business type. Choose the one that suits your needs:

　　60-120 seconds: Suitable for high-frequency operation and maintenance scenarios, such as frequent traffic switching, canary releases, and emergency drills. The advantage is extremely fast activation; the disadvantage is a significant increase in DNS query volume and high pressure on authoritative DNS servers. It's not recommended for long-term use as a standard configuration.

　　300-600 seconds (5-10 minutes): Suitable for general web applications. It allows for quick failover in case of problems, and DNS pressure remains within acceptable limits. This is the default value for most CDN scenarios, making it a versatile range.

　　1800-3600 seconds (30 minutes to 1 hour): Suitable for relatively stable businesses with low change frequency, such as corporate websites and SaaS backends. It balances activation speed and caching efficiency; this range is sufficient for most ordinary websites.

　　86400 seconds (24 hours): Suitable for purely static resources, download sites, domains that don't change much, or cost-sensitive overseas businesses (overseas DNS lookup fees are high). However, it's recommended to use this in conjunction with the process of "manually lowering the TTL before making changes," otherwise, it will be difficult when you actually need to change it.

　　Practical Application: Note these points when changing TTL

　　First, changing the TTL won't take effect immediately. If you just changed the TTL from 3600 to 60, this change itself will only take effect after the original 3600 seconds expires, and then DNS servers in various regions will fetch the new TTL value. So, if you want to "shorten the TTL now and immediately switch IPs," this is not possible; you have to wait. Adjusting the TTL one day in advance is basic operational etiquette.

　　Second, TTL is not set uniformly for all record types. Some DNS service providers support setting TTL separately for each record type. For example, your A record can be set to 600 seconds, MX records to 86400 seconds, and TXT verification records to 60 seconds. There's no need for a one-size-fits-all approach; each record should be configured individually based on its importance and change frequency.

　　Third, not all DNS providers support arbitrary TTL values. Some cheap or free DNS services only allow a minimum TTL of 600 seconds, not 60 seconds. Check the specifications before purchasing. Furthermore, the architecture of the authoritative DNS provider may affect the actual minimum effective TTL; values ​​exceeding the provider's supported range will be forcibly changed to the default value.

　　Fourth, after modifying a record, it's recommended to restore the TTL to normal. Don't leave it on a short TTL. Many people change the TTL to 60 seconds for emergencies, forget to change it back afterward, and find that a month later, the authoritative DNS query volume remains high, resulting in extra monthly DNS resolution fees. Don't forget to change it when you need to.

　　Ultimately, TTL isn't a "the higher the better" or "the lower the better" indicator; it's a strategic parameter. The accuracy of your judgment on the frequency of business changes determines whether the TTL setting is reasonable. For frequently changing services, accept the DNS pressure brought by short TTLs; for stable services, enjoy the caching benefits of long TTLs—it's that simple. The worst thing you can do is to use a one-size-fits-all approach, using default values ​​regardless of the scenario or the characteristics of your business—if you do that, you'll know the despair of "watching the server crash, but being unable to switch DNS resolutions" when a failure occurs.