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

Mukund Sivaraman <muks@mukund.org> Mon, 17 September 2018 16:52 UTC

Return-Path: <muks@mukund.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 4645E130E9D for <dnsop@ietfa.amsl.com>; Mon, 17 Sep 2018 09:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 ficHj3bo6_6J for <dnsop@ietfa.amsl.com>; Mon, 17 Sep 2018 09:52:21 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4A130E81 for <dnsop@ietf.org>; Mon, 17 Sep 2018 09:52:21 -0700 (PDT)
Received: from jurassic (unknown [27.5.172.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id A4D2932C0727; Mon, 17 Sep 2018 16:52:18 +0000 (UTC)
Date: Mon, 17 Sep 2018 22:22:15 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Evan Hunt <each@isc.org>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <20180917165214.GA28950@jurassic>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <20180916095655.GA11121@jurassic> <20180917071414.7pb6elbooockzaa7@nic.fr> <20180917074327.GA13046@jurassic> <20180917161124.GA39810@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180917161124.GA39810@isc.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qKyBsNRLv3Q4DTemMqlhv9GQHZE>
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 16:52:26 -0000

Hi Evan

On Mon, Sep 17, 2018 at 04:11:24PM +0000, Evan Hunt wrote:
> On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> > Similar things can be said of other proposals.
> > 
> > * If SRV for HTTP is brought into use, what about X% of user agents that
> >   don't have support for it?
> > 
> > * If a new RR type is introduced, what about X% of resolvers that do not
> >   support it?
> 
> They're no worse off than they already were. The old methods would still
> work just as well or badly as they do today.
> 
> If apex CNAME were declared legitimate, then people using legacy resolvers
> *would* be worse off than they are now.

This would not be a decision for people using legacy resolvers to make -
it would be for the zone administrator to decide whether to co-exist
CNAME with other types depending on market share of resolver support.
Then, it wouldn't mean resolvers would break for all other zones - they
could break for this particular zone.

We see this happening in other technologies where new things are
introduced. E.g., many popular websites use SVG, canvas, HTML5 elements,
etc. with no fallback for old browsers which still exist.

(a) Initially, very few web browser instances supported the new
features.

(b) At some point, a majority of web browser instances supported it.

(c) At some point, the *web developer* (not the browser user) decides
that they will now use the new feature in their website, even though it
would not work on a percentage of web browser instances in the wild. It
is a calculated decision for that individual website's case (in the DNS
world, it is for that particular zone and the zone administrator's
choice depending on the risk).

No old behavior is removed as long as zone admins stick to the current
way. Current zones will work as before. And it is a resolver-specific
requirement to support CNAMES with other types for now - it doesn't
require authoritative use, without checking if the new feature is
supported in the market.

The example about SRV has just as much risk. What about browsers that
don't support it? Whether to co-exist CNAME with MX has similar risk as
whether to depend on a new SRV's support in web browsers.

The ANAME draft seemed to beat this, but it got quite complicated.

		Mukund