I'm happy to see progress being made on this front. Some comments: *Section 3.1*
This section calls for limiting the TTL of cached address records to the lesser of the ANAME TTL and the TTL of the retrieved address records, but section 3 requires servers to follow chained responses. Are the TTLs of intermediate records in a chain supposed to be ignored? What is the expected behavior when the target record set is empty, or bogus, or when resolution fails? *Section 3.2* The wording of this section could use some improvement. It seems to prohibit secondary servers from resolving ANAME targets when they are present at the same domain as address types... do I understand correctly? Are such address records still subject to TTL decrementing (presumably starting at the time of zone transfer)? And when only a single address type is present (e.g., just ANAME and A), does that still prevent resolution of the ANAME target for the other type? *Section 3.3* Although labeled "DNSSEC signing", this section also contains more general specification (e.g., "the master server MUST respect the TTLs of the address records" and "TTLs [of address records in a secondary server] will count down"). It is also mute on the use of DNSSEC for resolving ANAME target records, but that should probably be covered somewhere. On Fri, Apr 7, 2017 at 2:11 PM, Evan Hunt <e...@isc.org> wrote: > Greetings, > > Here's the new ANAME draft I mentioned last week. > > This is similar to existing non-standard approaches (ALIAS records, > CNAME-flattening, etc) but also sends the ANAME record to the resolver so > that, if the resolver understands the ANAME type, it can re-query for the > answer just as it would with a CNAME. > > Please have at it. > > ----- Forwarded message from internet-dra...@ietf.org ----- > > From: internet-dra...@ietf.org > To: Evan Hunt <e...@isc.org>, Peter van Dijk <peter.van.d...@powerdns.com > >, > Anthony Eden <anthony.e...@dnsimple.com> > Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt > Date: Fri, 07 Apr 2017 11:04:39 -0700 > > A new version of I-D, draft-hunt-dnsop-aname-00.txt > has been successfully submitted by Evan Hunt and posted to the > IETF repository. > > Name: draft-hunt-dnsop-aname > Revision: 00 > Title: Address-specific DNS Name Redirection (ANAME) > Document date: 2017-04-07 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet- > drafts/draft-hunt-dnsop-aname-00.txt > Status: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > Htmlized: https://tools.ietf.org/html/draft-hunt-dnsop-aname-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-dnsop- > aname-00 > > > 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. > > 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. > > The IETF Secretariat > > ----- End forwarded message ----- > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > _______________________________________________ > 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
