This area is for discussion of the conceptual model to be used for the command tool and other possible interfaces. It will talk about the issues at a higher level and will have pages for more detailed discussions for the aspects.

Extensibility and Modularity

One of the primary goals of BIND 10 was to make it modular and extensible in ways that BIND 9 was not. It would only make sense to make sense that the same constraints me followed for the command tool. Since this is somewhat vague, this will attempt to be more explicit for what is meant by extensible and modular.

  • forklift modularity: the ability to replace defined sections of the command tool without recompiling.

A simple one is that database access should be through an interface that allows the type of server and much of the schema details to be hidden from the upper levels.

A more complex model is for someone to change the auth local data generators with ones that have different functionality to match a different auth server module.

  • functional APIs: allowing people to use components from the command tool to build their own tools

An example of this is an API and library that understands how to connect and authenticate with a BIND 10 server.

  • data extensibility

There are two aspects to data extensibility. One relates to changes to the data managed in the server and the other relates to data in the command tool.

If one looks at the server data extensibility, a good example I often use is a new wombat resource record that has 3 fields. Rather than having to replace the entire data generator and display systems to handle this, it would be far better to allow this kind of mechanism to be added to the command tool as an extension.

Management side extensibility would be more involved with the higher level structures used to help people control their servers. Extensions for things like provisioning records or trouble tickets are simple examples of this.

  • capability extension

The ability to add new functions to the command tool in an organized way is both challenging and powerful. There are many things that can be done in unique ways when connected to the servers directly and having added data from the management data model at hand.

One example of this would be a validator to confirm that all the configuration around a zone delegation is correct, including the zone transfers. A different example would be the generating of custom reports that combined server and management data into something more useful to the organization.

Data abstraction above the protocol level

The DNS specifications and data model are designed to simply and exactly define the transfer of data needed in many internet actions. This model does not reflect the way organizations think of the things that need DNS data related to it. One of the reasons that managing DNS environments is hard is that we require everyone to learn the protocol level data model and use a combination of user tools and mental translation to get from the data that the organizatoin has to the data that the server needs.

To address this issue, we are proposing that there be a management data model that is different than the server data model. The server data model needs to provide the specific information needed to feed the DNS protocol and does not want to be burdened by either the complexity or variability of higher level models. This implies that there is a translation of higher level model constructs into the lower level structures needed by the server components. This is part of the management side.

Data vs. metadata

If one says that data is the stuff that DNS provides to support actions by other programs wishing to communicate on the internet, some interesting things come about. All of the components related to zones and zone cuts are really protocol defined metadata for navigating a hierarchy of servers. The same can be said for all the information related to secure DNS.

A second level of metadata is all the information that an organization has about things that translate into DNS data and metadata. Things like the fact that a series of A records are virtual hosts of a given machine and if the machine main address changes, all the virtual host addresses need to change as well. Another type of metadata is related to operations, so a given change was made by some person in response to some work request which is tracked elsewhere.

Management data models

BIND 9 and DHCP 4 have very different management data models. BIND has a fixed set of data files, one per zone and a single config file (but supports includes.) There is no concept of generating data within the config, that all is expected to happen outside the server. DHCP has gone almost the exact opposite route, where there is no separate data files, and the server itself processes often complex generation tasks to reach a running internal state.

Though some of this can be seen as the result of the differences in usage of the two systems, it also reflects different choices by the initial designers on how to approach the problem. It is not clear that either was designed from the needs of current customers.

To build a management data model that can encompass the needs of both of these is a challenge, but others have done so with varying degrees of success. As this is explored, one must keep in mind that any management data model should be able to be replaced with another, as long as a companion translation to the low level data required by the server is also included.

Last modified 8 years ago Last modified on Sep 20, 2010, 7:37:19 PM