Software Requirement
Specification
for a
DNS Database Administration
Assistant
by Prentice Bisbal
Group Members:
Paul Senechko
Alex Rass
Joe Arciprete
November 2, 1998
Table of Contents:
Definitions, Acronyms, and
Abbreviations
Domain name servers rely on a collection of database files to provide the network information needed to perform their duties. These files include information on relationships between host names and IP addresses, mail routing information, and which machines are responsible for providing naming services for a particular domain. Editing these files manually whenever a change is made to the networks they serve can be tedious and prone to errors. To eliminate the chance of introducing errors to these databases, a program is to be developed that will assist in the generation of these databases.
The purpose of this document is to provide the necessary information for a group of software designers and programmers to develop such a program. To accomplish this, this document will give some background on the problem, a description of the desired functionality, and any requirements and constraints that affect the development of such a program.
The scope of this document is to provide a description of the program functionality requirements and constraints only. It is not intended to specify the programming language or any other implementation details. Any details of implementation not explicitly stated in this document are the responsibility of the software design/implementation team.
This program is expected to generate output consistent with Internet standards. These standards, known as RFCs (Requests for Comments), are maintained by the Internet Engineering Task Force (IETF). RFC 1035, Domain Names - Implementation and Specification, describes how name servers operate and defines the format of the name server database files. This document should be referred to during the design, implementation, and testing of the program. While the development team must be familiar with these standards, it is not the scope of this document to describe these standards. More information on RFCs and links to RFC repositories can be found at the IETF’s website, http://www.ietf.org.
A - Address - A type of record found in the DNS database files that provides name-to-address mapping.
CNAME - Canonical Name - A type of record found in the DNS database files that allows an alias to be assigned to a host’s “real” name. Not Mandatory
FQDN - Fully Qualified Domain Name - A host name, including the full domain with respect to the root domain. Format is similar to a host name that includes the domain, but a FQDN terminates with a period, indicating the root domain. Also known as an absolute domain name.
IETF - Internet Engineering Task Force, a group responsible for developing and adopting technical standards for the Internet. These standards are known as Requests form Comments (RFCs).
MX - Mail Exchanger - A type of record indicating which host(s) will be providing mail services for a particular host or the domain, and the precedence, if multiple mail exchangers are assigned to one domain or host.
NS - Name Server - A type of record found in the DNS database files indicating the name server information for the domain. Mandatory.
PTR - Pointer - A type of record found in the DNS database files that provides address-to-name mapping. Mandatory
RFC - Request for Comments, A document defining a standard to be used on the Internet, adopted and maintained by the IETF.
RP - Responsible Person - A type of record found in the DNS database files, indicating the person responsible for the name server. Not Mandatory.
SOA - Start of Authority - A type of record found in the DNS database files, indicating information about the domain being served by the name server. Mandatory.
TXT - Text - A type of record found in the DNS database files providing text information not used directly by the DNS, usually combined with RP records to provide contact information for the name server administrator. Not mandatory.
Mockapetris, P. RFC 1034: Domain Names - Concepts and Facilities, Information Sciences Institute, University of Southern California, Marina del Rey, CA, 1987
Mockapetris, P. RFC 1035: Domain Names - Implementation and Specification, Information Sciences Institute, University of Southern California, Marina del Rey, CA 1987
Albits, Paul and Cricket Liu, DNS and BIND, 2nd Ed., O’Reilly and Associates, Inc., Sebastopol, CA, 1997
The rest of this specification includes information necessary to develop the desired program. The following section, General Description, includes a discussion of the problems the program is meant to solve, a description of the intended functionality, characteristics of the eventual user, and some general constraints. The last section, Specific Requirements, gives examples of input and output of the program, and some specific tasks that the program should perform.
A domain name server gets its host name and IP address from a number of text files. The number of files used depends on the size of the domain being served. For a domain with n networks, there will be n + 2 files. There will be one file for host name-to-address mapping, one file for each network that provides address-to-name mapping (reverse-mapping) , and one address-to-name file for the loopback device.
With the exception of the of the loopback device, which shouldn’t need to be edited once it is created, at least two of the files need to be edited every time a change is made to the system. Changes will need to be made in multiple records, too. A mistake in corresponding records in different files can confuse the name server. Certain values, such as the serial number of a file, need to be changed every time a file is edited. As the number of files and records to be edited increases, the possibility of creating errors increases also.
The syntax of the entries are slightly different than what is commonly used elsewhere. For example, in the entries requiring an e-mail address, a period is used instead of the “at” symbol (@). For example, an email address of the form user@host.domain will appear as user.host.domain. Since it is common to see a @ in an e-mail address, a system administrator may accidentally type in an e-mail address using the @ symbol, or overlook it when searching for syntax errors. Also, host names entered in the address records must be fully qualified domain names (FQDNs). A FQDN is similar to a normal host name that includes the domain, but it terminates with a period. These errors may seem trivial, but can have a significant impact on the behavior of a name server.
This program is to prevent these mistakes by presenting a unified interface to the system administrator, allowing him to make the necessary changes in one place. The program will then make necessary changes to the multiple database files.
This program is to have a graphical user interface that will make it easy for a system administrator to browse through the network information in the database and make changes quickly and easily. This information will be presented in a logical manner, grouping related information together visually.
It will read information from an existing set of database files or allow the user to generate a new set of files from scratch. The program is to provide a mechanism for the user to quickly scan through existing network information and any additions, deletions, or modifications. After the user inputs a record, it should check the input information for obvious errors (invalid or already used IP address or host name) and warn him before continuing.
After the user finishes making modifications, the program will generate new files and place then in a location specified by the user. If files already exist with the same names, the program will automatically backup the old files before writing the new files to disk.
The program does not need to run on the name server. It will not make a difference to the program what computer it is running on. If the files are not run on the name server, it is up to the user to transfer them to the name server.
The users of this product will be experienced system UNIX administrators with a knowledge of IP address and host name conventions, as well as detailed knowledge of the syntax of the database files and name server administration in general. Any mistakes made by the user will most likely by typographical errors. Additional operator errors may include assigning the same IP address or host name to two different computers by accident. The intended users prefer functionality over ease of use or a pretty interface.
This program will primarily be run on computers using Sun Microsystems’ Solaris operating system. It also likely that this program will be used with other operating systems such as HP-UX, Digital UNIX, and Linux. For that reason, whatever language this program is implemented in, it should be available on multiple platforms, and should be highly standardized, such as ANSI C, Java, or PERL. It should also be provided as source code so that it can be compiled for whichever operating system it will be used on, if it is written in a language requiring compilation.
This program will be a stand-alone program that is executed on occasion. It may not even run on the system providing the DNS services. There are no significant performance constraints. If it is run on the computer that is acting as the DNS, It should not interfere with the normal operation of the name server or observably degrade its performance.
The programs will allow the user to select existing files to open and work with. It will also allow the user to specify a set of files to generate an initial set of files. If existing files are used, it will read through the files and parse the information from the existing files.
When opening new files, it should prompt the user for the information used in the SOA records. This may include information for the NS records, too. If pre-existing files are used, it should read the serial numbers from the SOA records and automatically increment their value by one when generating the output files. For new files, this value will be set to 1.
The program should prompt the user for NS record information if it isn’t included with SOA information.
The user interface should allow the user to quickly browse through host information based on either host name or IP address to quickly find the records that must be changed. If the user browses through the host names, they should be sorted alphabetically and include aliases and canonical names in the same list. If the user browses by IP address, the IP address should be listed in increasing numerical order.
When the user selects a record to modify, the fields displaying the information for that host (CNAME, aliases, IP address, mail server, etc.) should automatically be filled din with existing information. The user can then add to, remove, or modify the existing information presented to him.
If a user chooses to add a new record, the program will automatically assign the lowest available number on that network. The user can then change the number if necessary and add the rest of the information for that host.
After the user elects to save changes to record, the program should check for obvious errors. It should check for host names (canonical name or alias) or IP addresses that is already in use. It should also check the validity of the IP address.
When the user is done editing the database, and chooses to generate the new database files, the program should allow him to assign names to the files and a location to output the files to. If files of the same name already exist in the specified output directory, the program should automatically rename the existing files by appending an obvious suffix ( .old, .backup, etc.) before writing the new files to that directory.
An informal standard for the order of these records has been adopted on the Internet, which this program shall also use. This order is as follows.
SOA Start of Authority record
NS Name Server records
A Address records
PTR Pointer records
CNAME Canonical Name records
MX Mail Exchanger records
TXT Textual Information records
RP Responsible Person records
Since this is an informal standard, 100% compliance isn’t mandatory, and may not make sense. For example, it may be convenient to have all the records for a single host grouped together. It ma make more sense to have the A,CNAME, and MX records for a single host grouped together. PTR records will not exist in the same file as A, CNAME and MX records. The rest of the details of the format should be taken from RFC 1035.