17 Domain Name System Part 3 – Dynamic DNS

In Chapter 23, we manually configured our DNS entries with the IP addresses that were statically assigned to our client devices. However, it is uncommon to use static IP assignments, especially in networks with hundreds or even thousands of clients! If we can get our DHCP and ADNS servers to communicate with each other, then IPs can automatically be assigned and our zone files can automatically be populated. This practice is called Dynamic DNS (DDNS).

This lab will expand on the work in Chapter 23 and Chapter 24 to learn how to configure and manage DDNS in a small network environment.

Estimated time for completion: 60 minutes

learning objectives

• Learn how DDNS works on an enterprise network
• Learn how to work with multiple services (DHCP and DNS) on one network

prerequisites

• Chapter 12 – DHCP Linux
• Chapter 21 – DHCP Relay
• Chapter 24 – Domain Name System Part 2

deliverables

• Four (4) screenshots
• BLUE1 (PC1) successfully pinging BLUE2 (PC2) by name
• BLUE2 (PC2) successfully pinging BLUE3 (PC3) by name
• BLUE1 (PC1) successfully performing a DNS query and resolution with the NS1 server via Wireshark monitoring
• Live stream of NS1 reports of the DHCP handshake and zone logs when (BLUE3) PC3 is rebooted

resources

• BIND9 Administrator Reference Manual – https://bind9.readthedocs.io/en/v9.18.16/
• MikroTik RouterOS Documentation – https://help.mikrotik.com/docs/display/ROS/RouterOS
• Archy’s Blog – Dynamic DNS with BIND and ISC-DHCP – https://archyslife.blogspot.com/2018/02/dynamic-dns-with-bind-and-isc-dhcp.html
• Configuring Dynamic DNS with BIND9 – https://doncrawley.com/soundtraining.net/files/configuringdynamicdnswithbind9.pdf
• https://kea.readthedocs.io/en/kea-2.2.0/arm/ddns.html
• https://www.techtutorials.tv/sections/linux/how-to-setup-ddns-using-kea-and-bind/

Contributors and testers

Mathew J. Heath Van Horn, PhD, ERAU-Prescott
Kyle Wheaton, Cybersecurity Student, ERAU-Prescott

1. Preliminary step outside of VirtualBox
   1. Ensure that the “kea-dhcp-ddns-server” is installed. It most likely is if you have KEA installed, but it will solve a headache later if it is not when you begin to configure your GNS3 lab set up. You can check this by changing the network adapter to NAT and opening up the VM without opening GNS3. List everything in the /etc/kea directory to verify it is there.

      > ls -l /etc/kea
      > apt install isc-kea-dhcp-ddns-server

       

      Once installed, shutdown the VM and switch the network adapter back

2. Preliminary step inside VirtualBox
   1. Create/clone a fresh copy of the Linux Server VM with KEA’s DHCP server installed before you open GNS3 if you have the space and computer power to handle both VMs
3. Start GNS3
   1. Save the previous lab as a new project: LAB_11
4. Reuse the network that you built in the previous chapter
   1. Configure the router to act as a DHCP relay for the Blue subnet (Chapter 21, Phase II, Step 1)
   2. Add a DHCP server to the Red network – Ubuntu server (DHCP1)

      NOTE: In reality, both the DHCP and DNS services can operate from the same machine; however, we are splitting them into two separate devices for clarity.

   3. Add a switch to the Red network – Ethernet switch
   4. Connect NS1 and DHCP1 to the switch so that they are on the same LAN
   5. Remove the static IP addresses from Tiny Core Linux clients by commenting out the rules for static IP assignment

      > vi /opt/bootlocal.sh

       

      

      NOTE: Make sure that each client device keeps its unique hostnames! If there are two computers assigned with the same hostname it will cause issues with the DNS records so to limit future pains in the brain, double check your hostnames.

5. Label and organize your network as necessary

1. Start NS1 and login
2. Generate a new Transaction Signature (TSIG) key to use to communicate with DHCP1

   NOTE: Ensure that you have the bind9-utils package installed!

   > cd /etc/bind

   > tsig-keygen dhcp-dns > dhcp-dns.key

   1. It should look similar to the Figure # below
3. Modify the file permissions of dhcp-dns[.]key
   1. Change the owner and group from root to the bind user.

      > sudo chown bind:bind /etc/bind/dhcp-dns.key

   2. Change the file permissions to give read access for the group

      > sudo chmod 640 /etc/bind/dhcp-dns.key

4. Modify the named[.]conf[.]local file

   > sudo vi /etc/bind/named.conf.local

   1. At the beginning of the file, before the zone declarations, include the RNDC key

      include “/etc/bind/dhcp-dns.key”;

       

      

   2. Within each zone declaration (both forward and reverse zones), add the following directive to allow the zones to be updated with a new policy.

      NOTE: The correct amount of spaces may not appear in the CLI format, but you can reference the configuration below it. You will notice it starts at character #3 (a.k.a after 2 spaces), and ‘grant’ begins at character #9.

      > update-policy {
      grant dhcp-dns wildcard *.red.net A DHCID;
      };

      > update-policy {
      grant dhcp-dns wildcard *.80.30.89.in-addr.arpa PTR DHCID;
      };

      

      NOTE: The DHCIDs are required by KEA for both forward (A) and reverse (PTR) records. It allows the server(s) to identify unique clients when updates are made to its records.

       

   3. Save and exit the editor
   4. Verify the configuration settings for any errors

      > named-checkconf

5. Add a new static entry in the red[.]net zone files for DHCP1
   1. Modify the forward lookup zone file. Don’t forget to increase the serial count for each save.

      > vi /var/lib/bind/db.red.net

       

      

   2. Modify the reverse lookup zone file

      > vi /var/lib/bind/db.red.net.rev

       

      

6. Remove all client static entries in the blue[.]net zone files
   1. Modify the forward lookup zone file

      > vi /var/lib/bind/db.blue.net

       

      

   2. Modify the reverse lookup zone file

      > vi /var/lib/bind/db.blue.net.rev

       

      

7. Restart the DNS server and verify that it is running

   > systemctl restart named.service

   > systemctl status named.service

   NOTE: Errors at this stage are likely due to incorrect permissions on the key file. Ensure that both the owner (bind) and group (bind) can read the file.

8. Start and enable Systemd’s time synchronization daemon

   > systemctl start systemd-timesyncd.service

   > systemctl enable systemd-timesyncd.service

1. Start DHCP1 and login – Refer to (Chapter 23, Phase III, Step 3)
   1. Modify the machine’s hostname to dhcp1 and restart the machine from the terminal.

      > hostnamectl hostname dhcp1

   2. Assign a static IP address, default gateway, primary DNS server, and local domain name within its *.yaml file

      NOTE: This example uses the following information:
      – IP Address: 89.30.80.34/29
      – Local Domain: red.net
      – Nameservers: 89.30.80.35
      – Gateway: 89.30.80.33

      1. Verify that the name server information is correctly pointing towards ns1 (89.30.80.35) and that the current domain is red[.]net
         

         > resolvectl status

         

2. Having all elements in a network synchronized to the same time is critical.  SNTP clients provide this service.  Linux uses Systemd’s timesync daemon to provide SNTP packets.  Start it and enable (start on boot) the service by typing

   > systemctl start systemd-timesyncd.service

   > systemctl enable systemd-timesyncd.service

   1. Transfer the key file from NS1 to the primary user’s home directory in DHCP1 if you cannot copy paste the private key.

      NOTE: The default user on my machines is student; be sure to change the following commands as necessary. If you are using one machine for both DHCP and DNS you can skip this part. This section can help those who do not have a bidirectional clipboard enabled.

      1. Login to the NS1 terminal from the DHCP server

         > ssh student@89.30.80.35

         NOTE: You should see the hostname change to ns1 when you login successfully.

      2. Switch to the root user

         > sudo su

      3. Use the Secure Copy (SCP) command to make a copy of dhcp-dns[.]key to the primary user of DHCP1

         > scp /etc/bind/dhcp-dns.key student@89.30.80.34:/home/student

      4. Exit from root

         > exit

      5. Exit the SSH session

         > exit

      6. Verify you see the key in your home directory

         > ls -l ~

   2. Modify the permissions for the key file on the DHCP server
      1. Ensure that the owner and group are both root

         > chown root:root ~/dhcp-dns.key

      2. Change the permissions to remove read access from others

         > chmod 640 ~/dhcp-dns.key

      3. Move the file to the DHCP configuration directory

         > mv ~/dhcp-dns.key /etc/kea

   3. Modify the KEA DHCP configuration file to support both subnets and their domains. Remember KEA uses a JSON format.

      > sudo vi /etc/kea/kea-dhcp4.conf

      1. Include global parameters that apply to all subnets, including the new RNDC key file
         
      2. Add the pools, router data and the DDNS suffix for each subnet included in our BIND9 DNS server
      3. Add the following DDNS updates.
         
   4. Check the file for any errors

      > kea-dhcp4 -t kea-dhcp4.conf

   5. Here is the full configuration for reference
   6. Restart the DHCP service and check its status

      > sudo systemctl restart kea-dhcp4-server.service

      

   7. Ensure that each client in blue[.]net is able to receive an IP address.
      1. Login to the terminal of PC1
      2. Verify it was assigned an IP address

         > ifconfig

         

      3. Repeat for the other two client devices
   8. Configure the DDNS file
      1. The domain information may not be correct at the moment but that is okay! There is one more piece to this DDNS puzzle and that is configuring the KEA-DDNS file.
      2.  Edit kea’s ddns file

         > sudo vi /etc/kea/kea-dhcp-ddns.conf

         1.  Begin by adding some global parameters
            <insert beginning of ddns file including include ip, port, socket etc. show the file being small its ending }>
            
         2. Append the tsig-key you generated earlier to end of the file. Make sure you are not putting it after the final curly braces and including both the o

            > <?include “/etc/kea/tsig-keys.json”?>

         3. Add the forward lookup information
            
         4. Add the reverse lookup information
            
         5. Add KEA’s default logging information if it is not already there. We will keep the default values for everything.
            
         6. Final configuration reference
            
      3. Modify permissions of file so KEA can access

         > sudo chown _kea:root kea-dhcp-ddns.conf”

      4. Check configuration file for any errors

         > kea-dhcp-ddns -t kea-dhcp-ddns.conf

         NOTE: If you get an error stating “Can’t open include file /etc/kea/tsig-keys.json” just run the command again with sudo. This is because we just changed the file permissions so  only root and kea can access it.

      5. Restart the service and check its status

         > sudo systemctl restart kea-dhcp-ddns-server.service

         > systemctl status isc-kea-dhcp-ddhs-server.service

         

   9. Troubleshoot as necessary before proceeding to the next section

1. Start a Wireshark capture between NS1 and the switch
2. Test the dynamic DNS updates
   1. In Wireshark, filter for DNS. Then start up one of the TinyCore computers.
      

      

   2. In the NS1 terminal, start monitoring the system log

      > tail -f /var/log/syslog

   3. Reboot PC1 and watch the logs for the DHCP handshake and zone file mapping
   4. In the Wireshark window, you should see *DNS Update* packets
      

      

   5. Repeat for the other two PC clients

      NOTE: You can request new IP address leases in Tiny Core with the following command:

      > sudo udhcpc

3. After about 15 minutes, BIND9 will populate the db files with the updated host/IP records

   NOTE: By default, this information is stored in a journal file (.JNL) which is located in the same directory as the zone files. The main database files are not frequently updated to increase efficiency.

End of Lab