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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 08 November 2018 02:31 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E120D130E07 for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 18:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nTaqbkGKmsjS for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 18:30:58 -0800 (PST)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEC4130DE9 for <dnsop@ietf.org>; Wed, 7 Nov 2018 18:30:58 -0800 (PST)
Received: by mail-vs1-xe36.google.com with SMTP id x1so4374428vsc.10 for <dnsop@ietf.org>; Wed, 07 Nov 2018 18:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=I3Nam/jVLnd4XO7b8nxOWyV3GRySRF4wPJ2yvSy1qso=; b=IGo2dBRf2QCMln8kx/a+Uy9n9csjhs+OvXMc9yZKqkXO+n4i5FghxuedbY0SNj3GPS jUt1e9MWWfZ6L+tu/6aJiEN1KLxCRq702tTA7rI5x7UON82Q4sRf+1K76VDw6FeO/hx4 KROS20c4w7eaUltyRihv9fnYfXroA+iS19U0XAnPnXCc07IhRJOEMscj6Y/tH56g1xri QtMLFuKedfgnFEAmNV3dbbe53P73jO0FrdacMj4uzu+EsmFQM7TqmM523KFOUpYf7BZo fO1k1+GumNubB8AuS8ipfMh1t5XIhb1wkkfxvO/fm2iljEOh7PWqotUNzZsUryeHOD0R F73w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=I3Nam/jVLnd4XO7b8nxOWyV3GRySRF4wPJ2yvSy1qso=; b=bZOIV/ga0pSaLJByFJ/EtW8Sh1IycTJ8XHI+AwCt/WED01PSYDXdgnZCT6JpQDkGBH CWozhitbEh3T2jBj39WtdcuFaT72Br31v4eR5PNLk8wjGaS5pN3D2ACmzfF9P/VnQvtg AMGRBvaBEMIyYdriXx4aR4To4T+c34oZ1lIcdP9joAMcrhFCXpuLk9vjNP4pvJiTzEeV FkklRHO3zWRRPyZ51nMTouTk9f41YIzdK9KJGvhZB+TGjnA8YF3pqMqovUzEGZi93NYC MN/3yLQcLi9A53meIta1fMzT3NPpiK9K/jlwBRi2zNLIEDhjmIpdsV7zemUNQAhFsSSA yI1g==
X-Gm-Message-State: AGRZ1gJm25l+ph9+AHP0dVWfmeEE+bJZl7fBgX9pMsTXeVdotrayUqBT TkhL2ZHcT6x039/xWp0PM9V3C3UwiyAId4AS3HbdYBv1q8E=
X-Google-Smtp-Source: AJdET5ehvq+gB1ILuZI5z2V85g8s7vIZt37rSIAFRqWMkacZR1e2yNyB8fno/IHlrhX8WNVJ/vdkmgyQthC+B2Wkt74=
X-Received: by 2002:a67:7b0a:: with SMTP id w10mr1173345vsc.5.1541644257188; Wed, 07 Nov 2018 18:30:57 -0800 (PST)
MIME-Version: 1.0
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 8 Nov 2018 09:30:44 +0700
Message-ID: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051e33f057a1e0694"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lC2ZW0lwME-RrvkpntRpJzWrLuc>
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 02:31:01 -0000

I'm going to start a clean, related thread, to discuss a bunch of
questions, that I think can help with the ongoing threads.

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

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

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

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

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