> On Jan 25, 2018, at 3:27 PM, Evan Hunt <e...@isc.org> wrote: > > 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.
As an example, consider an ANAME record with TTL 3600 and a corresponding AAAA record with TTL 86400. I'm suggesting its just as acceptable to return the AAAA record with TTL counting down from 86400, but after 3600 seconds it is ejected/marked stale/whatever from the ANAME-implementing authoritative server. Unbound does that with its cache-max-ttl setting. If you do it this way then the consumers of the data (including ANAME-unaware clients) get to cache it for the original 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. I now notice that intermediate is sort of defined at the end of section 3. Perhaps that is sufficient. I guess we don't have a good collective term for CNAME/DNAME/ANAME yet. > >>> 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. It seems to me that ANAME gives auth servers resolver-like properties, so why wouldn't that apply there as well? DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
