Michael and Keith, A few additional comments... --On Friday, March 8, 2019 12:43 -0500 Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: > > I am top-quoting a bit to introduce. I started a new thread > and severed the references/in-reply-to chain from my message > about /.well-known. > > Keith makes what I first felt was a very controversial and > unsupportable claim about DNS vs services. DNS has been > widely successful at the Internet scale. On the other hand, I > happened to be in the offices of a ccTLD this week doing some > non-DNS work. I happened to be within earshot of a support > person answering the same question about why the ccTLD > couldn't fix the caller's web site/domain... So maybe it's > not so succesful if the complex > web-server/DNS-server/registrar/ccTLD relationship is still > opaque to so many. I'm actually a little surprised that the ccTLD support desk got the call. My experience is that users faced with a problem in that complex space will call whomever they think of a "Internet", often in terms of who they paid a bill to yet. That usually points the finger at the user's ISP. It might point to the ccTLD help desk if the user had found the ISP seriously unhelpful and/or good at excuses to not help (not hard, at least in my vicinity, to find ISPs who behave like that) and the TLD operator very helpful about other things (common in my experience with many ccTLDs who still think their job is to serve the populations in their countries; much more rare with those ccTLDs whose motivation is closer to making a fast buck on name sales). In any event, as you effectively point out below, not a problem that is going to be solved by technology. > Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: >> The last thing we need is even more use of DNS[*] to locate >> services. DNS is too often out of sync with reality as it is. >> A really unfortunate consequence of using DNS for service >> discovery results from a tendency to centralize DNS >> administration within an organization, even if (as is often >> the case) hosts and applications are administered in a >> distributed fashion. In any organization large enough to have >> an administrative hierarchy, this is a profoundly >> dysfunctional arrangement. It gives the central DNS >> administration a huge amount of ability to break things >> (whether due to incompetence, poor communication, or petty >> turf wars - usually some of all of these), whereas the very >> nature of such an organization makes it almost impossible for >> them to get things right. Using DNS for SD in a widespread >> fashion only exacerbates the problem. > It seems that you are arguing for a technology fix to a > management problem. (the "why we can't have nice things" > lament comes to mind) > > I'm not saying any of your reasons are wrong! I have observed > some of all of what you point to. It seems therefore that > any proposed technological fix needs to do a clear analysis of > the management issues around IT (not just specifically around > DNS). Please include "customer support" and related issues along with "management issues". Good customer support is hard and often expensive and many organizations have incentives to blow it off to the extent possible. The technology then gets blamed whether it could have been designed in a way that would mitigate the problems or not. > I know that the initial DNS-SD effort was thought to be going > to be just mDNS with proxies at the gateways. We didn't go > there: are you thinking about something like that? >> Part of the problem is the too-common notion that there are >> "public" names and "local" names, meaning that the DNS name >> space is polluted with names >> that aren't in the hierarchy. A separate, though related, >> problem is that there's no architected way to distinguish one >> from the other. > >> [*] By "DNS" here I mean the naming hierarchy, which is of >> course related to the data model. > > I agree with your description above. That problem is further aggravated by the observation that we have two uses of "public" in very wide use wrt the DNS. One has to do with names that are accessible to substantially everyone on the Internet without the need for special configuration or access rights (probably that is "public" as distinct from "local", but there may be other distinctions). The other distinguishes within the public DNS (as described in the previous sentence) between zones from which names are delegated to parties not directly related to the zone administration, usually involving the exchange of money and zones that are populated from within enterprises, organizations, etc. The observation that the latter definition can get a little fuzzy and may involve edge cases makes things harder still. Again, not a technology problem although it is often our feet (and those of the support desk personnel) that get hit by the bullets. best, john
