DNS at Rutgers

This document is a guide to the implementation and support of DNS (the Internet host directory) at Rutgers. It has three sections:

• Instructions for Users
• Recommendations for Departmental Staff
• Setting up a DNS server

Users

The following instructions are intended for general users, and technical staff configuring desktop systems. There are separate instructions below for staff setting up departmental servers.

For all of these sections, you need to know how to change the DNS setting for your system. For the common operating systems, this is documented here: DNS System Settings.

Dialup Users

Where possible, dialup users should configure their systems to use PPP, and to get their IP address, default router and DNS server from PPP. In some versions of Windows, there's a single dialog box for setting the IP address and DNS server. In this dialog box, you should click "Obtain an IP address automatically" and "Obtain DNS server address automatically."

If your software does not support this option, you should use the DNS server for the campus you are dialing. For example, if you are dialing the phone number in Camden, you should use the Camden DNS server. The DNS servers are listed here: Network Service Systems .

• If you use the Newark or Camden dialups, use the servers shown in the chart for Newark or Camden, and the "legacy" network.
• If you use the New Brunswick dialups, use the servers shown in the chart for Busch campus, RUNet 2000, Hill Center.

Other home users (ISP's, DSL, Cable modem)

Users at home who don't use Rutgers dialups should get DNS service from their network provider. This includes people who dial up phone numbers other than Rutgers, as well as DSL and cable modem users. Your network provider should give you the address of a DNS server. In most cases they will instruct you to set up your software to obtain a DNS server automatically.

There are no DNS servers at Rutgers intended to service people at home, other than those using Rutgers dialups. Some Rutgers DNS servers may work temporarily. However the information that they provide is inappropriate for home users (except those using Rutgers modems). It is likely to become more inappropriate as time goes on.

Dorm Users

Students in the dorms should receive a packet of information when you move in. This includes your IP address, DNS server, and other information. Please use the DNS server from that information.

Users in Departments

Users in departments should consult the staff in your department. You need to know what strategy your department is using. Here are the three options for setting up computers in departments:

• If the department is using DHCP (Dynamic Host Configuration Protocol), which we recommend, setup should be done automatically.
• If the department is not using DHCP, you should check to see whether your department is running its own DNS server. If so, you should use the address of this server
• Otherwise, you can use a OIT DNS server

Here are the details:

1. We recommend that departments use DHCP to configure desktop systems. If your department does this, then you will get the proper DNS server address automatically. If your department works this way, you'll need to make sure that your computer is configured to get its information from DHCP. For many current operating systems, this is the default. So you may not need to do anything. As an example, in some versions of Windows, there's a single dialog box for setting the IP address and DNS server. In this dialog box, you should click "Obtain an IP address automatically" and "Obtain DNS server address automatically."

2. For departments that do not use DHCP, check to see whether your department maintains its own DNS servers. If so, you will want to use the address of your department's DNS server.

3. If your department doesn't use DHCP (or your operating system doesn't support it), and they don't maintain their own DNS server, you can use a OIT-maintained DNS server. They are listed in a table near the end of this document: Network Service Systems.

In order to use this chart, you need to know whether your department uses the new RUNet 2000 infrastructure or not. Note that RUNet 2000 and the legacy network are separate. They join only in Hill Center. That's why there are separate servers listed for them.

• If you are on the legacy network, use the primary and backup for your campus. Make sure you pick the ones labelled "legacy".
• If you are on RUNet 2000, look up your zone. Make sure you use only entries labelled "RUNet 2000".

Now, as to whether the network you are using is an RUNet 2000 network or a legacy network: Your departmental networking staff should know this. If they do not, use the following command:

traceroute 128.6.224.114

On Windows, the command is called "tracert" rather than "traceroute." You should see output like this:

> traceroute 128.6.224.114
traceroute to 128.6.224.114 (128.6.224.114), 30 hops max, 40 byte packets
1 busch-gw (128.6.228.1) 2 ms 1 ms 1 ms
2 hill-gw (128.6.227.2) 1 ms 1 ms 1 ms
3 transition2-gw (165.230.12.145) 1 ms 1 ms 1 ms
4 pr01-h012-hill.Rutgers.EDU (198.151.130.1) 1 ms 1 ms 1 ms
5 cr01-h012-hill.Rutgers.EDU (198.151.130.35) 1 ms 1 ms 1 ms
6 ar02-hill012-hill (128.6.234.67) 2 ms 2 ms 2 ms
7 hme0-nss-hill012-hill (128.6.224.114) 1 ms 1 ms 1 ms

See whether "transition-gw" or a similar name (in this case "transition2-gw") is listed. If so, you are on the "legacy" network. If not, you are on RUNet 2000.

