This lab will cover the basics of DNS management using the open-source package bind9. You will need to work in pairs for this lab. Make sure that all machines are on the Syslab "orange" network.
The first thing we need to do is to setup the two computers we will be using for our lab excercise. Both computers should be on the "orange" 153.106.116.0/23 network. Boot one machine into Linux on a USB key. Boot the other machine into Windows. Make a note of your two machines' IP addresses - we will use them throughout the lab. Verify that the machines can ping each other before continuing.
Question 1: What is your Linux machine's IP address? What is your Windows machine's IP address?
Linux machine: Elevate your priveleges to root. You will be working as root for this lab. Bind9 is a package that exists in the default Ubuntu repositories, so we will be installing it via apt-get.
Once bind is installed, browse around the configuration files in the /etc/bind/ directory. We will mostly be working with the named.conf.local file in this lab.
By default, the bind daemon doesn't do much. Let's test it out to see if we can even do some simple lookups in its current state. Do the following *not* as root.
At this point, the server should NOT be able to lookup Google, and should return 'SERVFAIL' back to you. We will need to set up our bind server to enable recursion: the ability for the server to reach out to other DNS servers to lookup domain names. Before doing this though, please check to make sure that your partner can successfully use your DNS server, using the following steps:
Windows machine: Open up a cmd.exe window. We will be using Window's built-in nslookup utility to perform our queries.
This initial command should have returned a full list of www.google.com IPv6 and IPv4 addresses. Now, let's try the server on the Linux machine. In the command below, fill in your Linux machine's IP address; we will be performing our DNS queries on that machine. Continue with these commands:
After changing our DNS server to your Linux computer, you should once again be greeted with a 'Server failed' error. We are going to issue one last command to make sure that the Linux bind daemon is actually doing something at this point...
Question 2: What name is returned?
If you still get a server failed message, please verify that your bind daemon is running and that you can ping the machine (and if you don't find a problem, see Prof. Norman).
Linux machine: We want our DNS server to be able to perform all the necessary DNS lookups that we commonly use on the Internet. In order to do this, we need to "add" our machine at the bottom of the DNS heirarchy. DNS servers use a hierarchical system to resolve all DNS queries. Most networks will provide on-premise DNS servers for their clients to use for DNS queries (local servers), which then talk to upstream recursive servers or to the root servers of the DNS tree to resolve non-local names (see iana.org for a list). For this lab, we will set up our DNS server to use CPSC's two DNS servers as upstream servers.
Edit the /etc/bind/named.conf.options file in your favorite editor:
0.0.0.0 forwarder153.106.116.2 and 153.106.116.29dnssec-validation auto" line to "dnssec-validation no"Next, before closing out of the named.conf.options file, we want to add some configuration to allow clients to use this DNS server. Add the following lines under the forwarders section:
Any idea what the "myclients" thing was that we just added? The named daemon uses the concept of ACLs (Access Control Lists) to control who can use the daemon on a network. This allows you to configure exactly what computers you want using the DNS system, as it will check the IP address of the requestor before responding to a request. This is useful for security reasons; you can make sure that DNS clients you don't want using your DNS server are denied access to it.
The allow-query { myclients; }; line refers to an ACL "myclients" that we haven't added in yet. Navigate to the top of your configuration file, and before the "options" section that we were just working in, add:
acl myclients {At this time, save and close your configuration file. Before restarting the named daemon, we need to check the configuration file for syntax errors. Run the command:
If the command returns nothing, it means you have a valid configuration file. If you get a syntax error returned, check your configuration file for correct syntax, and run this again until your configuration comes back clean. Restart your named daemon by issuing the command:
Question 3: Why do we define acl lists in DNS configurations?
Now it is time to do some simple tests. Let's perform the nslookup commands as before (not as root):
Hopefully this time things will work out just fine. If you continue to see SERVFAIL errors, try to debug what went wrong or find Prof. Norman before continuing.
Windows machine: Once again we will be trying to perform the nslookup again (see above).
This time around you should get a full list of IP addresses for www.google.com. Try some other domains before moving on... Try, e.g., www.intel.com.
Whenever you want to resolve a domain name to an IP address, somewhere on the Internet, there is a DNS server that will "authoritively" answer for a domain name. That DNS server has something called a "forward zone" file on it; which maps DNS names within its domain to the corresponding IP addresses.
In this section, we'll be defining our own non-existant domain name, setting it up in our DNS server, and testing it out. For this lab we will only be using DNS A records, but be aware that there are many different DNS record types in use.
Linux machine: We will be be defining our zone in two parts; first, we need to let named know that we are setting up a zone file, and second, we need to define the zone file itself. We will be setting up the non-existant "calvinsyslab.edu" domain for this lab.
Edit the file /etc/bind/named.conf.local. Add this to the end of the file:
Save this file out.
Next, create the /etc/bind/db.calvinsyslab.edu file with the following contents:
@ in soa calvinsyslab.edu. root.calvinsyslab.edu. ( 2016042001 ; Serial 28800 ; Refresh every 8 hours 1800 ; Retry after .5 hours 2419200 ; Expire in 28 days 3600 ) ; Minimum TTL of 1 hour ; ; Name server records ; @ in ns root.calvinsyslab.edu.
Note: The spacing on this section is very important; make sure to have a tab after the @ and at the beginning of each line.
Next, we need to add some actual content to our zone file. We'll start simple, by adding an "A" record - an IPv4 address record. The entries use the format of: "
root, filling in your IP address where appropriate:Zone files have a serial at the top of them; every time you update a zone file, you must increment the serial number. It is a general rule-of-thumb that the serial number follows the pattern of YYYYMMDD##, where you fill in the year, month, and day, followed by a two-digit revision number (usually starting at 01). For example, if it was the third edit on 2016-04-21, you would use: 2016042103.
When you have finished, perform a named-checkconf command, and then restart the daemon using service bind9 restart. Note: you may want to monitor your /var/log/syslog file while reloading the DNS daemon, as it will reveal if it has any issues loading your zone file. Running tail -f /var/log/syslog | grep named is highly recommended.
Next, verify that you can lookup all your new DNS entries:
Windows machine: Use nslookup to lookup the three DNS entries above. Make sure that you can successfully resolve all of them.
As an opposite to forward zones, reverse zones let us map IP addresses to DNS names. However, this can only be done publicly if you have full control over an IP address block, and ARIN (for the US) registers your name server as "authoritative" for that IP address block. While multiple DNS names may resolve to a single IP address, a single IP address can only ever resolve to one DNS name; the name that is set in the authoritative DNS zone.
Calvin controls the authoritative reverse zone file for all of the 153.106.0.0/16 IPv4 network. For now, let's take a look at what your current IP's reverse DNS entry is.
Both machines: Restart nslookup and use it to look up your current IP address. Additionally, look up the IP address 153.106.116.40.
Next, we will be overriding the reverse zone lookup on our DNS server. To do so, we will need to make a reverse zone file for the current subnet; the 153.106.116.0/23 network.
Linux machine: Re-open the /etc/bind/named.conf.local file for editing. You will be adding a zone file similar to the forward zone, just named in a weird way..
Additionally, we will make a /etc/bind/106.153.in-addr.arpa.zone file.
db.calvinsyslab.edu file to this new file, as below:@ IN SOA calvinsyslab.edu root.calvinsyslab.edu. ( 2016042001 ; serial 28800 ; refresh 1800 ; retry 2419200 ; expire 3600 ) ; minimum @ IN NS root.calvinsyslab.edu.
40.116 IN PTR meow.calvinsyslab.edu.
Verify your config syntax and reload the bind9 daemon. I highly recommend watching the /var/log/syslog file for any errors; it will mention if it could not load a zone due to errors.
Both computers: Verify that you can successfully perform lookups of all the IP addresses you just put into the reverse zone file.
This concludes this lab; feel free to play around with your new DNS server if you would like.