On Fri, 7 Apr 2017, Evan Hunt wrote:
Here's the new ANAME draft I mentioned last week.
I like this one a little better, but :) When an ANAME record is present at a DNS node and a query is received by an authoritative server for type A or AAAA, the authoritative server returns the ANAME RR in the answer section. This is good, then it goes on with: Because not all querying resolvers understand ANAME, the authoritative server MUST also return address records, as described below. [...] Authoritative servers implementing ANAME MUST be equipped to resolve the ANAME <target> on the querying resolver's behalf, either by sending queries to an external recursive resolver or by implementing recursive resolution logic internally, so that address records can be expanded when the ANAME <target> is in a separate zone from <owner>. I guess I'm still not a fan of the AUTH server doing this. Moreover: When a recursive resolver sends a query of type A or AAAA and receives a response with an ANAME RRset in the answer section, it MUST re-query for the ANAME <target>. This is necessary because, in some cases, the address received will be dependent on network topology and other considerations, and the resolver may find a different answer than the authoritative server did. That opens up a whole can of worms :P We start with the problem of "we need addresses at the APEX be non-static, but then you add logic to support that and then it is not good enough for the job. AUTH servers already know how to return split view answers with various implementations based on geolocation, edns-subnet or what not. Also, a resolver support ANAME sending a query to a forwarding resolver might only receive the ANAME record back without anything else, and then has to do all the ANAME chasing itself anyway. So why not just always do that behaviour? So why not happy eyeball ANAME along with A/AAAA queries. Old stuff gets somewhat risky and possibly outdated A/AAAA records, and newer clients get the proper redirection. But really, what it comes down to for me is that if you are adding logic to the AUTH nameservers to synthesize ANAME into A/AAAA records, why bother ever sending ANAME over the wire? Just let clients send A/AAAA and never ask for ANAME. And have the AUTH server code that sees an ANAME in the zone at the place of the QNAME for A/AAAA synthesize by doing the queries. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
