> 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?

foo. A

foo. ANAME bar.
bar. A

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

f.anthony.n.finch  <d...@dotat.at>  http://dotat.at

DNSOP mailing list

Reply via email to