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

[Brian Dickson <[e-mail]>]

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:

_service._proto.name. 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