Here's my scenario:

  • I have an office which connects to AWS via a VPN tunnel to access some EC2 instances.
  • The office computers use AWS Route 53 via the VPN tunnel to resolve a private hosted zone.
  • The private hosted zone contains A records of assets located in the office. Printers, application servers, etc.
  • Office workstations are configured to use the internal address of AWS' DNS server (in the subnet with EC2 instances).

Everything is resolving fine.

Now in order to cater for the VPN tunnel going down and therefore reachability to AWS' DNS server going down too, I configured the DNS records of the internal assets to have a TTL of 432,000 seconds, or 5 days. Basically that gives me 5 days to reestablish the VPN tunnel before office workstations fail to resolve, by name, the internal assets.

However, I've noticed the following behaviour and am wondering whether this is "normal" for the resolver and (Windows 10) client?

  • Querying the authoritative server shows the TTL to be 432,000
  • Querying the resolver shows TTL to be 86,400
  • Querying the client (e.g. ipconfig /displaydns) also shows 86,400 (and decrements which is normal behaviour).

I've tried changing the TTL and it appears that the Windows client will respect any TTL value less than or equal to 86,400.

Why does the record's TTL of 432,000 at the authoritative server level not get propagated to the resolver and therefore the client? Am I misunderstanding something fundamental to how TTLs work?

Thanks in advanced!

  • 1
    RFC 2181, 8: "Implementations are always free to place an upper bound on any TTL received, and treat any larger values as if they were that upper bound. The TTL specifies a maximum time to live, not a mandatory time to live." Technically you could specify TTL for as long as 2147483647 seconds i.e. ~68 years, but can't expect resolvers to respect that and actually keep the cache for longer than it's configured to keep it. – Esa Jokinen Jul 28 '20 at 1:01

Ok so in the course of adding more context to the question I ended up solving the problem.

For those who stumble across this, for Windows clients, in order to increase the default TTL of 86,400 seconds (1 day), simply create a DWORD registry entry called MaxCacheTtl under the following key:


Then, enter a value (in decimal) of the maximum TTL you want the client to cache and reboot. As per @EsaJokinen comment, you can go up to 2147483647 if you're so inclined.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.