I have a couple of questions about the text in 3.1 around TTLs and caching:
> Address records cached locally MUST have a limited TTL. The initial TTL
> for locally-cached address records MUST be set to the lesser of the ANAME
Reading this reminds me of the way that Unbound works with respect to its
cache-max-ttl. Quoting the documentation:
cache-max-ttl: <seconds>
Time to live maximum for RRsets and messages in the cache.
Default is 86400 seconds (1 day). If the maximum kicks in,
responses to clients still get decrementing TTLs based on the
original (larger) values. When the internal TTL expires, the
cache item has expired. Can be set lower to force the resolver
to query for data often, and not trust (very large) TTL values.
In other words, Unbound uses the original TTL but removes the data after
cache-max-ttl, which might be shorter.
Might it not also be acceptable (desirable?) to do the same for aname? I think
it would mean that the A/AAAA records are cached similarly by both aname-aware
and aname-unware recursive name servers.
> TTL and the TTL of the address records retrieved from the ANAME <target>.
Perhaps "...and the TTLs of all the address records..."?
> The local TTL MUST count down, just as it would in a conventional resolver
> cache. Records with an expired TTL MUST NOT be used to answer address
> queries until refreshed with a new query to the ANAME <target>.
That only says what not to do. How should the server respond if the
locally-cached address records cannot be refreshed? SERVFAIL? whatever
draft-serve-stale says?
DW
> On May 27, 2017, at 2:36 PM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title : Address-specific DNS Name Redirection (ANAME)
> Authors : Evan Hunt
> Peter van Dijk
> Anthony Eden
> Filename : draft-ietf-dnsop-aname-00.txt
> Pages : 10
> Date : 2017-05-27
>
> Abstract:
> This document defines the "ANAME" DNS RR type, to provide similar
> functionality to CNAME, but only redirects type A and AAAA queries.
> Unlike CNAME, an ANAME can coexist with other record types. The
> ANAME RR allows zone owners to redirect queries for apex domain names
> in a standards compliant manner.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-aname-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
