On Fri, Mar 08, 2019 at 12:43:18PM -0500, Michael Richardson wrote: > 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) Sometimes the management structure around a technology reflects the capabilities of the available tools. When an the configuration data for a system such as an organization's DNS is managed as a single "configuration file" or as a datastore with very coarse-grained access control (permit or deny write access to all records), it is natural to erect a moat around the system to keep the marauding hoards at bay. When on the other hand, the datastore is designed with fine-grained access control, allowing self-service registration and delegated life-cycle management for individual data elements, the administrator responsibities shrink to just keeping the system running, and they no longer stand in the way of users managing their own data. The real problem we face is that there is no pervasive user authentication technology (some organizations have Kerberos, some PKI smartcards, some just username + password with a variety of backends) and then also no common way to manage authorization. Absent a common authentication and authorization substrate and a a datamodel that tracks fine-grained resource owners and supports self-service, unsurprisingly, we end up with centrally managed systems. To make alternative management structures possible for DNS, there needs to be a datastore that facilitates delegation of responsibility for particular nodes or RRsets. This has to integrate with whatever goes for authentication and authorization in the organization in question. A few organizations invest in building such systems. Most organize around whatever tool comes from the DNS vendor, with DNS administration determined by the choice of Microsoft Active Directory, Infoblox, PowerDNS, BIND with flat-file zone data, ... The problem isn't DNS, it is that we lack a broadly applicable technology that most organizations can use to expose fine-grained access control for configuration data. -- Viktor.