Checking a server

You may need to check a server to see whether it is appropriate for you to use. To do this, look up the names "inside.rutgers.edu" and "outside.rutgers.edu". DNS servers intended for use within Rutgers will have an entry for inside, but not one for outside.

It might seem that DNS servers intended for use outside Rutgers would have an entry for outside.rutgers.edu. In some sense this is true. However those servers are not set up to let you point to them as your DNS server. If you are outside Rutgers, you should use the DNS server provided by your network service provider.

The following example uses the "host" command to look up information. It is available on many Rutgers Unix systems. On many other systems, the "nslookup" command can be used in the same way (with the same arguments).

Example 1. Check to see whether your current DNS setup is giving you the correct information. You are at Rutgers.

> host inside
inside.rutgers.edu has address 128.6.224.114
inside.rutgers.edu mail is handled (pri=0) by tdmx.rutgers.edu
> host outside
Host not found.

Example 2. Check to see whether your current DNS setup is giving you the correct information. You are at home, not using a Rutgers dialup.

> host inside.rutgers.edu
Host not found.
> host outside.rutgers.edu
outside.rutgers.edu has address 128.6.224.114
outside.rutgers.edu mail is handled (pri=0) by tdmx.rutgers.edu

Example 3. Check to see whether the dns server "ns-lcsr.rutgers.edu" is giving you the correct information. This is how you would check your departmental server to make sure it set up properly.

> host inside.rutgers.edu ns-lcsr.rutgers.edu
Using domain server:
Name: ns-lcsr.rutgers.edu
Address: 128.6.4.4
Aliases:

inside.rutgers.edu has address 128.6.224.114
inside.rutgers.edu mail is handled (pri=0) by tdmx.rutgers.edu
> host outside.rutgers.edu ns-lcsr.rutgers.edu
Using domain server:
Name: ns-lcsr.rutgers.edu
Address: 128.6.4.4
Aliases:

Host not found.

Note: servers intended for use inside Rutgers may not respond to queries from outside, and visa versa.

Recommendations for Departmental Staff

We recommend that departments use DHCP to configure desktop systems. Networks are a dynamic technology. You need to expect that IP addresses will change now and then, as will parameters such as default routers and DNS servers. DHCP is the easiest way to avoid having to get all your users to reconfigure their desktops every time there is a change.

The structure described in this page is being implemented on May 28, 2001. In principle, you should immediately update all of your computers to use the new DNS servers. However in practice, the older servers will continue to operate and to supply information appropriate for Rutgers systems. The only exception is the primary DNS servers, dns1.rutgers.edu, dns2.rutgers.edu, and dns3.rutgers.edu. However even these systems will be usable for a while. They will have information intended for systems outside Rutgers, but for the first few months we do not expect this to differ very much from the internal systems. Here is more specific information about what will happen with older DNS servers: Spring 2001 DNS Server Changes.

This means that you can take time to move your department to DHCP. If possible we would prefer for you to do this, rather than go around and hard-configuring all of your desktop systems to use the new addresses.

OIT supports a set of DHCP servers, intended for use by departments. It is based on the DNS data. However in order to use DHCP, you need one piece of information that wouldn't normally be in your DNS information: the MAC address (also known as the Ethernet address: a 48-bit number that is associated with your NIC card). Departmental administrators can enter this information if they have been authorized to maintain DNS data for their department. The OIT DHCP servers are "static". That is, they permanently associate an IP address with a given host (i.e. a given MAC address).

Further information on the DNS and DHCP system and tools for departmental staff are available in the hostmaster web site.

Departments may also choose to run their own DHCP servers. This is particularly likely if you are making full use of Windows 2000, since Windows 2000 integrates a number of administrative tasks for supporting desktop systems.

NOTE: Departmental strategies must take into account the need for OIT staff to deal with abuse complaints. We regularly receive complaints from sites outside Rutgers about attacks being made from machines at Rutgers. Quite commonly this occurs when a hacker breaks into a machine at Rutgers and then uses it as a base for attacking other systems.

In order to deal with these complaints, abuse handling staff must be able to determine what system is associated with a given IP address. This means that all hosts must be registered with the DNS system. If a department chooses to use dynamic DHCP (see below), they must have a strategy for identifying systems in response to abuse reports.

If you run your own DHCP server, then you are responsible for coming up with a strategy for maintaining your IP address space, and for keeping your DHCP server up to date on the proper default router and DNS server.

Normally we recommend that departments use static IP address allocation. That is, we recommend that you always use the same IP address for a given host. This address should be registered in the University DNS database, with information describing the location of the host.

However there are times when it makes sense to use dynamically assigned addresses. If you do this, there are some issues, as mentioned above:

