Network Liaison Handbook

The primary purpose of the document is to explain the use and syntax of the dns datafile used by company network liasons to maintain domain name information on Blacksburg Electronic Village name server.

Network Liaison Functions Requesting Network Addresses DNS Datafile Information DNS Datafile Format Sample Records

Network Liaison Functions

Each company with devices connected to the Virginia Tech campus internetwork will identify a Network Liaison. The Network Liaison will be the contact person between the company and BEV. The responsibilities of the Network Liaison include:

Requesting protocol addresses (IP addresses, and domain names,) from network management and assigning to users.
Sending host registration information to BEV
Maintaining documentation for devices in their respective department.
Distributing information to users within the department as appropriate.

Other functions which Network Liaisons may undertake but which are not required include:

Providing computing assistance and first-level troubleshooting to users in their respective department.
Participating in campus level discussions concerning network development to ensure the special needs of the department are considered.
Monitoring campus and Internet information resources for information pertinent to users and systems within the department.
Systems administration for departmental resources.

The e-mail address of the network liason should be included in the #access line of the DNS datafile.

Alternates

Since the Network Liaison is the only person who can request addresses and register hosts, an alternate Network Liaison to assume these responsibilities should be identified. The alternate Network Liaison should have access to all of the required information and be listed by e-mail address in the #access field of the file.

Requesting Network Addresses

The Network Liaison requests IP addresses by sending e-mail to hostmaster@bev.net indicating the number of addresses needed, what they will be used for, which building the computers will reside in, and the company name and contact information. It is usually a good idea for the Network Liaison to have a few spare addresses for future needs, so please include an estimate of your needs for the next 3 months. A reply via e-mail from hostmaster@bev.net should provide the specified number of IP addresses requested, and will also include other information such as default gateway, netmask, broadcast address, domain nameserver address, etc.

Note: IP addresses in one building may not necessarily work in another building. You can send e-mail to hostmaster@bev.net to verify this.

Do not make up IP addresses to use.

Using un-assigned IP address can lead to erratic service for you and for other customers.

A Note About Local Area Network (LAN) Protocols

There are several LAN protocols in use on campus some of which do not scale well to a network the size the Virginia Tech's. Virginia Tech does not currently restrict LAN protocols from our campus internet. However, it is well known that inefficiencies in a number of these protocols combined with general problems associated with operating such a heterogeneous environment can eventually lead to poor network performance. The emphasis should be placed on applications that run over IP. Most network operating systems,including Microsoft Windows for Workgroups and Novell Netware, offer now or plan to offer soon an option for IP transport.

IP Domain Name Registration

