Webmasters Stack Exchange is a question and answer site for webmasters. It only takes a minute to sign up.
Sign up to join this community
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?
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.
