TThhee CCCCSSOO NNaammeesseerrvveerr -- WWhhyy?? by Steven Dorner s-dorner@uiuc.edu Computer and Communications Services Office University of Illinois at Urbana December 7, 1989 updated by Paul Pomes paul-pomes@uiuc.edu 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 "Steve.Dorner@uiuc.edu", 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 "dorner@garcon.cso.uiuc.edu", there would be five "people" who could update my entry: dorner@garcon.cso.uiuc.edu (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- sandrock@uiuc.edu) of the University's School of Chemical Sci- ences. [4] The DOS client was contributed by Gary Jacobs of Qualcomm Corp (gjacobs@qualcomm.com). [5] The Macintosh client was contributed by John Norstad, Academic Computing and Network Services, Northwestern University (j-norstad@nwu.edu). 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.