Introduction

The purpose of this document is to describe how DNS management can be implemented under Ganymede. It introduces the general concepts behind both Ganymede and DNS, and explains some of the issues involved with representing DNS information in the Ganymede environment. It then describes the translation between the DNS and the Ganymede representations of data, and explains how and why XML is used as an intermediary transport layer. Finally, it examines some of the external scripts and tools that are used to move data back and forth between DNS and Ganymede.

What is Ganymede?

Ganymede is a network directory management system. It provides a means to centrally manage information that is to be distributed throughout a network by means of services such as NIS, LDAP, and DNS. Written in Java, it consists of a graphical client and a server with a built-in database. The server provides support for multiple concurrent users to view and edit the database without interfering with each other.

Information is stored in the database as objects. All user interactions with these objects are controlled by a flexible permissions model built into Ganymede. This model is designed to allow varying degrees of privilege to be assigned to different administrative groups and individuals within those groups. Thus, a group of administrators can share control over a set of objects, and can delegate control over a subset of those objects to another group or individual.

Every object in the database is an instance of a given object type. These object types are defined in a schema. A schema basically describes each object type in terms of a series of data fields along with the data types allowed in each field. Ganymede provides a graphical schema editor for developing and editing schema definitions. In addition, the behavior of the server when acting on objects can be modified by custom plug-ins written in Java. It is the ability to utilize custom schema definitions and plug-in code that gives Ganymede much of its power.

Before describing in detail the creation of a DNS schema, we'll briefly review DNS in general. We can then see what the development of such a schema will entail, and can provide a few scenarios of how DNS management might work under this schema.

What is DNS?

DNS stands for Domain Name System. It is essentially a database of information about computers connected to the internet, distributed across special servers running all over the Internet. This means that control and maintenance of individual portions of the database can be handled at a local level while information in the database can be accessed by the internet community as a whole. It is the information in this database that, given a machine's name, allows its Internet (IP) address to be retrieved so that it can be communicated with on the net.

The DNS database structure can be pictured as an inverted tree, with a '.' labeling the root node. Each subtree of the root is called a Domain, and each domain can further be divided into subdomains. The root of each subtree is given an appropriate label. For example, the initial level consists of the familiar labels com, edu, net, etc. The domain name is then just the sequence of node labels from a given subtree root to the main root, with a '.' between each label. The domain name of a leaf node represents an index into the DNS database which points to information about a specific computer, including its Internet address.

Each domain or subdomain can be administered by a different organization, responsible for only its small piece of the database. Divided in this manner, data inconsistencies can be kept to a minimum and the administrative load on any one group is greatly reduced. Name Servers are the means by which this locally managed information reaches the rest of the internet. Name servers are programs that can accept requests for information about a computer and return the information if they know it, or direct the requesting agent to another name server that might have the desired data if they don't.

The information that the name servers provide is stored locally in text files called zone files (the term Zone refers to a subdomain that that has been delegated.) These are the files which local network administrators maintain and update to keep the information for their portion of the DNS database accurate. The zone files consist of entries called Resource Records, which provide the data associated with domain names. The A resource record, for example, provides the Internet address of a given machine name, while the NS record specifies a name server for a given domain.

When the information contained within the resource records is correct, the DNS mechanism operates smoothly. Unfortunately, when the number of records is larger than a handful, it is difficult to ensure that the hand-edited zone files are error-free. It is because of the perils of editing large (or even small) zone files by hand that tools have been developed which can automate the updates, providing consistency checking and minimizing human error. Ganymede has been designed, in part, to provide for such assistance.

How is DNS data represented in Ganymede?

As mentioned previously, everything in the Ganymede database is an object, and access to these objects is controlled through a permissions mechanism. In order to represent data from the zone files in the database, there must be some mapping of resource records to Ganymede objects. The question is how to accurately generate this mapping in such a way that the distributed management mechanisms already in place in the server can be best utilized. One solution is to represent resource record information using the following abstractions: Zone, System, and IP Network.

Zone
The Zone object type captures all the information specific to a given delegated subdomain. This includes the identity of the name servers and the configuration options for that zone.

System
The System object type is an abstraction that allows us to pull together all of the data from a set of resource records for a given computer. It contains information such as the name of a machine, the zone in which it exists, interfaces, aliases, mail exchangers, etc.

IP Network
The IP Network object type is basically a representation of a given internet subnetwork, including the IP addresses available on that network.

By conceptualizing the structure of DNS information in terms of these object types, the line-by-line textual representation of resource records in the zone files can be transformed into objects that can be stored and managed within Ganymede.

DNS Management using Ganymede

Ganymede has several features which make it suitable for managing DNS:

One of the features that makes it special, though, is the fine granularity with which administrative responsibility can be delegated. Delegation can occur not only of zones, but also of specific sub-portions of a given zone.

The problem with manual zone file administration is that the zone (file) is the unit of delegation; if a user can edit the file at all, then that user can edit everything in the file. There is no easy way to allow editing of some systems in a zone while denying access to the other systems or zone-specific data in the same file. Ganymede avoids this "all-or-none" issue through the interaction of its built-in permissions model and the object types described above. There is no longer any need to create and delegate a new subdomain when all that's needed is access to a subset of the existing domain data. The resulting flexibility is illustrated by the following examples.

Domain Delegation
Ganymede can make domain delegation easy. The administrator of the original domain creates a new Zone object to represent the delegated subdomain and assigns ownership of it to a user. Once the subdomain has been configured, all additional domain management can then be handled by that user. The permissions system in Ganymede ensures that the user can only edit data within the delegated subdomain, thereby insulating all other domains from any erroneous or unauthorized changes. This would be useful, for example, to an Internet Service Provider (ISP) who wants to delegate administration of a subdomain to a customer.

System Delegation
Ganymede also allows delegation of systems. In this way, individual systems or groups of systems can be managed by users or administrative groups who wouldn't normally be able to edit zone data. Thus, while an organization might want to manage an actual zone itself, it can delegate administration of the systems in that zone to departments within the organization. The departments could then change IP addresses, add interfaces, and maintain up-to-date records (such as where the machine is located and who's its primary user) for any of their own systems. They no longer need access to the whole zone just to edit or delete system information. Again, the permissions model ensures that each department can only edit the systems belonging to that department.

IP Network Delegation
In addition to domains and systems, Ganymede can allow delegation of IP Networks. Like with system delegation, this lets an organization manage a zone while delegating control of a specific portion of that zone to others. In this case, the organization allocates ranges of IP addresses to different departments and lets those departments assign the addresses to their machines as they see fit. Each department controls its own individual blocks of IP addresses, even though all the departments may belong to a common DNS domain that is managed by the main organization.

The remainder of this paper will detail the development of a schema designed specifically for DNS management. We'll first review the content (resource records) of DNS to provide an understanding of exactly what information needs to be captured in the schema. We'll then focus on how to represent this information as object types in the database so that Ganymede's permissions system can be used effectively to allow sharing and delegation of administrative duties. Finally, we'll take a look at some of the external scripts and tools that are used in the process of moving data between DNS and Ganymede using XML as an intermediate layer.


Brian O'Mara
Last modified: Tue Aug 8 11:20:48 CDT 2000