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

["Wessels, Duane" <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop