25 Domain Name System Part 3 – Dynamic DNS

Jacob Christensen

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: 45 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

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

Contributors and testers

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

Phase I – Building the Network Topology

This lab is an extension of the previous two chapters. If you have not completed them yet, it is recommended that you do so first before continuing. By the end your network should look like the following:

GNS3 Workspace Environment
Figure 1 – Final network topology
  1. Preliminary step in VirtualBox
    1. Create/clone a fresh copy of the Linux Server VM with ISC’s DHCP server installed
  2. Start GNS3
    1. Save the previous lab as a new project: LAB_11
  3. 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

       

      Removing the static IP address
      Figure 1a – removing the static IP

      NOTE: Make sure that each client device keeps its unique hostnames!

  4. Label and organize your network as necessary

Phase II – Modify the DNS Server

This section assumes that all configurations made in the previous chapter have carried over to this one.

  1. Start NS1 and login
  2. Generate a new Remote Name Daemon Control (RNDC) key to use to communicate with DHCP1

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

    > rndc-confgen -a -b 512

    Switch Description
    -a Automatically generate the RNDC file in the /etc/bind directory.
    -b Set the size of the key as a value between 1 and 512 bits.
  3. Modify the file permissions of rndc[.]key
    1. Change the owner and group from root to the bind user

      > chown bind:bind /etc/bind/rndc.key

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

      > chmod 640 /etc/bind/rndc.key

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

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

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

      include “/etc/bind/rndc.key”;

       

      BIND9 configuration
      Figure 2 – BIND9 configuration
    2. Within each zone declaration, add the following directive to allow the zones to be updated with the key

      allow-update { key rndc-key; };

       

      BIND9 configuration
      Figure 3 – Updating zone directives
    3. Save and exit the editor
    4. Verify the configuration settings

      > named-checkconf

  5. Add a new static entry in the red[.]net zone files for DHCP1
    1. Modify the forward lookup zone file

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

       

      Zone configuration modification
      Figure 4 – Updating static forward DNS entry
    2. Modify the reverse lookup zone file

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

       

      BIND9 zone configuration
      Figure 5 – Updating static reverse DNS entry
  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

       

      BIND9 zone configuration
      Figure 6 – Purging static forward DNS entries for an internal subnet
    2. Modify the reverse lookup zone file

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

       

      BIND9 zone configuration
      Figure 7 – Purging static reverse DNS entries for an internal subnet
  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 RNDC 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

Phase III – Configuring the DHCP Server

The following section outlines the configuration of the DHCP daemon for the network.

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

      > hostnamectl hostname dhcp1

    2. Assign a static IP address, default gateway, primary DNS server, and local domain name

      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

        Current DNS configuration
        Figure 8 – DNS information verification
  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 RNDC key file from NS1 to the primary user’s home directory in DHCP1

      NOTE: The default user on my machines is iako; be sure to change the following commands as necessary.

      1. Login to the NS1 terminal

        > ssh iako@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 rndc[.]key to the primary user of DHCP1

        > scp /etc/bind/rndc.key iako@89.30.80.34:/home/iako

      4. Exit from root

        > exit

      5. Exit the SSH session

        > exit

      6. Verify you see the RNDC key in your home directory

        > ls -l ~

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

        > chown root:root ~/rndc.key

      2. Change the permissions to remove read access from others

        > chmod 640 ~/rndc.key

      3. Move the file to the DHCP configuration directory

        > mv ~/rndc.key /etc/dhcp/ddns-keys

        NOTE: If the ddns-keys folder does not exist, make it with the following permissions:

        > mkdir /etc/dhcp/ddns-keys

        > chown root:dhcpd /etc/dhcp/ddns-keys

        > chmod 710 /etc/dhcp/ddns-keys

    3. Modify the DHCP daemon configuration file to support both subnets and their domains

      > vi /etc/dhcp/dhcpd.conf

      1. Include global parameters that apply to all subnets, including the new RNDC key file
        DHCP daemon configuration
        Figure 9 – DHCP daemon configuration part 1
      2. Add the forward lookup zones for the subnets included in our BIND9 server
        DHCP daemon configuration
        Figure 10 – DHCP daemon configuration part 2
      3. Add the reverse lookup zones for the subnets included in our BIND9 server
        DHCP daemon configuration
        Figure 11 – DHCP daemon configuration part 3
      4. Add the DHCP subnet directives for both the Red and Blue networks
        DHCP daemon configuration
        Figure 12 – DHCP daemon configuration part 4
    4. Restart the DHCP service
    5. Ensure that each client in blue[.]net is able to receive an IP address and that its domain information is correct
      1. Login to the terminal of PC1
      2. Verify it was assigned an IP address

        > ifconfig

        Terminal command execution
        Figure 13 – Tiny Core static IP verification
      3. Verify its DNS information is correct

        > cat /etc/resolv.conf

        Terminal command execution
        Figure 14 – DNS information verification
      4. Repeat for the other two client devices
    6. Troubleshoot as necessary before proceeding to the next section

Phase IV – Wireshark Captures

Now that our network is set up, lets watch at some live packet captures to what DNS queries look like in action.

  1. Start a Wireshark capture between NS1 and the switch
  2. Test the dynamic DNS updates
    1. In Wireshark, filter for DNS

      Wireshark packet capture
      Figure 15 – DNS traffic
    2. In the NS1 terminal, start monitoring the system log

      > tail -f /var/log/syslog

       

      Terminal command execution
      Figure 16 – Live monitoring system logs
    3. Reboot PC1 and watch the logs for the DHCP handshake and zone file mapping
      System log monitoring
      Figure 17 – Dynamic DNS updates
    4. In the Wireshark window, you should see *DNS Update* packets
      Wireshark packet capture
      Figure 18 – Wireshark DNS updates
    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

Deliverables

4 screenshots are needed to receive credit for this exercise:

  • BLUE1 (PC1) successfully pinging BLUE2 (PC2) by name as observed on BLUE1 (PC1)
  • BLUE2 (PC2) successfully pinging BLUE3 (PC3) by name as observed on BLUE2 (PC2)
  • 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

Homeworks

Assignment 1 – Add the GREEN network to the workspace on the existing router

  • Minimize wasted address space for 313 machines
    • Add 3 Tiny Core machines to prove functionality
    • It is okay to turn off the 3 BLUE end devices to save VM resources
  • Modify the router, DHCP1, and NS1 to provide the same functionality to the GREEN network that exists on the BLUE network

Assignment 2 – Complete Assignment 1 and then add a PURPLE network

  • Minimize wasted address space for 512 machines
    • Add 3 Tiny Core machines to prove functionality
    • It is okay to turn off the other end devices to save VM resources
  • Modify the router, DHCP1, and NS1 to provide the same functionality to the PURPLE network that exists on the BLUE and GREEN networks

RECOMMENDED GRADING CRITERIA: Same as deliverables with appropriate substitutions for added devices.

License

Icon for the Creative Commons Attribution 4.0 International License

Mastering Enterprise Networks Copyright © 2024 by Jacob Christensen is licensed under a Creative Commons Attribution 4.0 International License, except where otherwise noted.

Share This Book