At Fri, 7 Apr 2017 18:11:39 +0000, Evan Hunt <e...@isc.org> wrote: > 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.
I've read draft-hunt-dnsop-aname-00 and have some comments on it. I'm aware that similar comments on some points have been made in this thread, but I'm providing my own version at the risk of repeating as I think these are not necessarily a complete duplicate. Overall I agree this is worth trying to achieve. There is a clear need for the ability of defining an alias at a zone apex, and it will be nicer if we provide a standard-compliant and interoperable way for that. I also agree that a long-term goal (hope) should deploy it in the resolver side even if it will take quite long (if not fail), so that authoritative server implementations can be kept lightweight and simple. I have one high-level concern in terms of the merit of providing a standard/interoperable version of 'alias'. As already noted in the draft there are currently several proprietary mechanisms of 'alias', mainly to allow an alias at a zone apex. In order for the standard version to be successful, it will have to be compatible with these existing ones as much as possible and as long as it doesn't break other DNS standards. In that sense I see some disparity with the ALIAS record of Amazon Route53, one of the earliest (and probably largest) players of the idea: - Supporting other types of records than AAAA and A - Allowing different target names for different types I don't know how critical these are for existing R53 ALIAS users, but depending on that ANAME may not be able to be successful in practice. I also wonder whether it's okay to allow 'AAAA or A' and ANAME to coexist for the same owner name. Shouldn't it be prohibited similar to that CNAME and other types can't coexist? Some specific comments on the draft text follow: - Section 3 If the original query is for type A, and an RRset of type A exists at the final ANAME <target>, then that A RRset (with <owner> changed to match that of the ANAME RR), MUST be appended to the answer section after the ANAME RRset. What if the target name of ANAME does not exist (NXDOMAIN)? Returning NXDOMAIN is quite likely to be a bad choice, since the owner name of the query actually does exist. It will be certainly problematic if it's a zone apex. So should it be translated into NOERROR+NODATA? Or something else? Also, if the zone is signed, what kind of proof should be returned? - Section 3.1 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 TTL and the TTL of the address records retrieved from the ANAME <target>. The local TTL MUST count down, just as it would in a conventional resolver cache.[...] Should the local TTL count down, even if the initial value is from the ANAME TTL? I suspect that's not the intent, and if I'm correct I think the current text is confusing and should clarify it. - Section 3.2 If the zone is configured with an A or AAAA RRset at the same DNS node as ANAME, then the ANAME is considered to have been pre-expanded for zone transfer purposes. When a zone is being transferred to a secondary server, if any address record already exists at the same node as an ANAME RR, then the ANAME RR MUST NOT be further expanded by the authoritative server. (I have a more fundamental concern about the coexistence as stated above, but ignoring it in this context) I'm afraid this text talks about something not explained before this point or not even explained clearly anywhere in the draft. I guess the "pre-expand" means the following behavior described in section 3.3, but not necessarily with RRSIGs: Implementers MAY allow address records associated with the ANAME to be populated and signed by the primary server, then sent along with their RRSIGs to secondaries via zone transfer. If my understanding is correct, the concept of population/pre-expand behavior for zone transfer should be explicitly introduced before the discussion in Section 3.2. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
