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

p vixie <> Thu, 08 November 2018 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AE4A130E61 for <>; Wed, 7 Nov 2018 18:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HIr8L5n2sOgb for <>; Wed, 7 Nov 2018 18:38:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F7F1130EAE for <>; Wed, 7 Nov 2018 18:38:30 -0800 (PST)
Received: from [] (unknown [IPv6:2001:559:8000:c9:b540:3791:a764:f341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id BBBBD892C6; Thu, 8 Nov 2018 02:38:26 +0000 (UTC)
Date: Wed, 07 Nov 2018 18:38:24 -0800
From: p vixie <>
To: Brian Dickson <>, " WG" <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Mailer: R2Mail2
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 02:38:38 -0000

If additional data is optional, so most resolvers can just pass it through, the DNS techs will say yes but the HTTP techs will say no.

----- Original Message -----
From: Brian Dickson <>
Sent: 2018-11-07 - 18:30
To: " WG" <>
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

> I'm going to start a clean, related thread, to discuss a bunch of
> questions, that I think can help with the ongoing threads.
> Rationale:
> I think many of the viewpoints some folks have are skewed by pre-existing
> familiarity with the protocol, and implementations (including browsers,
> libraries, stubs, forwarders, resolvers, and authorities, plus "specials").
> What we may be forgetting are the USERS of these systems, and the use
> cases. These matter both in terms of their diversity in their technical
> savvy, but also in terms of their respective numbers.
> We can sometimes forget that registered domains (the entry point right
> below the 'public suffix' level in the domain name system) number in the
> 100s of millions, and the user base is global.
> Starting right from that point, it's safe to say that the vast majority of
> registrants are not operating their own authority servers and editing zone
> files.
> This means that they are doing something else, and they are not all doing
> one single "something else", either; it is a mixed bag with no dominant
> "pie slice".
> Why not SRV?
> There are a number of reasons that SRV is not in widespread use, that have
> to do with the mixed bag of ways those 100s of millions of registrants
> operate their domains.
> Even if registrants use systems that expose SRV to them to configure, as an
> RRtype, the other parts of SRV are not at all novice-friendly. From the
> wikipedia page:
> TTL class SRV priority weight port target
> This isn't at all friendly. The alternative is to put all of the above into
> some kind of UI. But again, this puts several more roadblocks on uptake *by
> users*. Regardless of the interface, the values need to be supplied, and
> the input needs to be validated, with the ability for the user to
> understand error messages and fix the input. There is no short cut for
> understanding the values, and knowing about _service and _proto. If the
> user doesn't get it right the first time, they are very likely to give up,
> since there are so many variables. For HTTP as a use case, it is far too
> complex.
> In other words, SRV is really only suitable for a tiny fraction of the
> registrants. For them, there's still a learning curve, but they have a need
> that only SRV can fill, and an incentive to do so. Those are typically
> enterprises, large institutions, entities with actual IT staff.
> Yes, resolvers and authority software do SRV already, that isn't the point.
> If you are an SRV proponent, here's my recommendation: Find someone you are
> acquainted with, who doesn't have any DNS familiarity, show them CNAME and
> SRV, and ask them for their opinions. Please.
> Why is CNAME so abundantly used?
> If we look at CNAME, it is much simpler, and probably one of the first
> things anyone doing DNS every plays with.
> (But even then, it isn't completely trivial, given the trailing dot problem
> that pretty much everyone gets wrong at some point in their DNS career.)
> Even for a novice: there is only one "variable", and lots of information
> and advice on CNAMEs can be found online. The learning curve is gentle and
> short.
> Why not CNAME?
> The secondary issue with CNAME isn't just the apex issue, it is the
> non-coexistence issue (of which apex is merely the poster child).
> Why a new RRtype?
> Here's the TL;DR: on these issues, IMNSHO: browser vendors won't do stuff
> that isn't really in widespread use, even if it is possibly easy to
> implement. SRV isn't ever going to be truly widespread, as a percentage of
> domains.
> We want a solution that is easy to deploy, easy to understand, easy to use,
> SOLVES THE COEXISTENCE PROBLEM, and doesn't change the primary rules on
> "stupid DNS tricks", i.e. that the tricks are client-oriented by way of the
> resolver (or possibly client-subnet).
> This leads to the only logical outcome that is implementable, doesn't
> require more than five minutes for any user to understand, doesn't require
> (but supports optional) changes to resolvers, doesn't require any change to
> authority serving beyond new RRtype(s), and thus can/will get brower
> support (simply by the numbers): HTTP.
> Why should HTTP be so simple?
> Because it is simple to use.
> It looks just like a CNAME.
> It can chain with CNAMEs and DNAMEs.
> It works with stupid DNS tricks.
> It gets the job done.
> It is a common denominator.
> That is a feature, not a bug.
> Why service-specific?
> As Ray points out, MX is already there as a service-specic RRtype.
> Other service-specific RRtypes may be needed, and new RRtypes are easy to
> get now.
> (Perhaps we can anticipate what some of those are, and include those in the
> draft?)
> Brian
> _______________________________________________
> DNSOP mailing list