CTS 2322 (Unix/Linux Administration II) Project
DNS Caching Server Configuration

(This is a group project; see below for details.)

Due: by the start of class on the date shown on the syllabus

Description:

In this project you will build and use your own caching-only nameserver (DNS).  (This nameserver is authoritative for localhost only.)  After configuring a nameserver you then configure the resolver library to use the nameserver and no longer use the /etc/hosts file.

Background:

Four configuration files are used for a resolver-only configuration, where you do not run a name server locally.  These files are:

Note the /etc/networks file is always optional.  So is the /etc/resolv.conf file if you are not using DNS at all, such as in host only or NIS configurations.  In fact a minimal setup requires only two files, either /etc/resolv.conf (for a DNS setup) or /etc/hosts (for a non-DNS setup), and /etc/nsswitch.conf (to say how to resolve names, using the hosts file or using DNS).

Running a caching-only name server can be as simple as running the name service caching daemon nscd.  However this daemon caches more than just hostnames.  It also caches user and group names (but not passwords).  So every time you add/delete/modify a user or group you must remember to restart this daemon (to clear the cache).  Furthermore running this daemon will occasionally interfere with su.  These are rarely problems on a production server however.

Instead of running nscd you will learn a lot more about DNS by running the BIND name server (named) as a caching-only server.  You then must setup the resolver to use this local DNS server.

If you run a nameserver you must configure it.  In a caching-only configuration of named you use the file /etc/named.conf (the nameserver configuration), the DNS zone data files db.127.0.0 (address to name) and db.localhost (name to address), and root.cache (hints file).  (These may be installed almost anywhere and given arbitrary names, but typically under /var/named/).

DNS is a service vulnerable to attack, so it makes sense to secure it tightly.  The newer versions of named (the BIND nameserver) support directives to restrict who can get info and who can update the info, and to use encrypted communications.  In addition it makes a lot of sense to run the nameserver inside of a chroot jail.  (Or a BSD jail or Solaris 10 zone if available.)  The DNS records can be digitially signed, and the data verified using DNSSEC.

In a large organization it makes sense to permit remote control of the nameservers.  This is done with the command rndc (ndc in older versions of BIND).  Obviously this command could be abused even if use is restricted to users logged in on the localhost.  For this reason BIND permits you to configure this command with the file /etc/rndc.conf to restrict its use.  Additionally rndc can be configured to use an encryption key, generated with the command rndc‑confgen, and stored in the file /etc/rndc.key.

Sample copies of all required files can be found on our class website in the DNS resources section.

Requirements:

For this project you may work either individually or with a single partner.  Groups of more than two are not allowed!  Each student must submit their own copy of the assignment, which must include both your name and your partner's name.  You will setup, configure, and test a caching-only nameserver, configure the resolver library to use it, and configure the nameserver logging.  If necessary you will update the configuration of other affected services, such as email aliases, syslog, logrotate, or DHCP.

Follow these steps and answer the following questions:

