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 y...@isoc.org<mailto:y...@isoc.org> +1-802-735-1624 Jabber: y...@jabber.isoc.org<mailto:y...@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman <m...@mukund.org<mailto:m...@mukund.org>> 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 DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop