RFC 883 November 1983
Domain Names - Implementation and Specification
Design philosophy
The design presented in this memo attempts to provide a base which
will be suitable for several existing networks. An equally
important goal is to provide these services within a framework
that is capable of adjustment to fit the evolution of services in
early clients as well as to accommodate new networks.
Since it is impossible to predict the course of these
developments, the domain system attempts to provide for evolution
in the form of an extensible framework. This section describes
the areas in which we expect to see immediate evolution.
DEFINING THE DATABASE
This memo defines methods for partitioning the database and data
for host names, host addresses, gateway information, and mail
support. Experience with this system will provide guidance for
future additions.
While the present system allows for many new RR types, classes,
etc., we feel that it is more important to get the basic services
in operation than to cover an exhaustive set of information.
Hence we have limited the data types to those we felt were
essential, and would caution designers to avoid implementations
which are based on the number of existing types and classes.
Extensibility in this area is very important.
While the domain system provides techniques for partitioning the
database, policies for administrating the orderly connection of
separate domains and guidelines for constructing the data that
makes up a particular domain will be equally important to the
success of the system. Unfortunately, we feel that experience
with prototype systems will be necessary before this question can
be properly addressed. Thus while this memo has minimal
discussion of these issues, it is a critical area for development.
TYING TOGETHER INTERNETS
Although it is very difficult to characterize the types of
networks, protocols, and applications that will be clients of the
domain system, it is very obvious that some of these applications
will cross the boundaries of network and protocol. At the very
least, mail is such a service.
Attempts to unify two such systems must deal with two major
problems:
1. Differing formats for environment sensitive data. For example,
RFC 883 November 1983
Domain Names - Implementation and Specification
network addresses vary in format, and it is unreasonable to
expect to enforce consistent conventions.
2. Connectivity may require intermediaries. For example, it is a
frequent occurence that mail is sent between hosts that share
no common protocol.
The domain system acknowledges that these are very difficult
problems, and attempts to deal with both problems through its
CLASS mechanism:
1. The CLASS field in RRs allows data to be tagged so that all
programs in the domain system can identify the format in use.
2. The CLASS field allows the requestor to identify the format of
=6= |