Part I — Configuring the Resolver and the Name Server:

  1. Verify the default resolver configuration is correct to use a caching-only DNS nameserver, by examining the files /etc/hosts and /etc/nsswitch.conf.  (Carefully examine the 127.0.0.1 line from /etc/hosts and the hosts and networks lines from /etc/nsswitch.conf.)  What changes (if any) did you make to these files?
  2. Install the Bind (named) name server if necessary.  Configure the nameserver by editing (if necessary) the /etc/named.conf file for a caching-only nameserver.  In what directory will the various zone data files be stored?  What are the name(s) used for any zone files listed?  Verify your /etc/named.conf file has correct syntax by running the command named‑checkconf.  Report and fix any errors found.
  3. Be sure to comment out ALL lines containing any reference to DNSSEC (should be about five such lines).  DNSSEC requires more configuration than you need to do for this project!
  4. Verify the correct zone data files are in the directory, and the zone files have the names specified, in /etc/named.conf.  Examine each zone file (and compare to the samples found in the resources section of this website).  Do you like the zone file naming convention Red Hat uses?  If not feel free to rename the files (and of course update /etc/named.conf.  A useful conventions is zonename.zone for the forward zone file, and zonename‑rev.zone for the reverse zone file.  (I also like root‑servers.hints for the hints file, since it isn't really a zone file.)  Report any changes you have made.
  5. Once you have initially turned on your DNS server, never edit the zone data files without updating the serial number field!  One good convention for serial numbers is to use the current date plus a number (in case you edit the file more than once in a given day), for example 2010080100.  But you can use any number, as long as it increases for every change to the zone file.  What serial number would you use for your zone files, if you needed to make changes today?
  6. The Fedora zone data files may (or may not) need some editing.  Verify the zone files have legal syntax by using the command named‑checkzone.  Report and fix any errors found.  What changes (if any) did you make to these files?
  7. Each zone file lists the email address for the system administrator responsible for maintaining DNS host information.  This person is known as the hostmaster.  For other zones you can use the whois database to locate the hostmaster.  For your own zones (and fake zones such as for localhost) you can look in the zone file to find the email address.

    Check your textbook to determine which part of the zone data file contains the email address.  (Hint: check the syntax of the SOA record.)  What is the email address listed for the hostmaster for the localhost.localdomain zone?

    (Optional part)  For any real zones (you don't have any for this assignment) you should always verify that the email addresses used actually exist.  Usually some email alias is used, so you must examine and edit if necessary the /etc/aliases file.  It is very common to use (or create) an email alias hostmaster@yourDNS‑domain for the DNS administrator (usually root).  Feel free to update your localhost zone data file(s) with any valid email address you wish to use.  (The fake email address used by default is fine for a fake domain such as localhost.)  What changes (if any) did you make to the zone files?  To the /etc/aliases file?  If you update the /etc/aliases file remember that you must run the command newaliases to rebuild the email alias database afterward.

  8. Verify the /etc/sysconfig/named file has all lines commented out.  This is a Red Hat configuration file used to set the command line arguments to named.  (By default it may try to start the nameserver in a chroot jail.  If so you must edit this file and comment out that line for now.)  What changes did you make (if any) to this file?
  9. Start the nameserver (named) from the command line.  This can be done by the normal Sys V init method of /etc/init.d/named start.  Examine the system log files for any errors or other name server related messages.  What name server messages resulted when you tried to start the nameserver?  You should see something like the following in your log file (by default /var/log/messages on Fedora):
    Mar 23 18:33:50 localhost named[9667]: starting BIND 9.2.3 -u named
    Mar 23 18:33:50 localhost named[9667]: using 1 CPU
    Mar 23 18:33:50 localhost named: named startup succeeded
    Mar 23 18:33:50 localhost named[9667]: loading configuration from '/etc/named.conf'
    Mar 23 18:33:51 localhost named[9667]: listening on IPv4 interface lo, 127.0.0.1#53
    Mar 23 18:33:51 localhost named[9667]: listening on IPv4 interface eth0, 10.40.84.221#53
    Mar 23 18:33:51 localhost named[9667]: command channel listening on 127.0.0.1#953
    Mar 23 18:33:51 localhost named[9667]: zone 0.0.127.in-addr.arpa/IN: loaded serial 200503251
    Mar 23 18:33:51 localhost named[9667]: zone localhost/IN: loaded serial 200503251
    Mar 23 18:33:51 localhost named[9667]: running
    Mar 23 18:33:51 localhost named[9667]: zone 0.0.127.in-addr.arpa/IN: 
                                           sending notifies (serial 200503251)
    Mar 23 18:33:51 localhost named[9667]: received notify for zone '0.0.127.in-addr.arpa'
    You should also be able to verify the status of the nameserver with /etc/init.d/named status or with rndc status.
  10. Update the resolver to use the local nameserver.  This is done by editing the file /etc/resolv.conf to include the line
        nameserver 0.0.0.0

    before any other nameserver lines.  In this file the special IP of 0.0.0.0 means localhost.  (Note only the first three nameserver lines in this file are used with some versions of the resolver.)

    Add a search directive to this file like this:

        search hccfl.edu

    This will set a default domain name to use when resolving hostnames without any periods in them (e.g., www).  (You should use search rather than the older domain directive.)  Show the modified resolv.conf file.

  11. Test the nameserver and resolver setup.  Describe the result of: ping -c 1 www | head -1

    You can also try host www, which (unlike ping) won't attempt to use /etc/hosts no matter how nsswitch.conf is set.  Finally, you can try “getent hosts”, which uses the resolver library (and thus tests everything).

  12. If all is working, make the changes permanent by configuring named to start automatically at boot time.  How do you set named to start automatically at boot time?
  13. Finally, test out what happens after a reboot.  You may find that the DHCP settings over-write your /etc/resolv.conf file.  If so, you must update the DHCP configuration so that doesn't happen.  Did your resolv.conf file change after a reboot?  What is the name of the DHCP client run on your system?  How did you find this out?

    A nasty instructor would let you work out on your own how to configure your DHCP client.  You would learn a lot by doing that!  But instead I have provided the information for you here, you may wimp out and use it if you wish.

    /etc/dhcp/dhclient.conf:

    interface "eth0" {
       prepend domain-name-servers 0.0.0.0;
       supersede domain-name "hccfl.edu";
    }

    See the man page for dhclient.conf for more details.  Note that NetworkManager won't use that file.  It only uses interface-specific files.  So if your NIC is named “eth0”, you should make a symlink to that file as follows:

    # ln -s /etc/dhcp/dhclient.conf /etc/dhcp/dhclient-eth0.conf
    

Part II — Logging and Log Rotation Configuration:

BIND (named) can use syslog to handle errors.  But BIND also has a built-in version of syslog and logrotate you can configure.  Rather than configure BIND to handle all the logging issues itself you can use its logging features to separate different kinds of DNS log messages to go to separate syslog facilities.

The default for log messages in BIND version 9 (the most current at this time) is to send all messages of any type to syslog.  The default is to use syslog's daemon facility with priority of info for all messages.  With these settings all nameserver messages end up in the messages log file.

We want to change this so that DNS security messages use the authpriv facility instead (and with the default syslog configuration, the security messages will end up in the /var/log/secure file.)  In addition we would like the other messages to end up in a /var/log/named.log log file instead of the /var/log/messages default.  To accomplish this you must update the syslog configuration so it sends the messages to the correct place, configure named to change the default logging, and finally update the logrotate configuration, so the new log file gets rotated.  To do this, follow the steps below and answer the questions:

  1. First configure syslog

    Fedora (since version 10) uses rsyslog rather than the traditional syslog daemon.  rsyslog is compatible with traditional syslog, except the configuration file is named /etc/rsyslog.conf rather than /etc/syslog.conf.

    Look through the current syslog.conf to identify an unused facility.  Which general facilities (local0 – local7) are not in use?
  2. For the rest of this assignment we assume local2 isn't in use.  Edit syslog.conf and add a line to save all log messages from local2 to the file /var/log/named.log.  Also change the configuration so that local2 messages only go to this file, and not also to any other.  (Duplicate log messages can be confusing!)  What did you add/change in syslog.conf?
  3. Run the command tail ‑f /var/log/messages.  In another window, activate your new syslog configuration.  What command did you use to do this?  Examine the output produced in the first window.  Did syslog restart correctly?
  4. In the configuration for named you can specify the facility you selected previously to log all messages, say local2, and to additionally send security related messages to the syslog authpriv facility.  Read your text for directions on how to add a logging directive to your named.conf file.  When you have done that you can compare your configuration with the following:
    logging {
        channel "security" { syslog authpriv; severity info; };
        channel "named" { syslog local2; };
        category security {  "security"; "named"; };
        category  default { "named"; };
    };
  5. Finally you must configure log rotation on the new log file, /var/log/named.log.  As we showed in class, you need to create a new configuration file for logrotate in /etc/logrotate.d.  (You can copy and modify one of the existing files rather than start from scratch.)

    Over time you will learn if the file is growing too fast or too slow for the settings you chose, and you will need to monitor the log file for a while and make any needed adjustments.  Meanwhile, read the man page for logrotate.conf and add any directives to your configuration that make sense to you.  What is your logrotate configuration for the named file?  A sample file can be found below.

    /var/log/named.log {
        missingok
        create 0644 named named
        postrotate
            /etc/init.d/named reload 2> /dev/null >&1 || true
        endscript
    }

Part III — Using DNS Tools:

Read the man pages for whois, host, and dig (host and dig replace the older nslookup command).  Especially useful are:

host [-al] host-or-domain-name
dig host-or-domain-name [any]
getent hosts host-or-domain-name

(The getent command uses the resolver to get the information; the other two commands directly query DNS.  See getent ‑‑help as the command has no useful man page.)

Notice that a simple change to the name server configuration has had a cascade effect: many other services needed to be re-configured as well (syslog, logrotate, DHCP, and the email aliases).  Not realizing this cascade effect is a common trap for system administrators.  You always need to ask what else is affected by this change?

  1. Besides the changes to named, syslog, and logrotate, what other services might be affected by changing the named logging to use a new file?  (HINT: think about monitoring tools.)
  2. Who owns the domain hcc.edu?  (Use whois for this.)
  3. What is the name and email address of the technical contact (i.e., the hostmaster) for wpollock.com and for hccfl.edu?
  4. What is the DNS name and IP address of the mail server for HCC (hccfl.edu)?
  5. To see all records in a zone you can try a zone transfer from the appropriate server.  Try
    dig @ns1.hcc-online.com -t AXFR wpollock.com

    and then try

    dig @ns1.hcc-online.com -t ANY wpollock.com

    (For security reasons, few servers allow unrestricted zone transfers using AXFR anymore.  I have enabled a zone transfer of wpollock.com, but only from YborStudent.hccfl.edu.  You should try these commands from there.)

    Explain why there are differences in the output.

  6. Next, try these commands as well:
    dig -t AXFR hccfl.edu
    dig @ns1.hccfl.edu -t AXFR hccfl.edu
    dig @ns1.hccfl.edu -t ANY hccfl.edu
    

    Explain the output:  Why did some commands work while others didn't?  Do you think you got all of the records in the hccfl.edu zone, with the command that worked?

  7. What are all the DNS aliases for the host wpollock.com, defined in that zone?  (This can be difficult to determine!  Try using a zone transfer and grep.  Remember, this will only work from YborStudent.)

Additional Notes:

When testing your setup you can temporarily rename the /etc/hosts file, or remove files from the hosts: line in /etc/nsswitch.conf, to be certain you are using the DNS system.  You should also frequently restart the DNS server to clear the cache after each change.

Sample configuration files can be found in the resources section of our class web page.  You should be able to use them as models for your setup.

If you want some other host to use your nameserver you must remember to adjust the firewall rules to allow other hosts access to your DNS server.

To be turned in:

A copy of your relevant journal pages and the answers to the questions asked above.  You can use diff to show any file changes you made.  You can send as email to (preferred).  If email is a problem for some reason, you may turn in a hard-copy.  In this case the pages should be readable, dated, and stapled together.  Your name should appear on the first page.  Consider using this command when printing each file:

lpr -pJ "Your name - Caching DNS Server Project file" file

Don't turn in your whole journal, you will need to add to it every day in class!  It is common in fact to keep the journal as a text file on the system (with a paper backup of course).

Please see your syllabus for more information about submitting projects.