On Mar 1, 2019, at 9:33 AM, Dave Lawrence <t...@dd.org> wrote: > > Bob Harold writes: >> Will the "resolution recheck timer" cause ttl's less than the timer >> to be effectively lengthened, by refusing to look them up again? I >> think 'serve-stale' should focus on the situation where the auth >> server is not available, and not change the handling of short ttl's. >> Or am I mis-reading that? > > Mildly misreading, though it does point out that we could make it > clearer that this is akin to existing mechanisms that resolvers have > to cache that an authority is problematic (eg, RFC 2308 Section 7). > It is NOT about the feature that some resolvers also have, a minimum > cache TTL, which is what you're concerned about and we don't intend to > address in this document. As you say, and unfortunately we somehow > managed to not make clear, the purpose is only to deal with failures > to refresh authoritative data.
FWIW, I read it like Bob did. The following paragraph from the current draft makes it clear that the draft is proposing that the resolution recheck timer be lengthened to at least 30 seconds. If iterative lookups will be, done then the resolution recheck timer is consulted. Attempts to refresh from the authorities are recommended to be done no more frequently than every 30 seconds. If this request was received within this period, the cache may be immediately consulted for stale data to satisfy the request. I'm not sure a standards track document that updates RFC 1034/1035 should be recommending a minimum TTL. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
