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

Mark Andrews <marka@isc.org> Tue, 18 September 2018 00:00 UTC

Return-Path: <marka@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 1BD77130DD1 for <dnsop@ietfa.amsl.com>; Mon, 17 Sep 2018 17:00:30 -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 ha7IITPa_D9w for <dnsop@ietfa.amsl.com>; Mon, 17 Sep 2018 17:00:27 -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 3C551130DF2 for <dnsop@ietf.org>; Mon, 17 Sep 2018 17:00:23 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 675493AB045; Tue, 18 Sep 2018 00:00:22 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4A96D160044; Tue, 18 Sep 2018 00:00:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 32DE61600A8; Tue, 18 Sep 2018 00:00:22 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UlihfFtkvKp3; Tue, 18 Sep 2018 00:00:22 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DD442160044; Tue, 18 Sep 2018 00:00:18 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20180917074327.GA13046@jurassic>
Date: Tue, 18 Sep 2018 10:00:15 +1000
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6B75E85-EC60-42BA-B941-3A700D693A46@isc.org>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <20180916095655.GA11121@jurassic> <20180917071414.7pb6elbooockzaa7@nic.fr> <20180917074327.GA13046@jurassic>
To: Mukund Sivaraman <muks@mukund.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IBBUESSHRSrHq54qmE6cdzilohY>
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: Tue, 18 Sep 2018 00:00:30 -0000


> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman <muks@mukund.org>; wrote:
> 
> Hi Stephane
> 
> On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
>> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
>> Mukund Sivaraman <muks@mukund.org>; wrote 
>> a message of 66 lines which said:
>> 
>>> 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.
>> 
>> [Algorithm deleted]
>> 
>> The difficult thing is not to specify what the new resolvers will have
>> to do, but to describe what will happen with the current
>> resolvers. What will happen when "CNAME at apex" will be deployed,
>> assuming X % of the resolvers will not be upgraded?
> 
> I fully realise what you're saying.
> 
> The suggestion is only to require support in resolvers going forward for
> CNAME co-existing with other types for now. That should not break any
> detail of how DNS is used today.
> 
> Whether CNAME + other types at apex can be used in the future would be
> an operational decision for that time of the world.
> 
> 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?

Initially none.  That however doesn’t stop a site publishing SRV records for
itself.  They do no harm being published.  As browsers and other clients deploy
add SRV support they will use them.  If you have the SRV records point to
secondary addresses you can actually track the deployment of SRV in your
client population.

e.g.

example.com AAAA 2001:0DB8::1
_http._tcp.example.com SRV 0 0 80 server.example.net
server.example.net AAAA 2001:0DB8::2

I would also expect a relatively large client population using SRV records given
the rate Firefox and Chrome browsers are upgraded.  SRV lookups work for lots of
other protocols.  SRV records also make it through firewalls and IDS today.

Sites can look at the clients that are still using legacy A/AAAA records as well
as the user agent so they know who and what to target to get SRV support added.

There is no simple / reliable way to measure the client population support for
accepting CNAME co-existance.

> * If a new RR type is introduced, what about X% of resolvers that do not
>  support it?
> 
> Although it changes current DNS protocol, AFAICT there does not seem to
> be anything badly wrong with allowing CNAME + other types at a node,
> where the CNAME is considered a fallback when the required type doesn't
> exist.

Which is a matter of opinion.  Even if support was started today it would be
a decade at least, maybe two, before you could use MX + CNAME instead of
MX + A/AAAA synthesis.  DNS servers are just not upgraded that fast.

> Repeating what the original post's author Petr said, this seems to be a
> simpler change than adding other types for similar benefit, esp. when
> hacks are already necessary to workaround the case of CNAME and other
> types co-existing that are seen in the DNS.
> 
> 		Mukund
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org