Re: [DNSOP] Minimum viable ANAME

Mukund Sivaraman <> Thu, 20 September 2018 06:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3518130DC4 for <>; Wed, 19 Sep 2018 23:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ELa59dC_RZ6T for <>; Wed, 19 Sep 2018 23:13:48 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:140:644b::225]) by (Postfix) with ESMTP id A23DB12872C for <>; Wed, 19 Sep 2018 23:13:48 -0700 (PDT)
Received: from jurassic (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2407B32C0720; Thu, 20 Sep 2018 06:13:45 +0000 (UTC)
Date: Thu, 20 Sep 2018 11:43:43 +0530
From: Mukund Sivaraman <>
To: Tony Finch <>
Cc: John Levine <>,
Message-ID: <20180920061343.GA754@jurassic>
References: <20180919201401.8E0C220051382A@ary.qy> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <>
Subject: Re: [DNSOP] Minimum viable ANAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Sep 2018 06:13:51 -0000

Hi Tony

On Wed, Sep 19, 2018 at 10:08:45PM +0100, Tony Finch wrote:
> * minimal ANAME can be deployed unilaterally on the provisioning side
> * 20 years ago and similar features are widely available (you are
> * ahead of me on this one, John!); if resolvers implement it there
> * will be useful amounts of deployed support within a few years
> * browser-friendly SRV replacement: two years to standardization;
> * another two years watching caniuse before we can maybe think about
> * not copying A records around; even more years before it becomes as
> * portable on the provisioning side as ANAME is now
> * fix CNAME, at least 10 years

All these have similar adoption rate risks. Mark has a point that it's
more difficult to check for the last one.

There are orders of magnitude fewer resolver instances to upgrade than
HTTP user agents (popular web browsers aren't the only HTTP clients).

I don't follow how ANAME, if resolvers have to implement it, can be
deployed within a few years, and fixing CNAME takes at least 10 years.
They both involve resolver changes.

SRV is most elegant. IMO we should push the resolver-side CNAME handling
change through so one day in the future it is available widely.