On Thu, Jan 25, 2018 at 11:51:30PM +0000, Wessels, Duane wrote: > As an example, consider an ANAME record with TTL 3600 and a corresponding > AAAA record with TTL 86400.
You'd want the AAAA to expire no later than the ANAME did, because the ANAME might have been updated to point to some other name by then. > 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. That's exactly what I'm trying to prevent. With an ANAME-aware resolver, the address returned by the auth is ignored, the resolver chases the answer for itself, and records are all cached with their original TTLs. The ANAME answer and the target answers expire when they should, just as with a CNAME now. In your example, the ANAME expires after 3600 seconds, so we re-query to refresh it. If it's changed, then we follow it to get a new AAAA, but if it hasn't changed, then since we already have the AAAA cached, there's no need to chase it again. But with an ANAME-unaware resolver, it asked for an address, got one, and will cache it for whatever TTL you sent it. If your ANAME has a one-hour TTL, then you wouldn't want to send a higher TTL than that; you'd just overriding the ANAME TTL. > It seems to me that ANAME gives auth servers resolver-like properties, so > why wouldn't that apply there as well? Yes, fair point. I'll try to come up with text to address this. -- Evan Hunt -- [email protected] Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
