by

TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy??

by
Steven Dorner [email protected]
Computer and Communications Services Office
University of Illinois at Urbana

December 7, 1989

updated by
Paul Pomes [email protected]
Computer and Communications Services Office
University of Illinois at Urbana

August 2, 1992

_I_n_t_r_o_d_u_c_t_i_o_n

There are several documents that describe the function, implemen-
tation, and use of the CCSO Nameserver. This paper has a
slightly different thrust; it endeavors to answer the question,
"Why?" Why did we want a Nameserver? Why did we put in the
features we did, and not others? Why did we develop our own
rather than use someone else's? Why did we choose the CSnet
server as a starting point, and what are the differences between
our Nameserver and the CSnet server?

This paper should be of most use to those contemplating a name
service for their own organization. We hope it will at least
point such people at some of the questions to ask about a name
service; we do not pretend that they will reach the same conclu-
sions as we did.

Necessary to the understanding of this paper is _T_h_e _C_C_S_O
_N_a_m_e_s_e_r_v_e_r - _A _D_e_s_c_r_i_p_t_i_o_n. _A _D_e_s_c_r_i_p_t_i_o_n explains exactly what
our Nameserver is, and how it operates. We will assume that the
reader is familiar with that information, and will not attempt
here to duplicate the explanations offered in _A _D_e_s_c_r_i_p_t_i_o_n.

The CCSO Nameserver is, like many systems, the product of design,
accident, and evolution. Not everything panned out as we had
hoped; some things we thought were important were eventually dis-
carded; some things we tried did not succeed. Special note will
____________________
Converted to portable n/troff format using the -me macros from
funky Next WriteNow format (icch).

22 TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy??

be made where the reality differs radically from the intention.
These places merit close scrutiny, since they indicate a place
where the "right" choice is probably not very clear.

_W_h_y _H_a_v_e _a _N_a_m_e _S_e_r_v_i_c_e?

The first question to be answered is, why do this thing at all?
What are the real benefits of a name service like the CCSO
Nameserver? We had several reasons for expending the effort to
create our Nameserver.

o+ _E_l_e_c_t_r_o_n_i_c _m_a_i_l _d_i_r_e_c_t_o_r_y. First and foremost, we wanted some
way for people in our University to find one another's elec-
tronic mail addresses. There are hundreds of computers in
many different departments, and finding somebody's email
address was like looking for a needle in a haystack. A name
service would provide a central collection and inquiry point
for electronic mail addresses. We have found the Nameserver
to be very useful in this regard, although it has been diffi-
cult to collect the electronic mail addresses.
o+ _A_u_t_o_m_a_t_i_c _m_a_i_l _f_o_r_w_a_r_d_i_n_g. Another reason, ironically, that
we wanted a Nameserver was to eliminate the need for explicit
electronic mail addresses. A central repository of specific
email addresses would give us the capability to accept very
general addresses, such as "[email protected]", turn them
into proper electronic mail addresses, and deliver them. This
would not only eliminate the need for correspondents to know
email addresses, but would also allow people to move from
machine to machine without having to retrain everyone who
sends them mail. It would only be necessary to change the
electronic mail address in the name service to change the
account that receives a person's mail. In practice, we have
found this to be a very convenient service.
o+ _E_l_e_c_t_r_o_n_i_c Phone Another function of a name service would be
as a replacement for the paper phone book. It could be used
to look up mailing addresses and phone numbers of people or
campus organizations, just like a regular phone book. Unlike
a regular phone book, it would be ready at the fingertips of
anyone on our campus network, not across the room on a
bookshelf. Also unlike a regular phone book, it could be kept
up to date as people move around in the University. We are a
little suprised that this is _t_h_e big hit of our Nameserver,
and the major reason that people use it.
o+ _U_s_e_r _v_a_l_i_d_a_t_i_o_n. Given a name service that keeps some infor-
mation about everyone on campus, it is reasonable to contem-
plate using it as a central point for authentication. A user
would identify himself to the name server, and other systems
would accept the name server's word that the user was who he
said he was, eliminating the burden on the user of remembering
many different passwords, as well as ensuring security. This
was not to be part of our initial implementation, however.
[_R_e_a_l_i_t_y: _T_h_i_s _h_a_s _b_e_e_n _p_u_t _o_n _h_o_l_d _u_n_t_i_l _M_I_T'_s _K_e_r_b_e_r_o_s
_c_e_a_s_e_s _t_o _b_e _a _m_o_v_i_n_g _t_a_r_g_e_t.]

TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy?? 33

o+ _A_c_c_o_u_n_t_i_n_g. The name service could serve as a central reposi-
tory for accounting information.

What is has come down to for us is: the Nameserver is a very good
substitute for the paper phone book, a substitute that people
really like; the Nameserver is the only way to find out someone's
email address; and the Nameserver is very useful for forwarding
mail.

_W_h_a_t _D_i_d _W_e _W_a_n_t _I_n _a _N_a_m_e_s_e_r_v_e_r, _a_n_d _W_h_y _D_i_d _W_e _W_a_n_t _I_t?

We had definite ideas about some of the features we wanted in our
name service. The following items were considered essential:

o+ _F_l_e_x_i_b_i_l_i_t_y. We wanted our name service to be a fairly gen-
eral tool. Rather than try to think of all possible uses of
it beforehand, our goal was to come up with a design that
would give us the freedom to add new data items or new
categories of entries. The keeping of tagged fields and the
use of field properties in our Nameserver have met this goal
completely.
o+ _L_a_r_g_e _C_a_p_a_c_i_t_y. Obviously, we needed a database that could
handle the fifty to one hundred thousand entries we were
expecting. This is actually a rather magic range; in the mid-
dle of the range, one exceeds the capacity of 16 bit pointers.
Our Nameserver uses 32 bit pointers, and so is quite safe from
a size standpoint.
o+ _H_i_g_h _P_e_r_f_o_r_m_a_n_c_e. The system has to be very fast if it is
going to be used; no one is going to want to wait a long time
to look up a phone number. Moreover, low delay is absolutely
essential if a name service is going to be involved in mail
handling. Response time for our Nameserver on a typical query
is 1 second, and most of that is spent on network setup, so we
are pleased with performance.
o+ _O_n_l_i_n_e _U_p_d_a_t_e _b_y _U_s_e_r_s. We wanted a name service in which
individuals could update their own information. There were
basically three reasons for this; two practical and one philo-
sophical. The practical reasons are that we didn't want to
bear the large clerical burden of keeping the database up-to-
date, and we didn't want to incur the inevitable time and
accuracy penalty that goes with the aforesaid clerical burden.
The philosophical reason is we'd rather users have control of
their own information, unless there was a good reason for them
not to do so. We allow anyone to change most information
about themselves in our Nameserver; they can do it any time
they wish, and the changes are instantly available to others.
o+ _N_e_t_w_o_r_k-_b_a_s_e_d. Obviously, a large database that is being
dynamically updated is going to have to be accessed over a
network. Even if the database wasn't too large to be repli-
cated on each computer, the fact that updates are possible at
any time would mean the databases would be out of date immedi-
ately. A distributed system such as that used by the Internet

44 TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy??

Domain Name Server[1] could have been used; both implementa-
tion restraints and security concerns made us decide in favor
of a single, centralized database.

We feel that our Nameserver has met all of the essential require-
ments listed above. We also had a list of items that would be
nice, but were not considered essential, for a name service. Our
track record with these items is less good; some of them were not
done because we changed our minds about their worth, others
because we just didn't have the time to implement them.

o+ _T_h_e _O_w_n_i_n_g _A_c_c_o_u_n_t. This idea came from the CSnet Name
Server;[2] the gist of it is that each user has a single
account which "own" his or her entry. The name service only
requires that the host on which the account resides verify
that the account accessing the entry is indeed what it is
claimed to be; no passwords are required of the user. [_R_e_a_l_-
_i_t_y: _W_e _n_e_v_e_r _d_i_d _t_h_i_s. _I_t _r_e_q_u_i_r_e_s _t_h_a_t _t_h_e _h_o_s_t_s _o_n _w_h_i_c_h
_o_w_n_i_n_g _a_c_c_o_u_n_t_s _r_e_s_i_d_e _h_a_v_e _a _h_i_g_h _d_e_g_r_e_e _o_f _c_o_o_p_e_r_a_t_i_o_n _w_i_t_h
_t_h_e _n_a_m_e _s_e_r_v_i_c_e, _s_o_m_e_t_h_i_n_g _w_e _d_i_d _n_o_t _f_e_e_l _w_e _c_o_u_l_d _g_e_t _f_r_o_m
_a_l_l _t_h_e _U_n_i_v_e_r_s_i_t_y _c_o_m_p_u_t_e_r_s. _W_e _c_o_u_l_d _d_o _t_h_i_s _f_o_r _t_h_o_s_e _w_e
_a_d_m_i_n_i_s_t_e_r _o_u_r_s_e_l_v_e_s, _b_u_t _h_a_v_e _n_o_t _f_e_l_t _a _g_r_e_a_t _n_e_e_d _t_o _d_o _s_o.
_I_n_s_t_e_a_d, _w_e _a_s_s_i_g_n _p_a_s_s_w_o_r_d_s _t_o _a_n_y_o_n_e _w_h_o _w_i_s_h_e_s _t_o _c_h_a_n_g_e
_h_i_s _o_r _h_e_r _i_n_f_o_r_m_a_t_i_o_n.]
o+ _D_o_m_a_i_n-_b_a_s_e_d _A_u_t_h_o_r_i_z_a_t_i_o_n. Along with the concept of the
owning account came the idea of domain-based authorization.
In short, one viewed the owning account as being composed of
several domains, each of which would have its own Nameserver
entry. Further, each of these domains would be allowed to do
updates on the information kept about anyone whose owning
account was in its domain. For example, if the owning account
for my entry was "[email protected]", there would be
five "people" who could update my entry:

[email protected] (me)
garcon.cso.uiuc.edu (my system administrator)
cso.uiuc.edu (my department)
uiuc.edu (my University)
edu (the super-user)

