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

[Mukund Sivaraman <[e-mail]>]

Hi Petr

Apologies for the delayed reply.

On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
> Hello dnsop,
> 
> beware, material in this e-mail might cause your head to explode :-)
> 
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>   is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>   already have code to cope with the "impossible" case of CNAME at the
>   apex and deal with it in ways which do not break stuff on resolver
>   side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
>   apex.
> - There are CDNs etc. which allow users to create CNAME at apex
>   no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
> 
> 
> Take a deep breath!
> 
> 
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
> 
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for
> future. I.e. adding ANAME will just increase complexity because CNAME at
> apex will be there for a long time (if not forever).
> 
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through
> current hacks for CNAME at apex) instead of inventing new things like ANAME
> (or whatever else).
> 
> Opinions? Tomatoes? Can it work? If not, why not?

To me it seems it can work, and it sounds like a good idea. To relax DNS
protocol for CNAME to co-exist with other RR types, we'd need resolver
support, authoritive support and a time when it is practially usable.

----

Adding resolver support (to resolvers that don't have it, i.e., vs. RFC
1035) does not appear to break current DNS, i.e., it can be proposed
now.

1. When a resolver looks up a RR type in cache, and finds any positive
type match, it serves it.

2. If it does not find a positive type match, but finds a CNAME, it
looks for a negative cache entry for that RR type.

2.a. If a negative cache entry is found (or if it can synthesize one),
it returns/follows the CNAME chain.

2.b. If no negative cache entry is found (and it cannot synthesize one),
it starts a fetch for that type from upstream.

2.b.i. If the fetch returns a CNAME or NODATA, it means that the type
does not co-exist with CNAME in that node in the auth zone. The resolver
adds a negative cache entry for the type for the TTL of the returned
CNAME (or from SOA fields) to the cache, and returns/follows the CNAME
chain.

2.b.ii. If the fetch returns the type, it means that the type may
co-exist with the CNAME. The resolver adds a positive cache entry for
the type and returns the fetched answer.

2.b.iii. If the fetch returns NXDOMAIN, it overwrites the cache for that
node with a negative cache entry.

----

Adding authoriative support would mean relaxing checks and allowing
CNAME to co-exist with other types except non-apex NS (parent of zone
cut), and perhaps allow CNAME and DNAME to co-exist too.

For operators to be able to use it, they would need resolver support to
be available everywhere. I guess nothing stops a draft requiring
resolvers to implement support for it now.

So +1.

		Mukund