Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

[Evan Hunt <[e-mail]>]

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 -- [e-mail]
Internet Systems Consortium, Inc.