Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Joe Abley <[e-mail]>]

On Jun 19, 2018, at 10:20, Tony Finch <[e-mail]> wrote:

> Petr Špaček <[e-mail]> wrote:
>>
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
>
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of deeply hierarchial subdomains in my main
> zone. CNAME at apex does not need to be (and I think should not be treated
> as) a special case.

My memory of the specifics about the various ANAME/BNAME/ALIAS/etc
proposals or non-standard features is fuzzy so the following may miss
the point (apologies if so, as usual).

However, it sounds a bit like what is being proposed in this thread
(generally, not in your specific message) is for CNAME to be treated
on authority servers like a wildcard RRTYPE for a particular owner
name. The response behaviour if a CNAME is present at the owner name
matching the QTYPE but there is no corresponding RRTYPE in the zone is
to return a NOERROR/CNAME response instead of a NODATA response.

For recursive servers the change that is required is to keep track of
what QTYPEs triggered particular CNAMEs in the cache so that new-QTYPE
cache misses trigger an upstream query.

All of this needs to be extended along the edns-client-subnet axis.

All of the corner cases relating to existing CNAME behaviour, both
standardised and not, on recursive servers, stub resolvers and
authority servers needs to be specified.

This sounds like a lot of work and likely to cause camel indigestion.

However assuming the initial thesis was correct and there is demand
for this functionality (seems right to me) using a new RRTYPE for this
still sounds easier than changing the semantics of CNAME.

Perhaps the new RRTYPE could include an encoding of explicit types
that do exist to make life easier for resolvers.

Perhaps we could call the RRTYPE "*" instead of ENAME or FNAME to
avoid encouraging future GNAME and HNAME proposals :-)


Joe