TTL for a DNS response is in seconds, and is intended to be the maximum time a value is cached. If you request an address for a name that the server you are talking to is authoritative for, then you will always get the TTL set in the DNS records. If your request goes to a caching name server that is not authoritative then you may get a lower value, in fact you most likely will. If the intermediate server makes a new request upstream it can, as per the spec, just pass on the TTL it gets¹, but some seem to drop one second just-in-case even though it isn't needed² really.
If an intermediate server handed out the original TTL for all requests then the TTL would be effectively multiplied by each caching layer³, which is why you will only get the true TTL at the client end if a fresh request was actually made to the authoritative server(s).
--
[1] the fraction of a second difference caused by latency isn't likely to be significant for either long or short TTLs
[2] and on a really high latency link (like back when GPRS or POTS landlines were common, or some links even now in deep rural areas) 1s might not be enough anyway for the benefit they think they are giving
[3] so at my home where lookups go PiHole->8.8.8.8->authoritative it would make TTLs potentially up to 2x their intended length. Example: for a 1000s TTL if PiHole gets the lookup request with 1s remaining but hands out the true TTL, my client will not check for 1000s, potentially 999s late. Depending on the sequence of related requests to each DNS server from other clients, that could become 1998s in my case, longer if there were more caching layers.
If an intermediate server handed out the original TTL for all requests then the TTL would be effectively multiplied by each caching layer³, which is why you will only get the true TTL at the client end if a fresh request was actually made to the authoritative server(s).
--
[1] the fraction of a second difference caused by latency isn't likely to be significant for either long or short TTLs
[2] and on a really high latency link (like back when GPRS or POTS landlines were common, or some links even now in deep rural areas) 1s might not be enough anyway for the benefit they think they are giving
[3] so at my home where lookups go PiHole->8.8.8.8->authoritative it would make TTLs potentially up to 2x their intended length. Example: for a 1000s TTL if PiHole gets the lookup request with 1s remaining but hands out the true TTL, my client will not check for 1000s, potentially 999s late. Depending on the sequence of related requests to each DNS server from other clients, that could become 1998s in my case, longer if there were more caching layers.