On Thu, Jan 25, 2018 at 10:05:24PM +0000, Wessels, Duane wrote: > Why does the draft mandate initial TTL behavior? The important aspect > would seem to be how long the data can be kept in cache, not what the > (initial) TTL value is. As I noted in the previous message, Unbound's > cache-max-ttl works that way and I think it has some nice properties.
I'm not sure I understand the distinction you're making. When you first cache something, its TTL represents the length of time that data can be kept in the cache, and it counts down from there to zero. That's what I meant by the initial TTL. > Also in this new text I'm not sure what to make of "intermediate and address > records." If "and" is truly intentional in this phrase then I think > intermediate should be better defined, or examples given. Suppose ANAME (TTL 3600) points to a CNAME (TTL 30) which points to a CNAME (TTL 5) which points to an A (TTL 86400). The response would contain ANAME with TTL 3600 and, because of the intermediate CNAME, A with TTL 5. Suggestions welcome for a clearer way to phrase this. > > Address records with expired TTLs MUST NOT be used to answer > > address queries until refreshed by sending a new query to the ANAME > > <target>. > > > > [...] > > > > If resolution of the ANAME <target> yields no address records due to > > some other failure, and the query was for a specific address type, > > the response MUST include the ANAME record and set the RCODE to > > SERVFAIL. > > If the authoritative server has address records, which then expire, and > cannot be refreshed, I read this as saying the later response must be > SERVFAIL. For A or AAAA queries, that is the intent. An explicit query for type ANAME would still be answered. > That seems in contradiction with the ideas of draft-serve-stale which says > "stale bread is better than no bread" and "Several major recursive resolver > operations currently use stale data for answers in some way ... Their > collective operational experience is that it provides significant benefit > with minimal downside." This seems like a job for the resolver, not the auth server. In the long term my hope is that resolvers will implement ANAME, chase the answers themselves, and then decide whether to serve stale records or not. However, I guess we can relax this requirement if the auth server is configured for serve-stale. -- Evan Hunt -- [email protected] Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
