Provision of Essential Network Services James Sargeant Network Services Group Monash University Computer Centre 1. Introduction: The increased reliance by the University on the network has led to an increasing criticality of essential network services (eg. bootp and DNS). Currently, essential network services are provided using different approaches and different platforms on each individual campus. This has led to duplication of staff effort and difficulties when equipment is moved from campus to campus, especially as staff from one campus may not be familiar with the approaches to essential network services at another campus. These essential network services need to be considered in the design of a redundant network that is able to continue to operate given any single point of failure. In addition, recent changes to cisco software enable bootp and DNS requests to be forwarded to two or more (sub)networks. Consequently, essential network service requests could be automatically answered from another campus in the event of problems at the local campus. 2. Essential Network Servers: A single, dedicated, network server machine should be implemented at each campus. These campus network servers should be slaved to a central master network server. The minimum functionality of the Monash master server should be: Primary Bootp repository; Primary Monash domain name server (for CC controlled domains); Secondary DNS for non CC controlled domains; Secondary for non-Monash domains; and Host-name database (for moves and changes). The Monash master server should not be used to provide application level network services such as network news, email or gopher server, as application level network services can consume large and unpredictable machine resources. The minimum functionality of the campus network servers should be: Stand-alone capability; Bootp server; DNS server; and Network authentication server. 3. Responsibility: Responsibility for the Monash master server and the campus network servers should reside with the Network Services group. However, the group could negotiate with other groups for the provision of some services (eg. hardware and software support, maintenance of tables, and file backup). 4. Stand-alone capability: The campus network server must be able to boot and provide bootp and DNS service independent of the state of any other host system and independent of the state of inter-campus connections. An appropriate test of this requirement is for the network server to be able to boot while disconnected from Ethernet, and then resolve local bootp, DNS and network authentication requests once re-connected to its local ethernet segment. Campus network servers should be connected to uninterruptable power supplies. 5. Bootp Serving: Bootp is used by TCP/IP hosts to determine IP addresses from MAC layer addresses (eg. ethernet hardware address). Bootp packets can often contain additional information such as the subnet mask and the IP addresses of the local gateway and DNS server. Initially, a single master bootp file should be maintained on the Monash master server and distributed (in total) to the campus network servers when modified. All changes to bootp information should be made to the master bootp file for later distribution. The master bootp file should be structured in such a way that it can be quickly and easily modified to reflect changes to network services (an example of this is the current bootptab in use on mother.cc.monash.edu.au). An alternative to a single master bootp file is to create multiple bootp files and combine them into a single entity as part of the distribution process. Administration of bootp files could then be delegated to a number of people, including those from other departments. The master bootp file would be distributed to the campus network servers as described above. The effort required to implement this solution would not be great, although extreme care would need to be exercised on the part of those modifying the individual tables. However, this approach would be valid only until such time as the hostname database became available, and the effort expended may be better directed towards developing the hostname database scheme. Other host systems could provide bootp service provided they were on the same subnet as the campus network server and only used the master bootp file as distributed from the Monash master server. This would require the registration of all bootp servers on the Monash master server. 6. Name Serving: The DNS is used by TCP/IP hosts to determine IP addresses from domain names (eg. vaxc.cc.monash.edu.au). The DNS also contains mechanisms to perform reverse lookups (domain name from IP address), many to many mappings between domain names and IP addresses, mail exchange pathway identification, and identification of host hardware and software. The Computer Centre is responsible for all names and sub-domains in the monash.edu.au. domain. It has devolved responsibility for some sub-domains to other departments. The Monash master server would be the primary server for all sub-domains administered by the Computer Centre. Individual campus network servers would act as secondaries for all sub-domains of Monash University. The Monash master server would act as the sole Computer Centre secondary for individual departments that operate their own primary name server, irrespective of their home campus. The Monash master server would also be the sole secondary for those external organisations that arrange for Monash University to act as their secondary. The Computer Centre will continue to encourage individual departments to take responsibility for their own sub-domains and to run their own primary name server. System administrators will continue to be encouraged to operate DNS caches. The campus network server would provide the DNS service for all hosts in sub- domains administered by the Computer Centre that are located at that campus. Campus network servers would forward locally unresolved DNS requests to the Monash master server, which would in turn forward DNS requests through to uneeda.aarnet.edu.au. This represents a four tier search strategy: local campus (local); Monash master server (Monash); unneda.aarnet.edu.au (Australia); and root name servers (international). As departmental name servers are, in a sense, logically equivalent to external organization name servers, they would forward unresolved DNS requests to the Monash master server rather than to a campus network server. The four tier search strategy is thus retained with the departmental server taking the place of the local campus network server. Of course the vast majority of requests (including international) would be resolved by the campus servers (or departmental servers). As name servers at each level cache DNS responses very few requests will be made to the root name servers. 7. Hostname Database: The purpose of the hostname database is to automate: the allocation of IP (and possibly other protocol) addresses; the deallocation of addresses; the creation of DNS files; the creation of bootp files; the documentation of host location and responsibility details; and consistency checks. It is anticipated that the hostname database will co-exist with the network management system, as each would need to exchange information with the other. One example could be the notification of contact details to operations staff in the event that the network management system determines a network fault is due to a host fault. Another example could be (in some circumstances and on some subnets) the automatic addition of a host into the hostname database (and subsequently the DNS and bootp files) should the network management system identify a new ethernet address. This need for interoperation tends to imply that the hostname database needs to be implemented on a similar platform and database package to that of the network management system. The hostname database may reside on the Monash master server or it may reside on some other (dedicated) device. Further discussion of the hostname database is beyond the scope of this document and would need to be the subject of further investigation. 8. Network Authentication: Extending Monash University's network through the telephone network is likely to result in network level authentication challenges (eg. Annex and RLN passwords, and dial-back modems). The possible extension of the pilot ADEnet project to encompass the Open Learning initiative will provide further impetuous for network level authentication. Monash University's network is large and complex. Moreover, some connections involve Monash University's network as merely a transit path. Consequently, external access is likely to be quite sophisticated and will require significant resources - resources beyond the simplistic approaches currently in use. The problems of network authentication have certain similarities to those of bootp and DNS serving (ie. a large number of systems that require information to a distributed information system before they can become operational). The solution to network authentication is likely to have similarities to bootp and DNS solutions. An initial starting strategy would be for terminal servers, RLN server and dial back modems to direct their authentication requests through to the campus network server for validation. Similar to the strategy suggested for bootp and DNS, the local campus network servers would only hold (regularly updated) copies of the master authentication files. The master authentication files should reside on a host system separate from the Monash master server as users will need to be able to log in and modify their network authentication password. To reduce the number of steps required to change the network password it may be sensible to have a dedicated machine whose password file is the master authentication file. Users could then change their network password by telneting to the dedicated host and changing their password. It may also be possible to automate this process and for the dedicated host to only accept login requests from specified hosts. This last step would decrease the probability that the user was masquerading as someone else. Future development could consist of extending the local campus network server's checking procedure to allow it to interrogate a remote (non-Monash) site to validate users' credentials. 9. Interaction with other departments: Individual faculties or departments, eg. computer science, may choose to run their own bootp and DNS servers, either as part of the Monash University system or as a stand-alone operation. Provided a department doesn't have any shared subnet or cisco ports with any other department, it is possible to develop solutions to cover most scenarios. For example, DNS and bootp requests from all subnets belonging to an independent department could be forwarded to the departmental server, and, if the department was party to the wider University system, to the Monash master server as well. Where a subnet is shared by several departments, or where there are several subnets sharing a cisco port, an attached department should not operate its own essential network server. Rather, the department should be encouraged to move onto its own dedicated cisco interface. James Sargeant 30 August, 1993.