• Before using dynamic addresses, you should discuss your strategy with hostmaster@tdmx.rutgers.edu
• You must maintain logs that allow you to identify what system was using a given IP address at a given time. These logs must be kept for at least a month, and information from them must be made available to the OIT abuse handling staff on request.
• We strongly recommend using dynamic addresses only for desktop systems of the same type, supported by the same staff. Servers should always have permanent IP addresses.

Departmental Servers

Departments may wish to set up DNS servers of two types:

• Caching: these servers are not the original source of any information. They simply cache information so that machines in the department can talk with a local server. This can improve performance and reliability.
• Primary servers for subdomains. Currently this is fairly uncommon. But over time we expect some departments to run subdomains themselves.

In either, the issues are the same.

The rest of this section gives instructions for configuring bind 8 and 9. Bind is the most common DNS server software used with Unix. I do not currently have specific instructions for other DNS server software. They should have similar options available.

Bind is configured using a text file, often called /etc/named.conf. The examples below show items to be put in this file. This is not a complete manual on using bind. I'm just giving you the unusual things needed to set it up at Rutgers.

If you don't do special configuration, servers will get information about Rutgers from one of the official servers, e.g. dns1.rutgers.edu. These servers have external information. This is inappropriate for use inside Rutgers.

Thus it is necessary to configure DNS servers to ask a Rutgers inside server whenever they need to lookup a Rutgers host.

The simplest approach is to configure your server so that it sends all queries through one of the OIT-maintained inside servers. To do this, include the following in your configuration file:

options {
   forward only;
   forwarders { 128.6.21.63; 165.230.36.210; };
};

The list of forwarders -- 128.6.21.63; 165.230.36.210 -- should be adjusted to point to the servers appropriate to your campus.

Only one options section can occur in the configuration file. So if you have any other options, you need to combine them with the forward and forwarders statements into a single list of options.

Other approaches

If some some reason you want to deal directly with the hierarchy of DNS servers outside Rutgers, you're going to need to list each of the Rutgers zones, pointing your queries for that zone to one of the OIT inside servers. However we recommend not doing this. Using the forwarding option is likely to be the best approach for most cases.

Here is an example that keeps a local copy of the data:

zone rutgers.edu {
   type slave;
   file "rutgers.edu.cache";
   masters { 128.6.21.63; 165.230.36.210; };
};

This says that the server will keeps its own copy of data for RUTGERS.EDU in a file "rutgers.edu.cache". Data will be transferred periodically from 128.6.21.63 or 165.230.36.210.

If you take this approach, you must include a zone declaration for each zone where separate data is being maintained for inside and outside. Currently I believe this includes

rutgers.edu
6.128.in-addr.arpa
230.165.in-addr.arpa
88.12.192.in-addr.arpa
130.151.198.in-addr.arpa

The declarations for each zone will be the same, except for the name of the zone and the filename.

Unfortunately this list is subject to change, so if you don't forward all queries through an inside server, you'll need to make sure you watch for additional Rutgers zones and add them to your configuration file.

It is possible to mix these approaches. That is, you can include both the forwarding statement shown above and zone declarations for each Rutgers zone. The advantage of this approach is that if any additional Rutgers zones are created, your data will still be valid, because you'll get data for zones that aren't listed explicitly through the forwarders.

Recommendation

I recommend that you take one of three approaches, depending upon your reason for having your own DNS server:

• If you have a local DNS server to improve performance by caching information, or because you need to provide service for a departmental subdomain, I would put the forward statements shown above into your options section. I would not create zone sections unless you have your own subdomain, and are providing the primary DNS service for it. Then you'll need a zone declaration for each zone that you run.
• If you have a local DNS server to improve reliability in case your connection to the campus network fails, I would do both: (1) put the forward statements shown above into your options section, and (2) create zone sections for rutgers.edu and the two major inaddr zones, 6.128.in-addr.arpa and 230.165.in-addr.arpa. This will let you look up most host names within Rutgers if your campus network connection is down. That should let you continue operations within your department (which is all you can expect if your network connection is down). Other queries will still go through the forwarders.
• If you have a local DNS server because you're afraid that the OIT-maintained inside servers may fail, you're going to need to do it the hard way: Do not include the forward statements in the options section, and create zone sections for every zone in Rutgers that provides different information to inside and outside users. At this point you are committed to keeping the list of zones up to date. The OIT DNS servers are run very carefully, and you can refer to multiple servers. Thus I do not believe this approach is necessary. It will also lead to unnecessary traffic between Rutgers and the Internet DNS servers.

I recommend using the first option. The others involve complexities in setup and administration to guard against failures that we expect to be very rare.