I asked some questions about the -00 of this draft back in October which I don't think were addressed:
https://mailarchive.ietf.org/arch/msg/dnsop/Pc8iGemfjO2FsNV-MNd5n6eKvUc/?qid=c250bacc5206b035878ddcb9036b9e53 I'll try to ask them again based on the current text: > The initial > TTL for locally-cached address records MUST be set to the minimum of > the ANAME TTL and the TTLs of the intermediate and address records > retrieved during ANAME <> resolution. 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. 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. > 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. 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." > In this case, the master server MUST respect the TTLs of the address records, Suggest s/master/primary/ to be consistent with previous text. DW > On Jan 11, 2018, at 9:25 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 WG of the IETF. > > Title : Address-specific DNS Name Redirection (ANAME) > Authors : Evan Hunt > Peter van Dijk > Anthony Eden > Filename : draft-ietf-dnsop-aname-01.txt > Pages : 12 > Date : 2018-01-11 > > 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-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-01 > > > 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
