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

Evan Hunt <> Sat, 23 June 2018 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEEAB130DD4 for <>; Fri, 22 Jun 2018 18:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XQXlUJKn3ANM for <>; Fri, 22 Jun 2018 18:45:03 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1A81130DCD for <>; Fri, 22 Jun 2018 18:45:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 941823AB041; Sat, 23 Jun 2018 01:45:03 +0000 (UTC)
Received: by (Postfix, from userid 10292) id 7A899216C1C; Sat, 23 Jun 2018 01:45:03 +0000 (UTC)
Date: Sat, 23 Jun 2018 01:45:03 +0000
From: Evan Hunt <>
To: John R Levine <>
Message-ID: <>
References: <> <20180619190213.B76962846E19@ary.qy> <> <alpine.OSX.2.21.1806221517590.29829@ary.qy> <> <alpine.OSX.2.21.1806222114230.31259@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.21.1806222114230.31259@ary.qy>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Jun 2018 01:45:06 -0000

On Fri, Jun 22, 2018 at 09:18:25PM -0400, John R Levine wrote:
> Like I said, it's a disctinction without a difference.

The difference is implememtation complexity, which maybe isn't of concern
to you but has been of concern to some people who argued with me about
ANAME on this basis early on.

You *don't* have to implement a full resolver inside your auth server to
get ANAME to work. That's all I'm trying to make clear.

Your point about having to deal with recursion failures is entirely valid.
It's irreducibly a hack, but I'm still pretty sure a different rrtype than
CNAME will be needed to get anything like this to work reliably.

(And, realistically, it isn't going to be SRV; it's going to have to be
something that browsers get for free just by sending address queries, since
that's all they're willing to do.  A related idea that's occurred to me is
an EDNS option that could be included with a query for, which
says "this query originated from a _http._tcp application, so do me a favor
and check for SRV while you're at it, 'k?"  But I'm pretty well convinced
at this point that no browser vendor would ever lift a finger to use that
information no matter how easy we made it for them.  *All* of the
finger-lifting will have to be done in the resolver.)

Evan Hunt --
Internet Systems Consortium, Inc.