Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

Tony Finch <> Thu, 08 November 2018 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49F2128BCC for <>; Thu, 8 Nov 2018 10:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LSoKRcf4XOVg for <>; Thu, 8 Nov 2018 10:27:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02FA012426A for <>; Thu, 8 Nov 2018 10:27:05 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:47602) by ( []:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gKp1C-000uDj-Lg (Exim 4.91) (return-path <>); Thu, 08 Nov 2018 18:27:02 +0000
Date: Thu, 08 Nov 2018 18:27:02 +0000
From: Tony Finch <>
To: Ray Bellis <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
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, 08 Nov 2018 18:27:08 -0000

Ray Bellis <> wrote:
> On 08/11/2018 11:47, Dan York wrote:
> > For that reason, wouldn't all the resolvers (or at least an extremely high
> > %) need to be upgraded to support the new record?
> They don't _have_ to be, but performance is improved when they are (since only
> an upgraded resolver will include the A and AAAA answers in the additional
> section).
> The critical path is the browsers, since none of this works unless they
> start looking up the HTTP record.
> As a transition mechanism, site operators would still need to publish their
> existing A and AAAA records by whatever means they currently do (even if
> that's e.g. a CNAME flattening on the authority server).

The transition mechanism is really important if zone publishers are going
to use HTTP records. It needs to be automated and invisible to the web
site admin. If you require people to provide both a target hostname and
the corresponding addresses, you are making it too hard. You aren't
removing the friction caused by the restrictions on CNAMEs.

At the moment the options for setting up 3rd party hosting are:

  * Just use address records. Lots of places prefer this because it
    always works, at the cost of less flexible static server setup.

  * Use a CNAME for www and address records for the bare domain. Maybe the
    address records refer to a server that is more limited in some way
    than the CNAME target (no geoIP, just a redirector, ...)

HTTP RRs risk adding a third option, where the web provider has to have
documentation asking whether the DNS provider supports HTTP RRs and if so
the site admin needs both these addresses and this hostname. And the
addresses can't refer to a redirector, so this thord option opens a new
trap for the unwary.

What I would like is to eliminate the wrong choices on the DNS provider
side of things, so that the web site admin can provide a target hostname
which will work on any name, just like they can with address records.

f.anthony.n.finch  <>
Fitzroy, Sole: Cyclonic 5 to 7, becoming southerly or southwesterly 7 to
severe gale 9. Very rough or high. Rain or showers. Good, occasionally poor.