On Wed, 19 Sep 2018, Tony Finch wrote:

If I look up foo and it has an ANAME to bar, which of these do I get

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.

Exactly. And some dns server addonn can go look through the zone files
and find ANAME records, and do the query/updating via a cron job and
reload or something.

This is a simle solution that works.

With this model, signing only happens where it currently happens.

Good. Although if you want to return bar's IP if it is different from
foo's IP and for resolvers that don't understand ANAME, you have to
synthesize these, but at least then it is nor worse then DNS64 with
respect to DNSSEC.

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:

I agree, CNAME is tainted.


DNSOP mailing list

Reply via email to