OPS335 Lab 3

DOMAIN NAME SYSTEM (DNS)

Objective of this Lab

In this lab, you will configure a Linux machine to be a DNS server for the rest of the machines in your Intranet. You will use your MySeneca ID as your domain. The server will handle all queries for names in the yoursenecaid.org domain. The server will also pass DNS queries for other names and addresses out to the Internet (i.e. to Seneca's DNS server).

This is the current state of our internal network when your harddrive is plugged into a lab machine. Please note that if any of the listed services aren't working for you, you should then fix them (especially your iptables which may block DNS traffic needed for this lab):

You can see in the diagram above that when one of your VMs does a name resolution request:

• The VM contacts the host, which is running a DNS proxy (a.k.a. stub resolver), not a full DNS server
• The DNS proxy on the host contacts the Seneca DNS server, which was assigned to be used on the host via DHCP
• Depending on the type of request, the Seneca DNS server may contact other DNS servers to get an answer to the request.

After you have completed this lab, your vm1 will be running a full-featured DNS server (which is how you're going to get the yoursenecaid.org domain without paying for it). Unfortunately, you will be the only one using your DNS server so no-one else will be able to resolve hosts under yoursenecaid.org

How DNS resolution works

We will review in class how the Domain Name Service works. You should also read in your own time the Address resolution mechanism section (including the Recursive and caching name server subsections) on Wikipedia for an overview of a DNS query. The diagram shown in the WIKI is also quite simple and easy to understand. Domain Name Service is a LARGE topic but this lab provides the basic principles and essentials for this course and DNS set-up for other courses.

We will not be setting up our server to do Reverse DNS Lookups but you are expected to understand the difference. In particular, you should understand that:

• Your registrar (whomever you pay for your domain, even if you run your own DNS server) is responsible for normal (forward) DNS resolution of your domain.
• Your ISP (whomever you pay for your internet connection, i.e. the company that assigned a public IP to your server) is responsible for reverse DNS lookups for your IP.

INVESTIGATION 1: CONFIGURING THE DNS SERVER

We will now be installing, configuring and running a DNS server on our vm1.

Preparation

First, ensure that the host and vms are running, and set the domain name on each of your four machines (host and three VMs via /etc/hosts):

• host.yoursenecaid.org
• vm1.yoursenecaid.org
• vm2.yoursenecaid.org
• vm3.yoursenecaid.org

You should notice that these host and domain names are settings that are local to each machine, e.g. you will still not be able to contact vm1.yoursenecaid.org from vm3. That occurs since you are currently using the Seneca and other public DNS servers which know nothing about domain name: yoursenecaid.org

This preparation step is actually unnecessary for this lab's purpose (do you know why it is unnecessary?). On the other hand, by performing the above operations, it will make things appear more consistent, and may make your life a little easier.

Installation

1. Switch to your vm1 machine.
2. We will be installing the DNS server called Bind, which is considered to be the most popular DNS server on the planet.
3. Issue the following command to install bind:
   
   

   yum install bind

Configuration

An authoritative Bind server has a global configuration file (named.conf) and at least one zone file for the zone it's authoritative for.

/etc/named.conf

When you install Bind you'll get a default /etc/named.conf. Move this file over to a backup location, we will be writing one from scratch with the following contents, but use your own X value where applicable.

options {
        directory "/var/named/";
        allow-query {127.0.0.1; 192.168.X.0/24;};
        forwarders { 142.204.1.2; };
};
zone "localhost" {
        type master;
        file "named.localhost";
};
zone "yoursenecaid.org" {
        type master;
        file "mydb-for-yoursenecaid-org";
};

You need to understand all the options in this file except the localhost zone, so that in the future (for example in a practical test) you can quickly set up a DNS server for a new zone. So look up in the reference these things and write down what they do:

• directory
• allow-query
• forwarders
• type
• file

Zone file

Now edit /var/named/mydb-for-yoursenecaid-org and enter the following (use your own X value where applicable).

$TTL    3D
@       IN      SOA     vm1.yoursenecaid.org.      hostmaster.yoursenecaid.org.(
                2016010301       ; Serial
                8H      ; Refresh
                2H      ; Retry
                1W      ; Expire
                1D      ; Negative Cache TTL
        );
@       IN      NS      vm1.yoursenecaid.org.
vm1     IN      A       192.168.X.2

Again, here's the reference documentation for records in this file. Specifically pay attention to:

• A records
• NS records
• SOA records

Now that your DNS server (bind, a.k.a. named) is configured:

1. Start it with the systemctl command.
2. Check that it's running using the ps ax command (perhaps combined with grep), and separately, the systemctl command (if necessary), or check the /var/log/messages file for troubleshooting purposes.
3. Once you are certain that the service had started and runs without errors, then set it to start automatically when this virtual machine boots.

Firewall rules update

Remember that you are supposed to have a working firewall on your vm1 (and every other machine), but we will focus on our vm1 machine for now. A working firewall will block requests to ports that you didn't explicitly allow. This means that at this point, your DNS server, even though it's perfectly configured, is inaccessible because iptables won't allow the requests to come in.

You will need to update the firewall on vm1 to allow incoming connections in UDP port 53 (i.e. the protocol and port that DNS uses). After you have updated your firewall, then save your iptables rules using whatever means worked for you in the iptables labs and add it to a shell script.

You could just disable the firewall but that is a poor workaround! You are expected to be able to handle configuration (such as this) at this point in this course.

Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book

INVESTIGATION 2: CONFIGURING THE DNS CLIENT

Now that you've setup a DNS server on vm1, you will need to configure all your VMs to use that as the default DNS server. You should know how to do that, but if you forgot the procedure, refer to Lab 1.

You can but you shouldn't set your host to use vm1 as the DNS server. DNS is a critical component of your network setup and if it's not working right - you won't even be able to look for a solution online (or get to this wiki page) on your host. Also your host is configured to be a DHCP client and it gets its DNS server assigned automatically.

Testing

The following commands should work as expected on all your VMs:

host host.yoursenecaid.org
host yoursenecaid.org
host yoursenecaid.org
host yoursenecaid.org
host google.ca

Also on the VMs use a text browser such as lynx to access the Web.

Experiment with the following commands. Use the dig command to query your DNS server for specific records (up to this point you only have NS and A records).

Run vm1 (for DNS server) for Future labs
Due to the changes made in this lab, you will now need your vm1 running in order for any of your virtual machines to be able to use the internet.

Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book

COMPLETING THE LAB

Upon completion of this lab you have a DNS server in your network and every virtual machine is using it to resolve internal and external hostnames. You have now gained experience with some common configuration settings for named, as well as common resource records.

Arrange evidence (command output) for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:

✓nslookup information (A, NS, MX records) for yoursenecaid.org from both vm2 and vm3.

✓dig + trace for yoursenecaid.org from both vm2 and vm3.

✓Completed Lab3 log-book notes.

EXPLORATION QUESTIONS

1. What iptables rules apply to DNS?
2. Under what circumstances does DNS use TCP vs UDP?
3. What is a zone file and what is it used for?
4. Name the zone files used in this lab, and their purpose.
5. What file did you edit to set a static IP address?
6. What parameter did you set in that file to tell the machine to refer to your own DNS server?
7. What is the purpose of /etc/resolv.conf?
8. What is meant by the term "negative cache"?
9. What are MX records used for?
10. What security features are available for DNS?