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

p vixie <paul@redbarn.org> Thu, 08 November 2018 02:38 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4A130E61 for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 18:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIr8L5n2sOgb for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 18:38:30 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7F1130EAE for <dnsop@ietf.org>; Wed, 7 Nov 2018 18:38:30 -0800 (PST)
Received: from [100.100.216.117] (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 family.redbarn.org (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 <paul@redbarn.org>
To: Brian Dickson <brian.peter.dickson@gmail.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <90611d9.7bf77335.166f12f5c66@redbarn.org>
In-Reply-To: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com>
References: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Mailer: R2Mail2
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/maAVKbp-nDNXybXExjDsCJ_0aSU>
Subject: Re: [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: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 <brian.peter.dickson@gmail.com>
Sent: 2018-11-07 - 18:30
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
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:
> 
> _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
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop