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

[p vixie <[e-mail]>]

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 <[e-mail]>
Sent: 2018-11-07 - 18:30
To: "[e-mail] WG" <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop