dougb at dougbarton.email
Sun Jan 20 21:40:12 UTC 2019
On 2019-01-20 11:27 AM, Matthew Pounsett wrote:
> On Sat, 19 Jan 2019 at 13:16, m3047 <m3047 at m3047.net
> <mailto:m3047 at m3047.net>> wrote:
> Andrew, I don't think that RFC addresses the problem.
> I would go back to 1035.
> TTL a 32 bit signed integer that specifies the time interval
> that the resource record may be cached before the source
> of the information should again be consulted. Zero
> values are interpreted to mean that the RR can only be
> used for the transaction in progress, and should not be
> cached. For example, SOA records are always distributed
> with a zero TTL to prohibit caching. Zero values can
> also be used for extremely volatile data.
> For the moment, ignoring the case where an authoritative server answer
> with TTL=0... say for the sake of argument it responds with TTL=1. The
> caching server should cache it for one second, and after one second
> should remove it from the cache. Therefore, it should never respond
> from cache with a TTL of 0.
+1, emphasis on 'transaction in progress.' Matthew's logic is sound
here, and BIND's behavior is correct on cached answers that count down
to zero, IMO.
This is a special case of "time is hard," and bears thinking through. A
modern resolver might answer 10k queries in the second after a cached
answer ticks down from a TTL of 2 to 1. So that one second of validity
counts as that last second of TTL. When the TTL ticks down from 1 to 0
(per Greg's question) it doesn't mean that it gets one more second of
life with TTL=0, it means "time's up," so it should get expunged from
the cache at that moment.
The case of an auth server sending TTL=0 and the resolver(s) passing the
answer through is a special case, as pointed out in 1035, and that
answer is immediately dropped after it's sent; which reinforces the idea
that "When TTL=0 it's time to drop the answer."
More information about the dns-operations