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.dick...@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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
