[dns-operations] CNAME at the apex breaks DNSSEC DS lookups from caches

[Robert L Mathews]

On 4/14/22 4:00 PM, Mark Andrews wrote:
> Bring on HTTPS support in browsers as then this CNAME at the apex idiocy can go away.

I have doubts about this, because a) that will take a long time (a 
decade or more until people feel comfortable that most browsers are 
using them), and b) people are still going to want the same 
protocol-independent effect in other software that will never be updated 
to support HTTPS or SVCB records.

As a silly example, some people are going to want to "ping example.com" 
and expect it to reach the same IP address as "https://example.com".

I was disappointed to see the ANAME draft 
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/> retired in 
favor of HTTPS records, because unless I'm misunderstanding, they don't 
really solve the same problem, or at least not in the same way.

Experience shows that people really do want a way to express "every A 
record lookup for example.com should return the same value as whatever 
example.net (which I have no control over) currently returns", with no 
specification of protocols needed. They'll continue to want that for 
various (perhaps misguided) reasons.

I suppose the proper solution for people who want to do this is to use 
software that synthesizes A records based on lookups of the 
CNAME/ANAME/ALIAS target. But that has its own complications, and people 
will keep trying to do it natively in DNS with "CNAME at the apex" hacks 
and so on. It would be nicer if there was a proper way to do what people 
(think they) need.

(BTW, the isc.org "CNAME at the apex of a zone" page at 
<https://kb.isc.org/docs/aa-01640> has some text at the bottom that 
doesn't make sense, starting with "authoritative for a zone have been 
made capable".)

-- 
Robert L Mathews