> On 19 Sep 2018, at 21:14, John Levine <jo...@taugh.com> wrote: > If I look up foo and it has an ANAME to bar, which of these do I get > back?
; ANSWER SECTION foo. A 1.2.3.4 ; ADDITIONAL SECTION foo. ANAME bar. bar. A 1.2.3.4 The model is that this is a replacement for manually copying address records, with added hints to resolvers that they might want to re-do the copying in order to get geo-optimized answers or other complicated tricks. > The second is a lot more like what CNAME does, and also avoids having > to sign on the fly. With this model, signing only happens where it currently happens. > PS: I still think fixing apex CNAME is a better way to go. There are still DNS servers out there running on 1990s semantics, so I don’t think CNAME can be fixed any time soon - much of my practical annoyance comes from people asking for CNAME and MX and this combination is doom on a stick because it involves crazy MTA DNS message handlers, not just DNS servers. My guess at deployment timelines is: * minimal ANAME can be deployed unilaterally on the provisioning side 20 years ago and similar features are widely available (you are ahead of me on this one, John!); if resolvers implement it there will be useful amounts of deployed support within a few years * browser-friendly SRV replacement: two years to standardization; another two years watching caniuse before we can maybe think about not copying A records around; even more years before it becomes as portable on the provisioning side as ANAME is now * fix CNAME, at least 10 years Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
