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
