What is DNS TTL? How Time-to-Live Affects DNS Filtering

Step 1: What is TTL?

TTL stands for Time-to-Live, and it is a value (measured in seconds) that is set by domain owners on their DNS records. The TTL tells DNS resolvers how long they should cache a DNS record before requesting a fresh copy from the authoritative DNS server.

For example, if a domain's A record has a TTL of 86400, that means any DNS resolver that looks up this record will store the result in its cache for 24 hours (86400 seconds = 24 hours). During that 24-hour window, any subsequent lookups for the same domain will be answered from the cache rather than querying the authoritative server again.

If the TTL is set to 300 (5 minutes), the resolver will cache the record for only 5 minutes before fetching a fresh copy. This means changes to the DNS record will propagate to users much faster — within 5 minutes instead of 24 hours.

TTL values are set by the domain owner, not by the DNS resolver or the end user. When you visit a website, the authoritative DNS server includes the TTL value in its response, and every resolver along the chain respects that value (though some resolvers may impose minimum or maximum TTL limits for performance or security reasons).

Common TTL values you will encounter include:

• 300 (5 minutes): Used for domains that change frequently or are preparing for a migration. Ensures changes propagate quickly.
• 3600 (1 hour): A common middle-ground TTL that balances performance with reasonable update speed.
• 86400 (24 hours): A standard TTL for stable domains that rarely change. Maximizes caching efficiency.
• 604800 (7 days): Used for very stable records like NS records that almost never change.

Step 2: How TTL Affects Performance

TTL creates a direct tradeoff between performance and freshness. Understanding this tradeoff is important for both domain owners and network administrators.

Short TTLs (e.g., 300 seconds) force DNS resolvers to query the authoritative server more frequently. This slightly increases DNS resolution latency because the resolver cannot serve the answer from cache — it must perform a fresh lookup each time the TTL expires. However, short TTLs ensure that changes to DNS records propagate quickly. If you update your A record to point to a new server, users will start reaching the new server within minutes.

Long TTLs (e.g., 86400 seconds) allow DNS resolvers to serve cached answers for extended periods, reducing the number of queries to authoritative servers. This improves resolution speed for end users (cached lookups are nearly instantaneous) and reduces load on authoritative DNS infrastructure. The tradeoff is that changes take longer to propagate — if you update a DNS record, some users may continue reaching the old IP address for up to 24 hours.

A common practice among domain administrators is to lower TTLs before a planned migration. For example, if you are moving your website to a new server, you might reduce the TTL from 86400 to 300 a day or two before the migration. This ensures that when you update the A record to the new server's IP address, all users pick up the change within 5 minutes. After the migration is complete and verified, you raise the TTL back to its original value for optimal caching performance.

For end users, TTL is largely invisible — you do not set or control it. But understanding it helps explain why DNS changes (including filtering changes) sometimes take time to take effect.

Step 3: TTL and DNS Filtering

TTL has a direct impact on how quickly changes in your DNS filtering configuration take effect across your network. When you make changes in a DNS filtering platform — such as blocking a new domain, unblocking a previously blocked domain, or changing a category rule — the change may not take effect immediately on all devices.

Here is why: when a device on your network first visits a domain, the DNS resolver (CleanBrowsing, in this case) looks up the record and returns a result based on your current filtering rules. That result is then cached on the resolver, on your router, and potentially on the device itself — each level respecting the domain's TTL value.

If the domain has a TTL of 86400 (24 hours) and you change your filtering rules shortly after the initial lookup, the cached result may persist for hours before a fresh lookup occurs. During that time, the old result (whether allowed or blocked) continues to be served from cache. The filtering change only takes effect when the cached entry expires and a new DNS lookup is performed.

This is normal behavior — not a bug. DNS caching is a fundamental part of how the internet works, and it exists for good reasons (performance, reliability, reduced load on infrastructure). Changes made to filtering rules typically propagate within 24-48 hours depending on the domain's TTL value. Most commonly accessed domains have TTLs between 300 and 86400 seconds.

If you need a filtering change to take effect immediately, you can speed up the process by clearing DNS caches at multiple levels:

• Browser cache: Close and reopen the browser, or clear the browser's DNS cache (in Chrome, visit chrome://net-internals/#dns and click "Clear host cache").
• Operating system cache: Flush the DNS cache on the device. On Windows, run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• Router cache: Restart the router to clear its DNS cache. This forces all devices on the network to perform fresh lookups.

Even after flushing local caches, the upstream resolver may still have the old record cached until the TTL expires. However, filtering resolvers like CleanBrowsing prioritize applying rule changes as quickly as possible, typically overriding cached results when filtering policies are updated.

Step 4: How to Check a Domain's TTL

You can check a domain's TTL using the dig command, which is available on macOS, Linux, and Windows (via WSL or third-party tools). The dig command queries DNS records and displays detailed information including the TTL value.

To check the TTL for a domain, open a terminal and run:

dig example.com

The response will include a section that looks like this:

;; ANSWER SECTION:
example.com.        86400   IN  A   93.184.216.34

In this output, 86400 is the TTL value in seconds — meaning this record is cached for 24 hours. The IN indicates the Internet class, A is the record type, and 93.184.216.34 is the IP address.

There are a few important nuances to understand when reading TTL values:

• TTL counts down: The TTL value you see in a dig response decreases over time as the cache counts down. If the original TTL is 86400 and you run dig 10 minutes after the record was cached, you might see 85800 (86400 minus 600 seconds). This is the remaining time before the cache entry expires.
• Intermediate caching: The TTL you see may differ from the authoritative value because intermediate resolvers may have already decremented it. To see the authoritative TTL, query the domain's authoritative name server directly: dig example.com @ns1.example.com.
• Minimum TTL enforcement: Some DNS resolvers enforce a minimum TTL (e.g., 60 seconds) to prevent excessive query volume from very low TTLs. Others enforce a maximum TTL to ensure records are refreshed within a reasonable timeframe. These limits vary by resolver.

You can also check other record types by specifying the type:

dig example.com MX
dig example.com TXT
dig example.com AAAA

Understanding TTL helps you set realistic expectations for how quickly DNS filtering changes take effect and helps you troubleshoot situations where a blocked or unblocked domain does not behave as expected immediately after a rule change.