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

Evan Hunt <each@isc.org> Mon, 17 September 2018 03:51 UTC

Return-Path: <each@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EED5130E23 for <dnsop@ietfa.amsl.com>; Sun, 16 Sep 2018 20:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4QdHAXtjLZg for <dnsop@ietfa.amsl.com>; Sun, 16 Sep 2018 20:51:38 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1096E129385 for <dnsop@ietf.org>; Sun, 16 Sep 2018 20:51:37 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id DBA1A3AB045; Mon, 17 Sep 2018 03:51:34 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id C27E2216C1C; Mon, 17 Sep 2018 03:51:34 +0000 (UTC)
Date: Mon, 17 Sep 2018 03:51:34 +0000
From: Evan Hunt <each@isc.org>
To: Dan York <york@isoc.org>
Cc: Mukund Sivaraman <muks@mukund.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <20180917035134.GA34900@isc.org>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <20180916095655.GA11121@jurassic> <0C475F3C-2220-4CC4-B564-47E7DF83AF6B@isoc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0C475F3C-2220-4CC4-B564-47E7DF83AF6B@isoc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oCEljAIMYYkY3ARrJt62VvX1nS8>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2018 03:51:41 -0000

It seems to me problematic to start with the statement that apex CNAME is
"deployed on the internet". Obviously it does occur, but it breaks things
when it does.  Depending on various factors such as the order in which
responses are cached, the breakage is sometimes survivable, but you can't
put a CNAME at a zone apex and expect resolvers to Just Work. Even the
ones that have hacks to work around this problem aren't always successful.

I don't see how we can responsibly declare a new standard which, if
followed, will break every prior implementation. Apex CNAME is the sort
of solution that's clear, simple, and wrong.

We're going to need another type code.

On Mon, Sep 17, 2018 at 01:18:24AM +0000, Dan York wrote:
> 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
> york@isoc.org<mailto:york@isoc.org>   +1-802-735-1624
> Jabber: york@jabber.isoc.org<mailto:york@jabber.isoc.org>  Skype: danyork   http://twitter.com/danyork
> 
> http://www.internetsociety.org/
> 
> On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman <muks@mukund.org<mailto:muks@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

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.