All computers (workstations, servers, routers, etc.) on campus running IP should have a domain name (computer name) registered in the Domain Name Server (DNS). A domain name consists of three parts: the host (user's choice) name and the domain. A sample address looks like this: acme.bevc.blacksburg.va.us, where "acme" is the host name, and bevc.blacksburg.va.us is the domain.

You may wish to obtain your own (usually shorter) domain name, for example acme.com. See Domain Registration Services for more information about obtain a new domain name.

CNAMEs (aliases)

Computers registered in the DNS can have CNAMEs or aliases. Aliases are useful when a company offers some sort of server for use by many users on the network.

For example: the computer slingshot.acme.com could be the home for Acme's web server, but the CNAME is www.acme.com. The CNAME points to the computer slingshot.acme.com. Hence,if the web server is moved to another computer, the only thing to change is the CNAME configuration. Users could continue to use www.acme.com.

Mail eXchangers (MX Hosts)

A Mail eXchanger is a computer that receives mail for another domain name. MX records can be used to forward mail when a host is down, provide mail service for a domain that is not a host, or forward mail for another computer which does not have a SMTP server.

Registering Hosts

Each computer with an IP address should be registered in the Domain Name Server. The Network Liaison can register computers by sending a file in the format described below to hostmaster@bev.net

DNS Datafile Format

#filename:

#owner:

#access:

#contact:

hostname:ip:mxhost(,mxhost...):cname:(,cname...):hw:os:mac:comment

...

Fields:

The first four fields (#filename, #owner, #access,#contact) only appear once. There may any number of host lines following these first four.

#filename (required) is specified by BEV and is the name of your dns data file. example: #filename:acme.dat

#owner (optional) is a list of email addresses from which the first four fields of this file may be changed. Multiple addresses are seperated by commas. example:#owner:bugs@acme.com, bugs@the-hole.com

#access (required) is a list of email address from which the hostlines may be updated. example: #access:bugs@acme.com, foghorn@acme.com

#contact (required) is company contact information including name, address, phone number, and or other contact information

#contact

# Acme Incorporated

# 1234 Rocket Lane

# Toonland, USA

# (555) 1212, Fax (555) 1313, email bugs@acme.com

Now for each of the host lines.

hostname (required) example: slingshot.acme.com

IP (optional depending) example: 128.173.4.1

mxhost (optional) The mail exchange server for THIS host. May be a list of hosts separated by commas.

cname (optional) Comma separated list of cnames.

hw (optional) Hardware type. Should not contain blanks.

os (optional) Operating system. Should not contain blanks.

mac (optional) MAC (ethernet) address. Use dashes and not colons for the address (e.g. 08-00-0b-27-5f-ed). comment (optional) Use any fields you like from this point.

General Notes

No fields should include blanks until you get to the comment field.
All domain names should be fully qualified (for example: `slingshot.acme.com', not just `slingshot').
Please list hosts sorted numerically by IP address.
Put records without IP addresses first in the file.
Do not include multiple zones (if you manage several dns datafiles, do not combine the data for datafile `X' and datafile `Y'.
Please send the complete datfile. All existing data will be replaced.
Each record should be one line. Do not break long records over multiple lines.
If you are not using a particular field, be sure to include the colons out to the last field that you use.
Do not use leading zeros in IP addresses (e.g. use 128.173.4.1 rather than 128.173.004.001).

Sample Records

The following section contains several sample records. There is a record, description, and what will be in the nameserver. The nameserver Rrs are included for information only. Don't worry if you don't understand what they are.

Example 1

Hostname and IP address only

slingshot.acme.com:128.173.5.9

This record contains just a hostname and IP address. This will take care of the majority of registrations. The following registration examples are optional.

Example 2

MX record only

slingshot.acme.com::mail.acme.com,mail2.acme.com

In this case, there is no host for slingshot.acme.com. It is used for mail only. This will generate two MX records for slingshot.acme.com. The first one will point to mail.acme.com and the second one will point to mail2.acme.com. Note that the IP address field is not used, but the colons that delimit it are still there.

Example 3

Host with IP address and MX hosts

slingshot.acme.com:128.173.5.9:slingshot.acme.com,mail.acme.com

This will point MX records for slingshotto itself and mail.acme.com

Example 4

Host with IP address and CNAMEs

slingshot.acme.com:128.173.12.12::www.acme.com,ftp.acme.com:

This will add CNAME Rrs (aliases) for morse. CNAMEs are useful if you provide some sort of service with a host. If you choose to move the service to some other host, all that needs to be changed is the CNAME. Note that the MX field is not used here, but the colons that delimit it are still there.

Example 5

Host with IP address and Ethernet MAC address

slingshot.acme.com:128.173.12.12:::::08-00-09-of-5e-27:

This record has the MAC (ethernet) address filled in. This information is not used in the nameserver. It is something that Network Liaisons should be keeping track of for their own purposes. Note that the address does not contain colons (e.g. 08:00:09:0f:5e:27), dashes are used.

Example 6

Host with HINFO data

Slingshot.acme.com:128.173.12.12:::Intel_Pentium:Red-Hat_Linux:

Here the host type and operating system are listed. Note that these two fields do not contain blanks. These fields are not used for much, and are considered to a security problem by some. Use of these fields is totally up to you.

Example 7

Hostname, IP address, MX records, CNAMEs, etc.

slingshot.acme.com:128.173.12.12:slingshot.acme.com,mail.acme.com:www.acme.com,ftp.acme.com

Here is a fairly complete record. Note that it is one long line. Your browser may have split it into 2 by the time you see it.

Database

Each Network Liaison should keep track of all of the hosts in their respective department(s). Information should include user name, room #, portal #, IP address, MAC address (optional), and any other data the Network Liaison would find useful. Most people will want to keep this database in a format corresponding to the specifications for domain name requests (above).

Primary links

Network Liaison Handbook