Hi Paul, On Fri, Apr 07, 2017 at 05:16:14PM -0400, Paul Wouters wrote: > 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.
The hope here is that, in the long run, ANAME resolution would be the job of the resolver, which in in a position to get the best answer for its clients, given geolocation and topology considerations. Expansion of ANAME on the authoritative end is a workaround for the fact that we can't go back in time and put ANAME support into all the resolvers. > 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. Resolvers don't ask for ANAME. They ask for A/AAAA, and get an A/AAAA answer, along with an ANAME record so they can go directly to the source and get a better answer if they support that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
