As always, I suggest that you read through the entire lab before you get started!
Use ethereal to monitor traffic on the network. Capture->Start brings up a dialog box with options for what traffic to capture. For now, choose eth1 (or wherever your Internet connection is) and use the defaults for everything else. When you click OK, it will start capturing traffic, and show the count of the number of ethernet frames captured of varying types. Stop after you've captured a few hundred and take a look at the kinds of traffic. If you aren't seeing any traffic, open a browser and start accessing some Web sites.
Packet sniffers such as ethereal and tcpdump are valuable tools to understand exactly what traffic is flowing on a link, and to debug network applications. However, in a non-switched environment it can enable you to see other people's traffic, and even in a switched environment you will be able to see other people's traffic if they are logged into the same machine. As a result, use of such tools should be determined carefully, and with respect to any AUP.
Use ethereal to capture just DNS packets to or from your machine. To do that, put the following into the filter box "port 53 && host 192.168.XX.YY" without the quotes, and replacing XX and YY with the real IP address of your internet-connected interface. Now visit a new site, such as http://www.cs.vu.nl/ and capture a few dozen DNS requests and responses. Notice the root requests, and ccTLD requests.
(Do not use Red Hat's bind configuration tool.)
Use the Red Hat tool to configure which services are running. Programs->System->Service Configuration is how to start it. Make named start at boot, and start it now (button at top) and save changes.
OK, now named is running. Use dig to get SOA records for cse.lehigh.edu, specifying localhost as the resolver. This request goes through the server you just started, and you can tell even now that the server is a caching server.
Now we will add our own domain as an authoritative zone that this nameserver will manage for us. You should make up any domain name you like (e.g., lehighrules.edu) and then a few hostnames to go within that domain (e.g., www.lehighrules.edu). You'll be creating a zone file that maps those hostnames to IP addresses, and another zone file to map your local IP address to one of those names. You might want to reference a sample domain zone file, supplied as part of an online book about DNS. Recall that the zone files for named are located in /var/named/. You should currently see three files -- one for forward lookups of localhost, one for reverse lookups of 127.0.0.1, and one hints file. We need to add two more files. One for the forward lookups of our new domain, and one for the reverse lookup of our IP address into that new domain.
Using the localhost.zone, create a new file, perhaps called mynet.zone. Edit that file. When complete, your revised file should have (at least) three entries -- two A records, one pointing to your current IP address, and one pointing to 127.0.0.1; the third entry should be a CNAME for platypus.eecs.lehigh.edu. Remember that whenever you make a change to a zone file, you need to increase the serial number -- which is 42 in the default localhost.zone file.
However, there is more to be done before you can test it. You'll need to edit /etc/named.conf to include entries for your new file(s). In addition, in order for the changes to be used by the name server, you'll need to make it re-read the files. I suggest restarting it using the named script in inet.d (as you would restart any other service). You'll also want (at some point) to create the reverse zone file for your IP address.
Once you have made all the changes (and updated the serial numbers), restart named and then use dig to verify that you can resolve the new names correctly. If named has a problem with the files you have created, where do you think it'll send warnings and errors? In order for applications to start using the nameserver, though, you'll need to change /etc/resolv.conf -- put the IP address for localhost as the first nameserver (the system will only use the first, as long as it is a working nameserver).
You should now be able to use a web browser (actually, you might need to restart it) and visit the hostname you created for platypus. To verify that everything works, also use dig to see the results of reverse name resolution. To really see everything in action, use ethereal on the lo interface to see the requests that your applications use, and the responses generated by your local nameserver, and the external interface to see the requests made by your nameserver to the rest of the world.