Brian, > On Nov 8, 2018, at 9:30 AM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > I'm going to start a clean, related thread, to discuss a bunch of questions, > that I think can help with the ongoing threads.
DY> Thank you for doing so. > 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. DY> This was something I was trying to capture in https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view <https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view> - I definitely welcome comments, feedback and text from others. > 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. DY> Thomas Peterson did some great data gathering on this point. From a previous message: > I took the Alexa top 1 million websites and queried for A* and CNAME against > the www records for the top 10 000 domains. What I found is that > approximately 44% returned CNAME records, 56% returning A records. (his code > is at https://gist.github.com/thpts/eb5cec361867170a0ffd6ede136c6649 > <https://gist.github.com/thpts/eb5cec361867170a0ffd6ede136c6649> ) DY> I played with his data from the top 10K Alexa users and the majority of those CNAMEs looked like they were going to CDNs of different sorts. Plus, a sizable portion of the A* records are probably cases where the CDNs are also DNS hosting operators and so they are returning to the clients the A* records *after* doing their CDN lookups to point people to the best CDN edge server. (Using one of the various DNS techniques here - or other database techniques.) > 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 <http://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. DY> Additionally, *at the current time*, the user is typically told by their CDN provider to just "point your domain to <long-CDN-address>" under the assumption that the user is doing a CNAME. The CDN wants to keep it as simple as possible to reduce the possibility of user errors entering the info. DY> This is not to say the CDN couldn't tell the user the other info for priority, weight, port, etc. They could. And I am sure they *would* if that was the only or best way to configure the records. DY> But from a technical support point of view, the fewer pieces of info you have to give to the end user, the fewer chances are that they will screw it up when entering the data with the DNS operator. Which means happier customers and fewer technical support calls. DY> The *design* of SRV offers great flexibility and power. But with greater power comes greater deployment configuration issues. > 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. +1 > > 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. DY> Yes. > 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). DY> Agreed. > 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): DY> This to me is a good design statement. > 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. DY> A good summary, although the counterpoint I can see from the SRV/URI side is that those records are already out there and supported in the existing DNS infrastructure. DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still massively distributed and decentralized (even though we do have ongoing centralization/consolidation), getting a new RRTYPE deployed means: - upgrading all the authoritative servers to support the new RRTYPE - upgrading all the *provisioning software* at the thousands of DNS registries, DNS registrars, DNS hosting operators to support the new RRTYPE - upgrading the *millions* of recursive resolvers to know what to do they receive the new RRTYPE in a query response DY> A group of us wrote about these issues in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06 <https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06> and while that was talking about deploying new DNSSEC crypto algorithms, the situation is very similar for new RRTYPEs. DY> Which is NOT to say we should NOT do a new RRTYPE. I can see many of the benefits of HTTP. DY> But it is to say that deployment will take a lllllllllooooooooooooonnnnnnnnnnnnnggggggggggggg time. DY> Which does means we do need to get started NOW ... but it also means that it will be a significant number of years before it is widely available and deployed. (But if we don't start, of course, it will never happen.) DY> (And even if were to decide to change the behavior of CNAME, for instance, to allow it to co-exist at the apex, it would take a long time for that support to roll out into the millions of recursive resolvers.) DY> I'm just pointing out that the counter-argument FOR the use of SRV/URI is that they are out there now and would not have the same significant deployment lag. (But they still have the same user deployment issues I mentioned above.) > 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?) DY> Let's keep any drafts simple and focused on a single RRTYPE. We need RFCs to be as easy as possible for someone to *understand* and then *implement*. Thanks for bringing this all together, Dan -- Dan York Director, Content & Web Strategy, Internet Society y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
