Next: Host Database Up: Network Liaison's Handbook Previous: Network Protocol Addresses

Subsections

Domain Names

Hosts using IP identify each other by network addresses. Names are usually used because they are memorable. The mapping between host names and addresses is handled by servers of the Domain Name System (DNS). These domain name servers manage the Internet-wide "domain name space", which includes top-level domain names, such as edu., com., and org., second-level domain names, such as vt.edu., oracle.com., and npr.org. (which are delegated to individual organizations), and further divisions as desired by these organizations.

The DNS must handle billions of host names and therefore each server does not keep track of all of the host names. Instead, domain names are divided up among the various organizations that need them. This division into "sub-domains" allows an organization to assign host names within its sub-domain by putting the data in its domain name server. Our local name servers handle the host names for Virginia Tech, which must end in .vt.edu.. Hosts outside of Virginia Tech can look up vt.edu. hosts by querying our local name servers.

Local division of the name space requires that there be at least two more parts in front of the .vt.edu., a department sub-domain and a host name.

The department sub-domain is selected by the NL and the department. Usually this is the short name or a common abbreviation for the department, such as cs.vt.edu for the Computer Science department, or music.vt.edu for the School of Music. If one NL managed all of the hosts for the College of Agriculture, these hosts could all be registered under a single sub-domain like ag.vt.edu. University Relations and NI&S have rubber-stamp authority on selection of sub-domains, and can ask departments to select another one, should it be easily confused with other uses.

The host name is selected by the NL or individual user. It identifies a particular host (computer) within a department sub-domain. Some guidance on selecting names is found in RFC 1178. Anecdotally, naming your host "hokies", "maroon", or "orange" tends not to go well; select a fairly unique name!

A typical fully-qualified domain name (FQDN) looks like this: vtvm1.cc.vt.edu. The host name is vtvm1, the department sub-domain is cc (the Computing Center in this case), and vt.edu is Virginia Tech's top-level domain. A department may also elect to further subdivide their domain names by using additional designators before their department sub-domain, for example laplace.mprg.ece.vt.edu. In this case, Electrical and Computer Engineering has elected to designate hosts in the mprg group within their own sub-domain.

A domain name:

All hosts on campus with a global IP address should have a domain name registered in the vt.edu domain. This is not strictly required, but several things make it very important:

There are some cases in which using a domain name is not necessary:

The names associated with the IP addresses assigned to a department are registered by that department's NL. That process is described in more detail later.

An entry in the DNS is called a resource record, or RR. The type of RR that matches host names to IPv4 addresses is an address RR (A RR). An AAAA resource record is used to match the host name to an IPv6 address. In addition to address resource records, there are a few other RRs that can be added to the DNS.

Aliases (CNAME RRs)

Hosts registered in the DNS can have aliases. Aliases are useful when a department offers some sort of service for use by other people on the network. The use of an alias allows the service to be moved to some other host without users needing to reconfigure their clients. For example, the machine cmsw-prod.hosting.vt.edu is the home for the Va Cooperative Extension WWW server. The alias www.ext.vt.edu resolves to cmsw-prod.hosting.vt.edu. (In this case www.ext.vt.edu is the alias and cmsw-prod.hosting.vt.edu is the canonical host name. The alias is bound to the canonical host name with a CNAME RR.) If this service is moved to another host, the alias can be changed to resolve to the new host name and users do not have to reconfigure their clients. This is very helpful if a host provides multiple services (ftp, www, gopher, etc.) If it is later necessary to move one or more of these services to another host and each service has its own alias, the transition doesn't require reconfiguration of the clients.

Some notes on the caveats of using CNAMEs, especially for your top-level website are mentioned in this ISC blog post

Aliases are not used to create short host names. The process of allowing just the host name to be used (rather than the fully-qualified domain name) is done by the resolver code on a particular client. This is typically done by setting the domain search path.

Mail eXchangers (MX RRs)

A Mail eXchanger is a host that receives mail for another domain name. MX records are most useful for providing users a user@dept.vt.edu email address (potentially required for legal reasons), or so that mail from a host won't be dropped by other mail servers (as checking for MX records is often an anti-spam measure).

In general, mail should be sent to people at their pid@vt.edu addresses and not workstation or departmental addresses. Individuals can have their PID mail forwarded to any location they choose without changing anything in the DNS.

Operating a mail server is time-consuming and complicated. Unless including the departmental name in the address is considered to be of great importance, a department wishing to run its own mail server can have the individual users forward their PIDs to the mail server without having any special records in the name server. It is also often possible for departments to use Google or Microsoft Exchange hosted offerings as an alternative to running a mail server.

By default, a registered host will have an MX record referring to itself, in order to prevent unexpected behaviour. If you intend to send mail from a name, it is strongly recommended you add an SPF record.

Reverse DNS (PTR RRs)

A Reverse DNS entry, or pointer record (PTR RR) is a way to map an IP address back to the host that uses it. These are found in the in-addr.arpa. zone for IPv4 addresses, and ip6.arpa. zone for IPv6 addresses. By default, all hosts registered in VT's DNS have reverse DNS entries for all of their VT IP addresses. These are necessary for some services---very few mail servers will accept mail from hosts without reverse DNS.

There are several circumstances in which surpressing generation of this record may be necessary. We restrict PTR records to singletons---i.e. a single address will not reverse to multiple names. Thus, should you wish your bare sub-domain to point to your web server, PTR records must not be entered for the bare sub-domain as the addresses belong to your web server (and not the 3rd-level domain). Suppressing PTR records may also be necessary in certain DNS round-robin situations.

Update Times

The name servers are usually restarted on Tuesdays and Thursdays. Data should be submitted to hostmaster@vt.edu by 10 a.m. to be included in the update. Note that the updates are sometimes delayed or done early.

If the timing of an update is critical due to the change of a server name, please indicate that in your request. Hostmaster can either notify you when the change is done or schedule a special update at a non-standard time.

Emergency (unscheduled non-standard) restarts can be done if absolutely needed, but usually not outside of business hours.

If you want more info about the status of the name servers, we maintain a tool which monitors DNS Status.

We usually tweet when the name server has been updated. See VT Hostmaster.

Query Tools (Dig and Drill)

There are a number of tools available to query the name servers and check the database. For Unix systems, dig or drill can be built or installed. There are similar commands available for Windows and OS X; use of those tools is left as an exercise to the reader.

There is a TXT RR in each departmental data file called nsdata.your_sub-domain.vt.edu which will indicate when the file was last updated. Here is an example of looking up the record with dig.

;; QUESTION SECTION:
;nsdata.ece.vt.edu.             IN      TXT

;; ANSWER SECTION:

nsdata.ece.vt.edu.      14400   IN      TXT     "descr: Electrical & Computer Engineering"
nsdata.ece.vt.edu.      14400   IN      TXT     "owner: ECE"

nsdata.ece.vt.edu.      14400   IN      TXT     "$Id: ece.hosts,v 1.380 2019/03/21 13:58:32 walklet Exp $"

Other Domains

Departments sometimes host web sites for professional organizations or as part of research projects. NI&S does not provide domain name services for non-vt.edu domain names. Most domain registrars will provide domain name service for a small fee.

vt.edu Domain Names

There are a few cases where domain names are registered without a departmental sub-domain label, e.g. www.vt.edu. Hosts registered like this must be the official source of some service provided for the University and requests for such host names are reviewed before they are put in the name server.

Bare Subdomain Names

Some departments like to use their bare domain name as a way to reach their WWW server, e.g. wuvt.vt.edu. There are multiple issues with registering a CNAME for this, and the bare domain name should certainly not be the primary name for a host. The hostmaster can add A and AAAA records for bare sub-domains. Further, MX records for departmental sub-domains can be registered.

Registering Host Names

Each host with an IP address should be registered in the domain name server. The NL can register hosts by sending a plain text file in the format described below to hostmaster@vt.edu. Every time a host is added, changed, or deleted, the NL must send the entire updated list to hostmaster@vt.edu. Please include your department/admin group name in the subject of emails to the hostmaster: e.g. "DNS update for cns", as it is easier to figure out your department. If you are sending an attachment, please name the attachment with your sub-domain followed by the file type, either .dat or .csv.

The data files submitted to the hostmaster are processed by a program and they must be in a particular format. This section describes that format and it is important that it be followed carefully.

The NL can request a copy of the current DNS entries for a department by sending mail to hostmaster@vt.edu. This list will only include addresses that are registered in the name server, and will not include any comments previously stored in the data format.

File Format

The file must be ASCII text with unix-style line endings (newline only). We recommend it be included as a MIME attachment, to prevent mangling by your mail client, with the original file name (often dept.csv). The file is a simple comma-separated values format. The legacy colon-delimited format does not support IPv6 and should be considered deprecated. However, it is documented for convenience in the appendix. A fairly thorough sample file is included in this repo, however below is a walkthrough of various features that can be used.

Each record in the file has the following format, and this line is included as a header:

NAME,IP_ADDRESS,MX,ALIAS,COMMENT

The order of fields does not matter, except that COMMENT should be last, but we recommend the order above. Please note that there are other fields available, and new ones are defined from time-to-time; these are the most common.

Field descriptions (all host names should be fully-qualified):

NAME: (required) (sample: vtvm1.cc.vt.edu) See the discussion of the required format of host names earlier in this document.

IP_ADDRESS: (sample: "128.173.4.1,2607:b400:fe::effe:ff:0400") The IP addresses of the host being registered. PTR (reverse DNS) records will be created automatically for these addresses, unless a - is prefixed, e.g. -128.173.4.2. Suppressing a PTR is discussed in more depth earlier in this page. This field is optional as long as MX or ALIAS is populated.

MX: the mail exchanger for THIS host. May be a list of hosts separated by commas. Insert nomail to not have an MX added at all. (optional)

ALIAS: comma separated list of aliases (optional)

VTEDUPTR: If set to yes, IPv6 PTR records will reverse to the bare domain name, rather than host.domain.ipv6.vt.edu. (optional)

COMMENT: include any further data here.

General Notes

Sample records

The following section contains several sample records. There is a record, description, and the resulting entry in the name server. The name server RRs are included for information only. Don't worry if you don't understand what they are.

In these examples, we use the column order of

NAME,IP_ADDRESS,MX,ALIAS,COMMENT

unless specified otherwise.

Example 1

Host and IP address only.

groupw.cns.vt.edu,"128.173.8.21,2001:468:c80:2102:0:14f:b22:3b5d",,

(This is what the line in the data file would look like.)

This record is just a host name and IP address. The MX record will point to the host listed. The PTR for the IPv4 address will point to the bare host, and the PTR for the IPv6 address will point to groupw.cns.ipv6.vt.edu. This will take care of what needs to be done for most hosts.

groupw.cns.vt.edu. IN A 128.173.8.21
groupw.cns.vt.edu. IN AAAA 2001:468:c80:2102:0:14f:b22:3b5d
groupw.cns.vt.edu. IN MX 0 groupw.cns.vt.edu.

(This is what ends up in the name server)

Example 2

MX record only.

cns.vt.edu,,"groupw.cns.vt.edu,morse.cns.vt.edu",

In this case, there is no host for cns.vt.edu. It is used for mail only. This will generate two MX records for cns.vt.edu. The first one will point to groupw.cns.vt.edu and the second one will point to morse.cns.vt.edu. Note that the IP address field is not used, but the commas that delimit it are still there. (The hosts morse.cns.vt.edu and groupw.cns.vt.edu are registered somewhere else in the file with their IP addresses.)

cns.vt.edu. IN MX 10 groupw.cns.vt.edu.
cns.vt.edu. IN MX 20 morse.cns.vt.edu.`

Example 3

Host with IP address and MX hosts.

 groupw.cns.vt.edu,128.173.5.9,"groupw.cns.vt.edu,morse.cns.vt.edu",

This will point mx records for groupw to itself and morse.

groupw.cns.vt.edu. IN A 128.173.5.9
groupw.cns.vt.edu. IN MX 10 groupw.cns.vt.edu.
groupw.cns.vt.edu. IN MX 20 morse.cns.vt.edu.`

Example 4

Host with IP address and Aliases

morse.cns.vt.edu,128.173.12.12,,gopher.cns.vt.edu,ftp.cns.vt.edu,

This will add CNAME RRs (aliases) for morse. Aliases 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 commas that delimit it are still there.

morse.cns.vt.edu. IN A 128.173.12.12
morse.cns.vt.edu. IN MX 0 morse.cns.vt.edu.
gopher.cns.vt.edu. IN CNAME morse.cns.vt.edu.
ftp.cns.vt.edu.  IN CNAME morse.cns.vt.edu.`

Example 5

Bare sub-domain resolving to an IPv4 and IPv6 address, with an MX record

cns.vt.edu,"-128.173.12.12,-2001:468:c80:210f:216:3eff::56c3",morse.cns.vt.edu,,
morse.cns.vt.edu,"128.173.12.12,2001:468:c80:210f:216:3eff::56c3",,www.cns.vt.edu,

Here, morse.cns.vt.edu is the www server for cns.vt.edu, and is configured with vhosts for both cns.vt.edu and www.cns.vt.edu. It also is the mail server for cns.vt.edu. The output will look like:

cns.vt.edu. IN A 128.173.12.12
cns.vt.edu. IN AAAA 2001:468:c80:210f:216:3eff::56c3
cns.vt.edu. IN MX 0 morse.cns.vt.edu.
morse.cns.vt.edu. IN A 128.173.12.12
morse.cns.vt.edu. IN AAAA 2001:468:c80:210f:216:3eff::56c3
morse.cns.vt.edu. IN MX 0 morse.cns.vt.edu.
www.cns.vt.edu.  IN CNAME morse.cns.vt.edu.`

The file for 173.128.in-addr.arpa will only contain 12.12.173.128.in-addr.arpa IN PTR morse.cns.vt.edu., and similarly, the zonefile for 0.8.c.0.8.6.4.0.1.0.0.2.ip6.arpa will only contain the PTR to morse.cns.vt.edu.

Example 8

Sample File

Here is a short sample of what a file sent to hostmaster might look like.

NAME,IP_ADDRESS,MX,ALIAS,COMMENT
# DNS data for cns.vt.edu
# (lines that begin with # are comments.) 
#
# MX record for sub-domain. Most departments won't use this.
# morse will recieve mail for cns.vt.edu
cns.vt.edu,,morse.cns.vt.edu,,
morse.cns.vt.edu,128.173.12.8,,,
#
# A few services run on this host,
haydn.cns.vt.edu,128.173.12.9,,www.cns.vt.edu,ftp.cns.vt.edu,
#
# Regular hosts, just name and address
berg.cns.vt.edu,128.173.12.10,,,
hovhaness.cns.vt.edu,128.173.12.11,,,
cage.cns.vt.edu,128.173.12.12,,,
schoenberg.cns.vt.edu,128.173.12.13,,,
# End of data file`

Next: Host Database Up: Network Liaison's Handbook Previous: Network Protocol Addresses

Phil Benchoff, Eric C. Landgraf 2021-12-02