4

I'm just curious to know what the maximum practical TTL value is for an A entry.

Somewhere I found the TTL value can be as high as 99,999,999 seconds, about 3.1 years, but simply that would not be practical! ISPs would ignore it, wouldn't they?

I currently set A entries of my domain to 864000 seconds (10 days), because I will stay in my current server and want to reduce DNS queries.

Will this really reduce DNS queries and, for the first visit, speed-up website loading?

  • 2
    DNS queries are unlikely to be a significant bottleneck or resource drain, unless you’re operating at the scale of Google or Facebook, and you would probably find the flexibility of a shorter TTL more valuable. – Mike Scott May 25 '18 at 7:22
  • 1
    Are you hosting your own DNS? If not and you don't pay per query then more queries shouldn't affect you much. – jrtapsell May 25 '18 at 8:21
  • 1
    "for the first visit, speed-up website loading?" - Why would this speed up the "first visit"? Long DNS cache times will primarily only help returning visitors unless there is an intermediary DNS cache. – MrWhite May 25 '18 at 9:42
  • @jrtapsell, Yes, I am, but I don't pay per query. All I would like to do is to configure my server so that it performs at its highest potential. Thanks for your comment. – Siamak May 25 '18 at 10:42
  • @MrWhite, I thought the IP is cached by the ISP, so when a user of ISP ABC for example visits my website, anybody else of the same ISP will not need to send a query to find out the IP address. Is it incorrect? – Siamak May 25 '18 at 10:47
6

TL;DR Maximum value is 2147483647 (seconds), which is around 68 years.

TTL is defined in RFC 1034 as: " This field is a 32 bit integer in units of seconds, an is primarily used by resolvers when they cache RRs.". So its maximum value should be 232 - 1, that is 4 294 967 295 seconds or about 136 years (which is absurd, but that is the standard).

However this got redefined in RFC 2181 as such:

The definition of values appropriate to the TTL field in STD 13 is
not as clear as it could be, with respect to how many significant
bits exist, and whether the value is signed or unsigned. It is
hereby specified that a TTL value is an unsigned number, with a
minimum value of 0, and a maximum value of 2147483647. That is, a
maximum of 2^31 - 1. When transmitted, this value shall be encoded
in the less significant 31 bits of the 32 bit TTL field, with the
most significant, or sign, bit set to zero.

Note that there is some ambiguity: it is an indication of the maximum amount of time a resolver should keep a given record, however the resolver is free to dump it before that if it wishes, for whatever reasons (full cache, desire to retrieve fresher information, etc.) but in theory should never go above the value (but some resolvers do, specially in the face of absurdly low TTL values like 5 seconds).

This is clearly spelled out in RFC 2181:

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.

The TTL will have absolutely no impact for first time visit: if you consider your visitor to only go through DNS cold caches, all queries will be missed and the full resolution will need to happen. Only after it will the record be cached and then the TTL will be relevant.

It is true that ISP typically provide recursive nameservers to their clients, hence their cache is shared among all clients, so if one of them goes to your website, this fills the cache, and the next client of the same ISP going to it will get the record directly out of the ISP recursive nameserver.

There is no worldwide respected definite advise on which value is a good one. For most static services something around a couple of days is probably ok. If you need to change things later on (like changing hosting) you could plan in advance and first start by publishing a new record with very reduced TTL, wait for the previous TTL value (I simplify, other timers need to be taken into account in fact), change your record, wait again at least for the new TTL (optional, instead probably better to just leave things like they are during the time you need to validate the new setting), publish a new record with the TTL back to normal.

  • Thanks for your information, @patrick-mevzek. It is exactly what I wanted to know. So, what if there are two DNS resolvers for the main domain and the A record in question points to two IP address (two separate servers, one in OVH and the other in Hetzner). In other words, the domain is hosted by two servers, each with an active DNS resolver, and the domain has two name servers at the parent (in domain control panel), one for each server. Suppose the servers are not going to be changed. Here, is it OK to set TTL to 10 days? And will users be able to connect to the site if one server fails? – Siamak May 26 '18 at 1:46
  • I would add that both DNS resolvers report both IPs. I checked the configuration by dnscheck.pingdom.com, and there weren't any errors or warnings. – Siamak May 26 '18 at 1:53
  • 1
    @Siamak no the DNS does not work like that, it is load balancing. If you publish two A records for a name, on average, each IP will get 50% of requests. If one fails, clients MAY switch to the other, or not, it depends a lot on the client OS, the client software and the protocol. Specifically for HTTP, it is better to publish only IP addresses that work. So put in place some monitoring that can change the zone content (but of course if the TTL is in days, the change will take a long time to be seen). I am not sure to understand, and it is a new question so if needed do a new separate post. – Patrick Mevzek May 26 '18 at 2:18

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.