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

Jared Mauch <> Tue, 19 June 2018 15:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 750B8126F72 for <>; Tue, 19 Jun 2018 08:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJHs69TsVbZ2 for <>; Tue, 19 Jun 2018 08:40:27 -0700 (PDT)
Received: from ( [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40A06130DEC for <>; Tue, 19 Jun 2018 08:40:27 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 20BEE54077C; Tue, 19 Jun 2018 11:40:25 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Jared Mauch <>
In-Reply-To: <>
Date: Tue, 19 Jun 2018 11:40:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Ray Bellis <>
X-Mailer: Apple Mail (2.3445.6.18)
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: Tue, 19 Jun 2018 15:40:30 -0000

> On Jun 19, 2018, at 11:24 AM, Ray Bellis <> wrote:
> On 19/06/2018 15:43, tjw ietf wrote:
>> I find it personally appalling we can spend so many cycles injecting
>> dns into http but we can’t be bothered to fix what end users want.
> It's the HTTP folks that are putting most of those cycles into DNS into
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue.   CNAME was *never* the right answer for doing application
> level indirection in HTTP space.

Throw some shade at SMTP as well, if I send mail to and that pointed to it would end up as in the messages :-)

Part of it is just the human nature of how we debug things.  I can speak HTTP because it was easy to type telnet localhost 80.  These days I have to do the same thing but with openssl s_client etc.. 

If these methods to debug weren’t so hard, it would have gone much further to helping.  Developers/users want easy debugging steps and what we give them is things like the ednscomp tool, which is technically awesome but not very user friendly.  Instead of doing a dig on the port test tool, it’s much easier to visit instead.  I also may not have dig on my phone.. (ok, well I do).

I think a lot can be learned from how Apple (as an example) made simpler APIs to do connections vs doing  gethostbyname()^wgetaddrinfo().  It makes it easier to build tools if you don’t have to learn how to do all these things.  I really like Unix, the simplicity of many calls in C, but sometimes hiding the internal layers is what’s needed.  This is why is a thing.

This is why folks are doing what tjw says, “meh, go to route53 because it does what I expect”.

This doesn’t mean the internals aren’t important, but many application developers and end-users can’t be expected to know/care about how a CNAME at apex differs from an A record w/ redirector.

One thing that SMTP got right was MX records, so it’s easier to say “go over here”.  While I’m sure someone will say that HTTP should have it’s own (eg: SRV) but the barn door is still open, etc..

- jared