CTS-2333 (Unix/Linux Networking) Project #4
DNS Server Configuration

 

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

Description:

In this project you will build and use your own name servers (DNS).  After configuring a name server you then configure the resolver to use the name server and no longer use the /etc/hosts file.  (This project is a continuation of the Building a Caching-only DNS server from the CTS-2322 course.)

This project has two parts.  In the first part you will build a primary name server.  In the second part you will build a secondary name server on your second host.

Perform the following tasks and answer the following questions:

Part IMaster name server:

For this part you will construct and run a primary DNS (BIND) name server.  This name server will be authoritative for our fictitious gcaw.org domain.  You will configure the resolver to uses this DNS name server only, and use DNS before files.

  1. Edit the named.conf to add the needed sections that declares this name server is the master name server for the two zones (the gcaw.org zone and the 255.142.10.in-addr.arpa zone) needed to support our class network.  The new entries should look something like this (you should choose your own file names):
        zone "gcaw.org" {
           type master;
           file "gcaw.org.zone";
       };
    
       zone "255.142.10.in-addr.arpa" {
           type master;
           file "10.142.255.zone";
       };
    

    Next, adjust any options you see fit.  Make sure you accept queries from any host in our classroom (or just accept queries from any host, which is safe enough from the classroom).  As an authoritative server, normally you wouldn't allow any recursive queries.  In our case, you should allow them.  You can limit (recursive or all) queries to only those from the local LAN, to prevent abuse.)  You should configure any security options you see fit, logging, etc.  (Logging will be especially useful if you have trouble getting this to work!)

  2. A change to HCC's network infrastructure in 2015 requires an additional change.  Since the DMZ now sits between two NAT routers, each server has two IP addresses: a 10.something address for connections coming from inside HCC, and a 192.something address for connections coming from the outside.  You must use the correct address depending if you are inside or outside of HCC, or the address simply won't work.  Your new nameserver, when performing recursive queries will get the 192 outside IP for YborStudent or any other HCC server!  (You can test this by running the command “host YborStudent.hccfl.edu” from the classroom.  If you get 192.35.61.222 instead of 10.35.61.222, you won't be able to access YborStudent or any HCC server.)

    To fix this, we must forward any queries received for *.hccfl.edu to one of HCC's internal DNS servers, whose IP addresses can be found in your /etc/resolve.conf file.  Add the following to your named.conf file (using the correct IP addresses of course, and not w, x, y, or z):

    zone "hccfl.edu" {
        type forward;
        forward only;
        forwarders { 10.w.x.y; 10.w.x.z; };
    };
    

    What changes did you make to the named.conf file for these two steps?  (You should show the changes by providing diff output.)

  3. Create the new zone data files in with the same file names as used in the zone sections from step 1 above.  Where should you put zone files?  Where in the named.conf file says this?

    A sample gcaw.org.zone file might look something like this (Add the correct entries for our class, from your existing /etc/hosts file (if created in a previous project), or from the Networking Class Host Name List found on the class wiki:

    gcaw.org.zone File (for server “moe”):

    $TTL    1D
    $ORIGIN gcaw.org.
    @                  IN SOA  ns.gcaw.org. root.moe.gcaw.org.  (
                               2018112400 ; serial
                               3H         ; refresh
                               15M        ; retry
                               1W         ; expire
                               1D )       ; minimum
    @                  IN  NS  ns.gcaw.org.
    gateway            IN  A 10.142.255.1
    ns                 IN  A 10.142.255.2
    moe                IN  A 10.142.255.10
    larry              IN  A 10.142.255.11
    curly              IN  A 10.142.255.12
    shemp              IN  A 10.142.255.13
    

    Keep in mind your server is not named moe, nor is the name of your name server ns.  Indeed, there is likely no servers with any of these names.  (It's okay to add the name “gateway” to the zone, for the classroom router.)  Make sure you create a correct, working zone file.

    A sample 10.142.255.zone might look like this:

    10.142.255.zone File:

    $TTL    86400
    $ORIGIN 255.142.10.in-addr.arpa.
    @       IN      SOA     ns.gcaw.org. root.moe.gcaw.org.  (
                            2009112401 ; Serial
                            3H         ; Refresh
                            15M        ; Retry
                            1W         ; Expire
                            1D )       ; Minimum
                  IN      NS      localhost.
    
    1       IN  PTR  gateway.gcaw.org.
    2       IN  PTR  ns.gcaw.org.
    10      IN  PTR  moe.gcaw.org.
    11      IN  PTR  larry.gcaw.org.
    12      IN  PTR  curly.gcaw.org.
    13      IN  PTR  shemp.gcaw.org.
    

    What are the contents of the two zone files you created?

  4. Test your configuration and zone files using the commands named-checkconf and named-checkzone.  (View their man pages to see the syntax and options.)  What are the exact commands you ran?  What were the results? If any errors are found, fix them and then retest until no errors remain.  Be sure to include the final version of the zone files and the diff of your named.conf file with your submission.
  5. Start the name server (named) from the command line.  This can be done by the Sys V method of init.d/named start, The Systemd method of systemctl start named.service, or by using the rndc start command.  (See the man page for more information about rndc.)  Examine the system log files (or use journalctl) for any errors.  What log file(s) did you check?
  6. Update the resolver to use the local name server.  This is done by editing the file /etc/resolv.conf to include the line
    nameserver 127.0.0.1

    before any other nameserver lines.  Then verify (and edit if necessary) nsswitch.conf will use DNS before /etc/hosts, when resolving host names.  What is the correct line in nsswitch.conf for this?

  7. To ensure you're using the name server and not the hosts file, you should copy the hosts file to a safe location and then edit the original file by removing all entries except the entries for your system (localhost and the line for your static IP address).
  8. Test the name server.  What is the output of each of the following commands:
    dig www.hccfl.edu
    host wpollock.com
    getent hosts www.hccfl.edu
    dig wpserver.gcaw.org
    getent hosts wpserver.gcaw.org

    How do dig, host, and nslookup differ from getent in their operation?

  9. If all is working, make the changes permanent by configuring named to start automatically at boot time.  What steps did you take to do this?  Be sure to restore the /etc/hosts file, if you later plan on running your server but not use your DNS server.
  10. Test your setup by rebooting, then ping some names such as wpserver.gcaw.org, wpserver, yborstudent.hccfl.edu, and yborstudentWhat are the results?  If any names fail to resolve, perform troubleshooting steps.  What was the problem?  (For example, did /etc/resolv.conf change after a reboot?)

Part IISlave name server:

For this part you will construct and run a secondary DNS (BIND) name server, on a second host.  However the default configuration on the primary server is to block external access to the name server.  Before you can setup the secondary server, you must make a few changes on the primary server:

  1. Make sure SE Linux is off or running in permissive mode.  (This is easier then properly configuring SE Linux, and this project is already complex.)
  2. Edit the named.conf file on the master (primary), by changing this line (in the options section):
       listen-on port 53 { 127.0.0.1; };

    to:

       listen-on port 53 { any; };
  3. You can (and should) allow remote hosts to query your name servers.  By default only queries coming from localhost are permitted.  If you want to allow other hosts to list your name server in their resolv.conf file, or to run tools such as dig using your name server, then change this line (in the options section):
       allow-query { localhost; };

    to:

       allow-query { any; };

    Now check for any errors in the config file, then restart the server.  Examine the log files for any problems.

  4. Finally, you need to make a hole in the firewall so you slave server can contact your master name server.  This means allowing new TCP connections from the slave server, to port 53 on the master server.  Additionally, to allow general queries from the outside world, you need to allow UDP incoming connections.  You will need to work out on your own how to configure firewalld or whichever firewall front-end you are using.  You need to allow new (incoming) packets to port 53 using either TCP or UDP, from wherever you allow queries.

    Once you active your new firewall, you should test it from your second host.  How did you test your firewall?
  5. Examine the log files for any errors.  Then make journal entries of all the changes you made.

    Now you're ready to configure the secondary server!  Follow these steps:

  6. Configure the resolver on the secondary host exactly the same as for the first host (running the primary name server).  This will include having the resolver use the name server running on the localhost, and removing all extra entries from /etc/hosts.  Record the changes you made in your system journal.
  7. Edit the named.conf file, to configure it as a slave for the gcaw.org zone, the 0.255.142.10.in-addr.arpa zone, and the forwarding zone (the three zones for which this server is authoritative).  Do not change the other zones (e.g., for localhost).  You should change options (and logging) to match what yo used on the primary name server.  What changes did you make to the default (caching-only) name server's configuration file, to have it become a secondary (slave) name server?  You should show the differences with diff
  8. Test your configuration file using the command named-checkconfWhat is the exact command you ran?  What was the result?  If any errors are found, fix them and then retest until no errors remain. 
  9. Start the name server (named) from the command line.  Wait a while, then examine the system log files for any errors.
  10. Test the name server.  What is the output of the following:
    dig www.hccfl.edu
    getent hosts www.hccfl.edu
    dig wpserver.gcaw.org
    getent hosts wpserver.gcaw.org
  11. If all is working, make the changes permanent by configuring named to start automatically at boot time.

Additional Notes:

It is always a good idea to make a copy of any files before making any changes.  You can also use RCS.  Then you can see the differences easily using diff or rcsdiff.  If you fail to make a copy first, you can look at the file on an unchanged different host.  Or you can move the modified file, and re-install the original using the rpm (or other package management) tool.

If either of your hosts is using DHCP rather than a static IP setup, the changes you made to your resolver will vanish the next time you boot.  You should be running a static IP setup, but if not you can configure dhclient and/or the ifcfg-* file, to not mess up your resolv.conf entries.

Sample DNS files for various configurations can be found in the resources section of our class web page.  These files are for a different network scenario but you should be able to use them as models for your setup.

What additional changes to the resolver configuration would be needed to use DHCP or PPP instead of static IP addresses?

If you want some other host in our class to use your name server you must adjust the firewall rules to allow other hosts access to your DNS server.

To be turned in:

Submit your journal entries showing the steps you have taken and the answers to the questions asked.  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. 

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.