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


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.

Note!  While you will go through the motions, the BIND DNS server needs no local configuration to work; just install and run it.  For practice, you will make a couple of minor edits to the named.conf file, as indicted below.  You need not define any “zones” or edit any zone files for this project.


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 9 name server (named) as a caching-only server.  You then must setup the resolver to use this local DNS server.

The most recent version of BIND is 10, but that is a complete rewrite and works very differently.  Most distributions have decided to stick with BIND 9, and development has stopped on BIND 10 since nobody wanted it.  You will want the most recent version of BIND 9.  (You might need to explore your yum repos using the commands you have learned, to see what is available.)

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 named.<name-of-zone> (address to name) and named.<name-of-zone> (name to address), and named.ca (the so-called hints file).  (These may be installed almost anywhere and given arbitrary names, but typically under /var/named/).  On Fedora, the bind package includes all the needed files, and is pre-configured as a caching-only server.  Just install and run it, and it should work!

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 digitally 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.

For our project, we will not configure DNSSEC or use rndc.  Sample copies of all required files can be found on our class website in the DNS resources section.  (Keep in mind however, that over time, the commands and their configuration change.  So don't simply copy the existing config files I provided as samples, they are likely out of date!)


For this project you may work either individually or with a single partner.  Groups of more than two are not allowed without explicit permission of the instructor!  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 “” line from /etc/hosts and the “hosts” and “networks” lines from /etc/nsswitch.conf.)  What does the current configuration use to resolve names?  What changes (if any) did you make to these files?
  2. Install the BIND 9 (named) name server if necessary.

    Note!  With Fedora, if you used the server configuration when installing Fedora, you probably already have BIND installed.  However, it seems that the default configuration doesn't always work!  It is probably best to simply uninstall BIND, then reinstall.  Use “dnf remove bind” to delete the old version (and any dependent packages, such as bind-chroot.

    Make a backup copy of named.conf, and any other files you edit for this project.  You can then report the changes you made by showing the output of the diff command.

    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.  View the man page to ensure you use the correct options.  Report and fix any errors found.

    (No changes should be necessary for this step, but that may depend on your distribution and version.)

  3. Be sure to comment out ALL lines containing any reference to “DNSSEC” (should be two to five such lines; all such lines contain the phrase DNSSEC or DLV).  DNSSEC requires more configuration than you need to do for this project!  (While this step isn't strictly necessary, unless you do this BIND will attempt to validate the results it obtains.  That will cause a slowdown and many error messages in your log files.)  Check the named.conf(8) man page to see how to comment out lines.  What lines did you comment out?
  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).  What zone files are included by default on your system?  In which directory are those file to be found?  (Hint: named.ca is not a normal zone file, so don't try to check it.)

    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 to use the new names).  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 normal 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 “2015072100”.  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 to a zone file today?
  6. The zone data files that ship with the Fedora BIND package may (but probably won't) need some editing.  Verify the zone file for localhost has a legal syntax by using the command “named‑checkzone”.  (Examine the man page for that command, to determine the correct options to use.)  Report and fix any errors found.  What was the exact command line used to check that zone file?  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?  Note that if you do see any uncommented lines, you probably have installed the wrong BIND package.
  9. Start the nameserver (“named”) from the command line.  This can be done if your system uses “Sys V init” by the command “/etc/init.d/named start”.  However, if you have a modern systemd init system, you won't see any such file.  Start the service using the normal systemctl command.  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,
    Mar 23 18:33:51 localhost named[9667]: listening on IPv4 interface eth0,
    Mar 23 18:33:51 localhost named[9667]: command channel listening on
    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 verify the status of the nameserver with your init system's standard command, or with “rndc status”, if you configured that command correctly.
  10. Update the resolver to use the local nameserver.  This is done by editing the file /etc/resolv.conf to include the line

    before any other nameserver lines.  (Note only the first three nameserver lines in this file are used with some versions of the resolver.  The first one that provides an answer is used.)

    Add (or replace) the search directive in 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.

    Note that DHCP over-writes the /etc/resolv.conf file whenever it runs, usually at boot time.  So if you don't complete this project in one session, make sure to have a copy of resolv.conf so you can quickly restore that file.

  11. Test the nameserver and resolver setup.  Describe the result of: ping -c 1 www | head -n 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 www”, which uses the resolver library (and thus tests everything).  What would it mean if ping and getent return one result, but host returns a different result?

  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.  As mentioned previously, you may find that the DHCP settings over-write your /etc/resolv.conf file.  If so, you should update the NIC configuration file ifcfg-nameOfNic so that doesn't happen.  Did your resolv.conf file change after a reboot?  If so, what is the name of the configuration file for your NIC?  Show your changes to that file using diff.

    A nasty instructor would let you work out on your own how to configure your DHCP client to make resolv.conf have the correct entries.  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.


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

    (You can determine the name of your NIC by examining the output of the command “ifconfig”.)

    See the man page for dhclient.conf for more details if you are curious.  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

    (Use your correct NIC instead of eth0.)

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 is to send all messages of any type to syslog.  BIND uses 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 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.  However the directions below will use the file name 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?  (Show the diff output.)
  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, compare your configuration with the following (and if different, show your changes):
    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.)  Do not overwrite any existing named config file.  Simply create a new file (with a new name) to rotate your new log file.

    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 {
        create 0644 named named
            # For Sys V init:
            # /etc/init.d/named reload 2> /dev/null >&1 || true
            # For systemd init:
            systemctl reload named.service 2> /dev/null >&1 || true

Part III — Using DNS Tools:

Read the man pages for whois, host, and dig (host and dig are replacements for 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.

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; first try the command line tool, then try an on-line website such as whois.domaintools.com.)
  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. What are the names and IP addresses of HCC's name servers?  (Use whois for this.)  Now look at the IP addresses in your host's /etc/resolv.conf file, then take a look at the IP addresses, and think about what that shows about HCC's DNS setup.
  6. To see all records in a zone you can try a zone transfer from the appropriate server.  Try
    dig @ns5.hccfl.edu -t AXFR wpollock.com

    and then try

    dig @ns5.hccfl.edu -t ANY wpollock.com

    Note: here I showed using ns5, but be sure to use an actual HCC name server found from the previous question.  If you perform this project on-campus, you may need to use a different nameserver from what whois shows.  This is because internal namservers use private IP addresses, and whois data shows only the public, external IP addresses.  Try one of the ones shown in your resolv.conf file.

    (For security reasons, few servers allow unrestricted zone transfers using AXFR!  So don't expect this to work.)

    If the zone transfers were successful, explain why there are differences in the output.

  7. Next, try these commands as well (again, these are likely to fail):
    dig -t AXFR hccfl.edu
    dig @ns5.hccfl.edu -t AXFR hccfl.edu
    dig @ns5.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?

  8. 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.  (Speaking of caching, make sure you are not running nscd too!)

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.  Use diff to show any file changes you made.  Project file" file -->

Use Canvas and submit to the project's drop-box.  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.