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

[Dan York <[e-mail]>]

Mukund,

Thank you for reviving this conversation. I was just asked last week about the status of this whole debate by someone who was seeking to set up “CNAME at apex”-style records for a variety of domains, all of which would be pointed over to links within various CDNs.

His challenge is that, for a variety of reasons not within his control, his domains are spread across several different CDNs / DNS hosting providers, all of whom do “CNAME at apex” in different ways. (And, if I recall correctly, one provider did NOT support this capability, citing RFC 1035 as their rationale.) The added complexity, and having to be sure he is doing it correctly for each of the different services, is quite frustrating and time consuming.  Meanwhile, he has communications people asking him very strongly for the ability to drop the “www” and just refer to their website addresses as “example.com<http://example.com>/<foo>”.

Hence his question to me about if this was ever going to be “fixed” by the IETF with some kind of standard.

I do think something needs to be done to standardize CNAME (or something very similar) at the apex. For the person with whom I was speaking, all of this websites are set up using various CDNs. So all he can provide is a DNS address in the CDN’s network.  He has no way to get an A or AAAA address as I understand the ANAME proposal would require.

So this is a lengthy way of saying that I would agree with moving ahead with a proposal to allow CNAME at apex, and to start to get resolvers to implement that.  I realize that updating the whole DNS infrastructure is incredibly challenging (we wrote about this with regard to crypto algorithms at https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs ).  And so this may not be something widely available for some time.  But if we could get it started, it would definitely help the many people out there trying to configure domains to point to CDNs from their apex.

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
[e-mail]<mailto:[e-mail]>   [phone]
Jabber: [e-mail]<mailto:[e-mail]>  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman <[e-mail]<mailto:[e-mail]>> wrote:

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

_______________________________________________
DNSOP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop