CS-E4160 - Laboratory Works in Networking and Security D, Lecture, 10.1.2024-12.4.2024

Motivation

Devices on the internet are distinguishable from each other by their IP addresses. However, typing an IP address in your browser, e.g. 172.217.21.163 to reach google.com, is tedious and the addresses are difficult to remember. The Domain Name System (DNS) was designed to create an easy to remember naming system to be used instead of IP addresses. Instead of having to type an IP directly, your computer will do a query to a DNS server, finding who in the .com network owns google.com domain, and what IP is assigned to it. A single DNS server cannot store all the name-ip pairs, so DNS operates in a hierarchical manner.

Domain Name Servers are not something only internet service providers can run, but can be created quite easily inside your network as well. Using your own server allows you to create your own domain within your network. This can be used for creating a domain inside a closed corporate network, for example. Storing website-IP address pairs can also reduce the need for higher level queries, speeding up your access to a website. That is why name servers often have a cache of name-address pairs for recently/frequently requested websites.

Description of the exercise

In this exercise you will set up a simple caching-only nameserver, implement your own .insec -domain, complete with a slave server - and finally a subdomain .not.insec, enhanced with DNSSEC. You will also try out Pi-hole - a DNS sinkhole, which can be used to stop DNS-queries for blacklisted domains.

Additional reading

• BIND9 Administrators Reference Manual
• DNS for Rocket Scientists - BIND9 guide
• RFC 1035 - Domain Names - Implementation and Specification
• The Basics of DNSSEC
• RFC 6781 - DNSSEC Operational Practices
  
• Pi-hole documentation

1. Preparations

You will need four virtual machines for this exercise. Begin with assigning suitable host names in /etc/hosts, for example ns1, ns2, ns3 and client. Install the bind9 package on ns1 and ns2 and ns3. Setup a network topology as below:

2. Caching-only nameserver

Setup ns1 to function as a caching-only nameserver. It will not be authoritative for any domain, and will only resolve queries on behalf of the clients, and cache the results.

Configure the nameserver to forward all queries for which it does not have a cached answer to Google's public nameserver (8.8.8.8). Only allow queries and recursion from local network.

Start your nameserver and watch the logfile /var/log/syslog for any error messages. Check that you can resolve addresses through your own nameserver from the client machine. You can use dig(1) to do the lookups.

3. Create your own tld .insec

Next, you setup your first own domain. This shows that, starting from the top level domains like .com or .fi, all layers of the DNS can also be configured by yourself, to create your very own private internet.

Configure ns1 to be the primary master for .insec domain. For that you will need to create zone definitions, reverse mappings, and to let your server know it will be authoritative for the zone. Create a zone file for .insec with the following information:

• Primary name server for the zone is ns1.insec
• Contact address should be hostmaster@insec
• Use short refresh and retry time limits of 60 seconds
• Put your machine's ip in ns1.insec's A record

Similarly create a reverse mapping zone c.b.a.in-addr.arpa, where a, b and c are the first three numbers of the virtual machine's current IP address (i.e. IP = a.b.c.xxx -> c.b.a.in-addr.arpa).

Add a master zone entry for .insec and c.b.a.in-addr.arpa (see above) in named.conf. Reload bind's configuration files and watch the log for errors. Try to resolve ns1.insec from your client.

4. Create a slave server for .insec

Configure ns2 to work as a slave for .insec domain. Use a similar configuration as for the master, but don't create zone files.

On the master server, add an entry (A, PTR and NS -records) for your slave server. Don't forget to increment the serial number for the zone. Also allow zone transfers to your slave.

Reload configuration files in both machines and watch the logs. Verify that the zone files get transferred to the slave. Try to resolve machines in the .insec domain through both servers.

5. Create a subdomain .not.insec.

Similar to above, create a subdomain .not.insec, use ns2 as a master and ns3 as a slave. Remember to add an entry for subdomain NS in the .not.insec zone files.

N.B You are creating a subdomain of .insec, so a simple copy paste of 4 won't work. Check out bind9 delegation.

Reload configuration files in all three servers (watch the logs) and verify that the zone files get transferred to both slave servers. Try to resolve machines in .not.insec -domain from all three servers.

6. Implement transaction signatures

One of the shortcomings of DNS is that the zone transfers are not authenticated, which opens up an opportunity to alter the zone files during updates. Prevent this by enhancing the .not.insec -domain to implement transaction signatures.

Generate a secret key to be shared between masters and slaves with the command tsig-keygen(8). Use HMAC-SHA1 as the algorithm.

Create a shared key file with the following template:

key keyname {
algorithm hmac-sha1;
secret "generated key";
};

# server to use key with
server ip-addr {
keys { keyname; };
};

Fill in the generated key and server IP address, and make the key available to both the name servers of .not.insec. Include the key file in both the .not.insec name servers' named.conf files, and configure servers to only allow transfers signed with the key.

First try an unauthenticated transfer - and then proceed to verify that you can do authenticated zone transfers using the transaction signature.

7. Pi-hole DNS sinkhole

Pi-hole is a specialized type of DNS server, a DNS sinkhole, which makes queries for certain domains fail. This could be used for example as a DNS level filter for blocking access to forbidden or malicious websites, or for blocking ads by not allowing computers to resolve the addresses of the ad servers.

Install Pi-hole on ns1 and configure the client to use it as their DNS. Perform a dig(1) query to a non-blacklisted domain such as google.com. Then blacklist that domain on the Pi-hole and repeat the query. (The result should not be same for both runs.) 

8. Finishing your work

When finishing your work, please remember to backup files related to the assignment and after your demo possibly reset the configuration changes that you did to the lab environment (Lab1, Lab2, Lab3) to start the next assignment with a clean slate.