This would allow us to restrict some fields in our name service
to being changed at certain levels; for example, only my depart-
ment (or above) could change my job title. This would maintain
the integrity of the database (I couldn't lie about myself), and
____________________
[1] See RFC-1035, _D_o_m_a_i_n _N_a_m_e_s - _I_m_p_l_e_m_e_n_t_a_t_i_o_n _a_n_d _S_p_e_c_i_f_i_c_a-
_t_i_o_n, P. Mockapetris.
[2] See _T_h_e _C_S_N_e_t _N_a_m_e _S_e_r_v_e_r, M. Solomon, L. Landweber, D.
Neuhengen.

TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy?? 55

at the same time would not place the burden of upkeep on any sin-
gle area; each domain would handle its own. [_R_e_a_l_i_t_y: _W_e _n_e_v_e_r
_i_m_p_l_e_m_e_n_t_e_d _t_h_i_s _s_c_h_e_m_e. _M_o_s_t _d_a_t_a _e_l_e_m_e_n_t_s _a_r_e _c_h_a_n_g_e_a_b_l_e _b_y
_t_h_e _i_n_d_i_v_i_d_u_a_l_s _i_n_v_o_l_v_e_d; _i_f _t_h_e_y _w_i_s_h _t_o _l_i_e, _t_h_e_y _m_a_y _d_o _s_o.
_A_b_o_u_t _t_h_e _o_n_l_y _t_h_i_n_g _t_h_a_t _i_s _r_e_s_t_r_i_c_t_e_d _i_s _t_h_e _n_a_m_e _o_f _t_h_e _p_e_r_-
_s_o_n; _c_h_a_n_g_e_s _t_o _n_a_m_e_s _a_r_e _h_a_n_d_l_e_d _b_y _m_e _p_e_r_s_o_n_a_l_l_y _a_t _t_h_i_s _t_i_m_e.
_I _h_a_d _t_o _m_a_k_e _f_i_v_e _c_h_a_n_g_e_s _i_n _a _y_e_a_r _o_f _o_p_e_r_a_t_i_o_n.]

o+ _W_i_d_e _A_v_a_i_l_a_b_i_l_i_t_y _o_f _C_l_i_e_n_t _S_o_f_t_w_a_r_e. To quote from one of
our early design documents:

People should be able to access the nameserver from
just about anything short of an Edsel.

We wanted a name service that was available to anyone on our
campus network. In this we have done fairly well; we have
clients for UNIX, VMS,[3] DOS,[4] Macintosh,[5] as well as a
limited VM/CMS client.

o+ _E_a_s_y _E_n_t_r_y _o_f _I_n_f_o_r_m_a_t_i_o_n. With at least 50,000 entries
expected, we had to have an automated way of entering informa-
tion; "just type it in" was right out. In this our NameServer
gets mixed reviews. Automated entry is used, but it is not
very pleasant; witness the document, _R_e_b_u_i_l_d_i_n_g _a _N_a_m_e_s_e_r_v_e_r
_D_a_t_a_b_a_s_e _I_n _2_4 _E_a_s_y _S_t_e_p_s.
o+ _D_o_n'_t _P_a_s_s _P_a_s_s_w_o_r_d_s _O_v_e_r _t_h_e _N_e_t_w_o_r_k. With cheap ethernet
devices available, it is fairly easy for the asocial person to
tap an ethernet and grab packets. This would allow such a
miscreant to steal passwords; to avoid this, we wanted no
password to traverse our networks "in the clear". Our
Nameserver uses a random challenge scheme that meets this
requirement.

_W_h_y _D_i_d _W_e _D_e_v_e_l_o_p _O_u_r _O_w_n?

Some organizations suffer from NIHS (Not Invented Here Syndrome);
if someone else did it, it's not good enough for us. We'd like
to think that does not describe us. While we were thinking about
criteria for a name service, we also surveyed the field to see if
any of the name servers then in existence were appropriate for
out task. We looked initially at two; the CSnet Name Server and

____________________
[3] The VMS client was contributed by Mark Sandrock (m-
[email protected]) of the University's School of Chemical Sci-
ences.
[4] The DOS client was contributed by Gary Jacobs of Qualcomm
Corp ([email protected]).
[5] The Macintosh client was contributed by John Norstad,
Academic Computing and Network Services, Northwestern University
([email protected]).

66 TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy??

White Pages from Andrew;[6] later, we examined NetDB from Stan-
ford.[7] In tabular form, this is what we found:[8]

______________________________________________________________________
CCrriitteerriiaa CCSSNNEETT WWhhiittee PPaaggeess NNeettDDBB
____________________________________________________________________________________________________________________________________________
______________________________________________________________________
Flexible? No No No
______________________________________________________________________
Large Capacity? Yes

No; 16 bit
pointers.

No; perfor-
mance prob-
lems with
only a few
thousand en-
tries.
______________________________________________________________________
Performance? Yes

Problems with
a few
thousand en-
tries

Not evaluated

______________________________________________________________________
Online Updates? Yes No

Clerical
staff only
______________________________________________________________________
Network-based? Yes Yes Yes
______________________________________________________________________
Owning Account? Yes N/A N/A
______________________________________________________________________
Domain Auth? No N/A Sort of
______________________________________________________________________
Widely Avail Client? Yes Yes

No; need An-
drew
______________________________________________________________________
Easy Info Entry? Yes Unknown Yes
______________________________________________________________________
Secure Passwords? Yes N/A N/A
______________________________________________________________________

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

TTaabbllee 11.. Name Server Comparison

____________________
[6] See _A_n _O_v_e_r_v_i_e_w _o_f _t_h_e _A_n_d_r_e_w _M_e_s_s_a_g_e _S_y_s_t_e_m, J. Rosen-
berg, C. Everhart, N. Borenstein.
[7] See _U_s_e_r'_s _G_u_i_d_e _f_o_r _N_e_t_D_B, Networking and Communications
Systems, Stanford University.
[8] The information in this table was taken from before cited
documents describing the three name servers, as well as from oth-
er documents and source code in the case of the CSnet server.

TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy?? 77

The above comparison made it clear to us that we couldn't use any
of the three candidates as they were. They simply didn't have
the features we felt were essential. Therefore, we decided to
roll our own.

_W_h_y _D_i_d _W_e _U_s_e _t_h_e _C_S_n_e_t _S_e_r_v_e_r _A_s _a _S_t_a_r_t_i_n_g _P_o_i_n_t?

We did not start completely from scratch. We decided that the
CSnet Name Server would make a good starting point for our own
name server. Take a look at Table 1 again. The CSnet server met
three out of five of our essential criteria, and four out of five
of our list of non-essentials. It fell down in three areas:
flexibility, by keeping a fixed set of information about each
entry; capacity, by using 16 bit pointers; and the domain author-
ization scheme, which it did not use.

Examination of the CSnet source code revealed that the two major
deficiencies, the 16 bit pointers and the inflexibility, could be
remedied very easily. The underlying database was actually
fairly general, and adapted itself easily to tagged fields and 32
bit pointers. That left only the domain authorization scheme,
which we decided we could add easily enough at a later date.
[_R_e_a_l_i_t_y: _A_s _w_a_s _m_e_n_t_i_o_n_e_d _b_e_f_o_r_e, _w_e _n_e_v_e_r _d_i_d _d_o _t_h_i_s.]

_W_h_a_t'_s _t_h_e _D_i_f_f_e_r_e_n_c_e?

In the process of adapting the CSnet Name Server to our purposes,
we wound up making many changes. In fact, while we still use a
modified version of the CSnet server's database code, the overly-
ing software is all new. For the benefit of those familiar with
the CSnet server, let us outline the differences between the
CSnet software and our own:

o+ _P_o_i_n_t_e_r_s _e_x_p_a_n_d_e_d _t_o _3_2 _b_i_t_s. 16 bits translates into 65,000
entries (or 32,000 for signed pointers), and was not enough.
We therefore increased the pointer size.
o+ _F_i_x_e_d _f_i_e_l_d_s _r_e_p_l_a_c_e_d _w_i_t_h _t_a_g_g_e_d _f_i_e_l_d_s. The CSnet server
had a half dozen or so null-terminated ASCII fields. Each
field had to be present in every entry, although a field could
be empty. The database proper (as opposed to the higher lev-
els of the server) _d_i_d allow an arbitrary number of null-
terminated fields; a little surgery was done to exploit this
basic orientation. As mentioned elswhere, each entry in our
database has only non-empty fields, tagged with what kind of
field each is.
o+ _O_n_e-_t_i_e_r _a_u_t_h_o_r_i_z_a_t_i_o_n. The CSnet server thought in terms of
user, host, site triples. A user could change his informa-
tion. A host could change the information of any user whose
entry was "owned" by an account on that host. A site could
change the entry of any host identified with that site.
Finally, there was a "super-user" entry. Further, each host
and site had a password that was used for client-server com-
munication. We removed this entire structure; in our

88 TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy??

Nameserver, each user has his own password, and can use it to
change his own entry. Some users have "hero" privileges,
which allow them to change anything in any entry.
o+ _R_e_m_o_v_a_l _o_f _p_i_p_e _a_n_d _e_m_a_i_l _i_n_t_e_r_f_a_c_e_s. The CSnet server had a
client that could talk to it via the network, a pipe, or elec-
tronic mail. We remove the latter two capabilities (although
our server _c_a_n be talked to through a pipe by server adminis-
trators). The pipe was a simple special case of network
access, and was removed without loss of functionality (nor
efficiency, since our server is on a machine with no real
users). The email interface could be done, but we have had no
incentive to do it; network access has so far been suffi-
cient.[9]
o+ _R_e_m_o_v_a_l _o_f _m_a_i_l _f_o_r_w_a_r_d_i_n_g _p_r_o_g_r_a_m_s. The CSnet server looked
at mail forwarding very differently than do we; we therefore
removed that portion of the code. Mail forwarding is done
outside of the Nameserver _p_e_r _s_e, in other programs. These
programs use the Nameserver to look up information, but are
otherwise unrelated to it.
o+ _N_e_w _C_l_i_e_n_t_s. Our client software is completely different.
The ideas are basically the same, but the commands and other
operational issues have all been addressed afresh.
o+ Our Nameserver is talked to very differently than the CSnet
server. We found the CSnet protocol somewhat confusing, and
rather difficult for a human to use; ours can actually be used
by a _h_o_m_o _s_a_p_i_e_n_s without great grief.

There are of course many other differences. The list above is
only intended to hit the "high spots", places where we differ in
a significant manner from the CSnet product. Note that we have
not necessarily _i_m_p_r_o_v_e_d on CSnet's work; we have _a_d_a_p_t_e_d some of
it to fit our needs and desires. It may well be that the CSnet
server would be more appropriate for any given organization. For
example, if network connections are not universal our server is a
bit awkward; the built-in email interface of the CSnet server
would be quite useful in such a case.

_C_o_n_c_l_u_s_i_o_n

We are quite pleased with our Nameserver. It meets most of our
needs, and we are confident that its flexibility and good perfor-
mance will serve us well as we use it for more purposes. Organi-
zations considering a name service are welcome to evaluate ours,
and use it if they wish (subject to the distribution conditions
outlined in _T_h_e _C_C_S_O _N_a_m_e_s_e_r_v_e_r - _A _D_e_s_c_r_i_p_t_i_o_n, which are
liberal). There are however other excellent choices; your choice
will depend on your needs.
____________________
[9] There is actually one quasi-mail interface to our
Nameserver; it runs on our VM/CMS machine and translates BITnet
messages into Nameserver queries.