23 Domain Name System Part 1- Authoritative DNS

In previous labs, communication between devices was verified via pinging IP addresses. With the addition of a Domain Name System (DNS) server to our network, these computers can be referenced by a more human-friendly name rather than a hard-to-remember string of numbers.

This lab will demonstrate the configuration and implementation of a basic primary authoritative (local) DNS server for multiple LANs.

Estimated time for completion: 60 minutes

learning objectives

• Learn how DNS works on an enterprise network
• Demonstrate how to configure zone files

prerequisites

• One (1) Ubuntu Server VM with Bind9 installed (created in Chapter 7)
• Three (3) Tiny Core Linux VMs (created in Chapter 5)

deliverables

• Screenshot of the GNS3 working environment
• Screenshot of PC1 successfully forward resolving the details of PC2
• Screenshot of PC1 successfully reverse resolving the details of PC3
• Screenshot of PC3 successfully pinging PC2 by name instead of IP

resources

• BIND9 Administrator Reference Manual – https://bind9.readthedocs.io/en/v9.18.16/
• MikroTik RouterOS Documentation – https://help.mikrotik.com/docs/display/ROS/RouterOS

contributors And testers

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

Phase I – Building the Network Topology

The following steps are to create a baseline network for completing this chapter. It makes assumptions about learner knowledge from completing previous labs.

1. Preliminary step in VirtualBox
   1. Create/clone 3 TinyCore virtual machines

      NOTE: For easy reference you can name them PC1, BLUE1, etc.

   2. Create/clone a fresh copy of the Linux Server VM with BIND9 installed
2. Start GNS3
   1. Create a new project: LAB_09
   2. Add the VMs created in Step 1 (Chapter 6)
3. Build a subnet – blue.net – with the following specifications:
   1. Use a randomly generated IPv4 network address space
   2. Use a network address that minimizes wasted IPs for 250 hosts
   3. Three client machines – Tiny Core Linux
      

      NOTE: You may use GNS3’s VPCS instead of Tiny Core, but this is not recommended since they do not have the tools dig or nslookup installed. These are tools that are necessary to help troubleshoot DNS. Furthermore, you may need to flush DNS caches to reliably see the Wireshark traffic. It is just easier to use Tiny Core end-user devices from the beginning.

   4. One Switch – Ethernet switch
   5. Label each Tiny Core client with the static IP address

      NOTE: This example uses the following IPv4 addresses:
      – Network: 192.168.5.0/24
      – Gateway: 192.168.5.1
      – PC1: 192.168.5.101
      – PC2: 192.168.5.102
      – PC3: 192.168.5.103
      

4. Build a second subnet – red.net – with the following specifications:
   1. Use a randomly generated IPv4 network address space
   2. Use a network address that minimizes wasted IPs for 5 hosts
   3. One DNS server – Ubuntu Server (NS1) with the static IP set

      NOTE: the netplan configuration file will always be a .YAML file, however, the name may change between releases or user modifications.  This screenshot is using a Ubuntu 22.04.X LTS .YAML file. Adjust as necessary.

      NOTE: This example uses the following IP addresses:
      – Network: 89.30.80.32/29
      – Gateway: 89.30.80.33
      – NS1: 89.30.80.35

      > vi /etc/netplan/00-installer-config.yaml

       

      

5. Add a MikroTik router to the workspace
   1. Connect both networks to the router
   2. Configure the router with static IPs on all active interfaces

      NOTE: This example uses the following IP addresses:
      – ether1 – 89.30.80.33/29
      – ether2 – 192.168.5.1/24

6. Label and organize your network as necessary.  When complete it should look like Figure 1

1. Configure the first client PC1
   1. Navigate to PC1’s console
   2. Modify the system startup script to execute the sethostname binary on boot

      NOTE: vi is the only text editor installed by default in Tiny Core.

      > vi /opt/bootsync.sh

      1. Modify the /usr/bin/sethostname line and replace box with PC1

         /usr/bin/sethostname PC1

         

      2. Save (write) and exit the editor
   3. Configure the first user with a static IP address (192.168.5.101)
      1. Modify the local startup script to include our custom interface configuration by typing

         > vi /opt/bootlocal.sh

      2. Add the following items to the startup script
         1. Kill the DHCP client program

            pkill udhcpc

         2. Set the static IP address, netmask, and broadcast address for the eth0 interface

            ifconfig eth0 192.168.5.101 netmask 255.255.255.0 broadcast 192.168.5.255 up

         3. Add a default gateway pointing to the router’s inward-facing interface

            route add default gw 192.168.5.1

         4. Add the local domain name blue.net to the local DNS configuration file

            echo “domain blue.net” > /etc/resolv.conf

         5. Append the address for the primary nameserver (NS1) to the local DNS configuration file

            echo “nameserver 89.30.80.35” >> /etc/resolv.conf

         6. Use Figure 4 for configuration reference
            

            

         7. Save and exit the editor
      3. Reboot the machine to apply the changes

         > sudo reboot

      4. Verify that the changes went into effect

         > ifconfig

         

2. Repeat Step 1 above for Tiny Core clients (PC2 and PC3)
3. Ensure full network connectivity by pinging all the devices from PC1 before continuing to the next section

1. Start ns1.red.net and login
2. Modify the machine’s hostname to ns1
   1. Open the terminal and assign a new permanent device name using Systemd’s hostnamectl binary

      > sudo hostnamectl hostname ns1

      NOTE: You can check the hostname in Linux by typing

      > hostname

   2. Add the new name in the hosts file in the /etc directory to prevent name resolution conflicts

      > vi /etc/hosts

      

      NOTE: If you notice that commands executed with sudo have slowed to a crawl, you may have forgotten to do this step.

   3. Reboot the machine to apply changes

      > reboot

3. Assign a static IP address, default gateway, primary DNS server, and local domain name
   1. Configure the server’s netplan YAML file

      > sudo vi /etc/netplan/00-installer-config.yaml

      

   2. Apply the new configuration

      > netplan apply

   3. Verify that the IP address was established

      > ip route

      

   4. Verify that the nameserver information is correctly pointing towards itself (127.0.0.1) and that the current domain is red[.]net
      

      > resolvectl status

      

4. Stop and disable Systemd’s time synchronization daemon to avoid unnecessary DNS traffic

   > systemctl stop systemd-timesyncd.service

   > systemctl disable systemd-timesyncd.service

5. Open the DNS daemon configuration file using any text editor you prefer

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

   1. At the start of the file, before the options directive, add the following access control list (ACL)
      

      

      NOTE: ACLs are important for preventing unauthorized access to machines or services. In this case, all subnets can use this server for DNS queries, however, clear specification is always good practice.

   2. In the same file, add the following commands in the options directive
      

      

      NOTE: There may already be configuration options here by default. Feel free to delete or modify them as you see fit.

      Command	Description
      version	Specifies the version number of the BIND9 server to return in response to a version query.  Official BIND9 documentation suggests that this be set to “not currently available” to avoid detailed service enumeration from threat actors.
      recursion	Defines whether recursion ( and caching of queries as a result of recursion) are allowed.
      empty-zones-enable	Enables or disables all empty zones. Setting to “no”, allows the mapping of private IP addresses to hostnames (such as 192.168.x.x) if they are used on the network. By default, this is set to “yes”.
      allow-query	Defines which networks, if any, are allowed to query its service.
      allow-query-cache	Defines which networks, if any, are allowed to query cached domains.
      allow-recursion	Defines which networks, if any, are allowed to access recursion services on the server.
      dnssec-validation	Defines whether DNS validation is enabled.
      listen-on	Defines which ports and addresses to listen on and respond to DNS queries.

   3. Save (write) and exit the editor
   4. Verify that the file was configured correctly

      > named-checkconf /etc/bind/named.conf.options

      NOTE: No response indicates that no errors were detected. Otherwise, read the error carefully and fix syntax as necessary.

6. Modify the service zone configuration file to specify the domains our server will have authority over

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

   NOTE: Two types of zones must be created for each domain: forward lookup zones and reverse lookup zones. The former translates domain names to IP addresses while the latter does… the reverse. AKA, IP addresses to domain names.

   1. Add the following forward lookup zones to the configuration file
      

      

      NOTE: Notice how the zone declarations end with a dot [.]. This is a fully qualified domain name (FQDN). Make sure to pay special attention when FQDNs are being used going forward. Forgetting to include the period is an easy typo, but it can cause a major headache when debugging later.

      Command	Description
      zone	FQDN of the domain the server will have authority over.
      type	Declares whether this machine is the primary (master) or secondary (slave) server for this zone.
      file	Declares the location of the database file for this zone.

   2. In the same file, add the following reverse lookup zones
      

      

      NOTE: Notice how the first tree octets in the zone declaration are in LITTLE ENDIAN order. This is known as a reverse ARPA address. Make sure to double-check everything for typos. In reverse ARPA addresses, you only need to declare the octets that will be static. For instance, the correct syntax for the network 176[.]55[.]0[.]0/20 would be 55[.]176[.]in-addr[.]arpa[.] since host addresses can range from 176[.]55[.]0[.]1 to 172[.]55[.]15[.]254. Because this CIDR mask allows for such a large range of host addresses, the third octet can vary in value, so its reverse ARPA address must be adjusted in response.

      Little Endian vs Big Endian

      Endian can be confusing to people who have never programmed computer memory space.  It means which end of a number goes first.  Remember back to second grade, numbers have a one’s place, ten’s place, hundred’s place, etc…

      Little Endian – Write the number starting at the little end (the one’s place).

      Big Endian – Write the number starting at the big number (the highest number place).

      Computer memory and programs use First In First Out (FIFO) and First In Last Out (FILO) mechanisms for various reasons.  Reasons that are beyond the scope of these labs.  It is enough to know that FIFO and FILO exist, making Endian notation necessary.

      SIMILE TIME:  Endian is like a crowded elevator with two doors; front and back.  The following people enter the elevator from the front doors.
      – Miracle (Enters first, stands at the back of the elevator)
      – Maribel
      – Scott
      – Rory
      – Halle
      – Lucian (Enters last, stands at the front of the elevator)

      If they travel to the 5th floor, the front doors open and Lucian will exit the elevator first and Miracle will exit the elevator last (FILO).

      However, if they travel to the 6th floor, the rear doors open and Miracle will exit the elevator first and Lucian will exit the elevator last (FIFO).

      Now, let’s say the people must exit the elevator in a particular order, so the usher needs to know which order to have the folks enter the elevator.  The usher knows that the 5th and 6th floors open differently, so when the ordered list is prepared, the usher will use Little Endian notation for the 5th floor or Big Endian notation for the 6th floor.

      Back to computers: Using an IP in Endian notation.  We can say our PC has an IP address of 192.168.1.5 so that translates to:
      – Big Endian Notation 192.168.1.5
      – Little Endian Notation 5.1.168.192

   3. Save and exit the configuration file editor
   4. Verify the file was configured correctly using the following command

      > named-checkconf /etc/bind/named.conf.local

      NOTE: Again, no response indicates that no errors were detected. Otherwise, fix file syntax as necessary. Pay attention to FQDNs.

1. Create a new forward data file for the Red subnet
   1. View the contents of the bind directory to see what database files are available

      > ls -l /etc/bind

   2. Copy any db file of your choice

      > cp /etc/bind/db.empty /var/lib/bind/db.red.net

      NOTE: Ensure the renamed file matches the one specified in Phase III when we declared our zones.  We used:
      db.red.net
      db.blue.net

   3. Configure the newly created file to act as the Red subnet’s forward lookup data file

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

      1. Rename the comment at the start of the file to reflect its new purpose

         NOTE: In these files, the semicolon denotes a note instead of a command.

         ; BIND9 forward data file for red.net.

      2. Below $TTL, add the following directive

         $ORIGIN red.net.

         NOTE: This will append the base domain name to any domain that is not terminated with a dot [.]. For example, the string ns1 will be interpreted as ns1[.]red[.]net[.]. Conversely, the string ns1[.] will be read as only ns1[.]. This is why paying attention to FQDNs is important, for strings such as ns1[.]red[.]net (without the terminating dot) will be read as ns1[.]red[.]net[.]red[.]net[.] by the server.

      3. In the Start of Authority (SOA) declaration, overwrite the local host information with the master DNS server domain

         @      IN     SOA     ns1.red.net. hostmaster.red.net. (

      4. Increment the Serial value by one

         2                ; Serial

         NOTE: Whenever this file is edited in the future, the serial number should be incremented again.

      5. Leave the Refresh/Retry/Expire/Negative Cache TTL values as their defaults for now
      6. Replace the current name server (NS) entry with all available domains (in this case, there is only one server)

         @      IN     NS     ns1.red.net.

      7. Since we only have one device in the Red zone, we need to map it with its static layer 3 internet (IN) address (A)

         ns1    IN     A      89.30.80.35

      8. Save the file and exit the editor
      9. Use this image for configuration reference
         

         

   4. Verify that the file was configured correctly and correct any errors as necessary

      > named-checkzone red.net. /var/lib/bind/db.red.net

2. Create a new reverse data file for the Red subnet
   1. Copy any db file of your choice

      > cd /var/lib/bind

      > cp db.red.net db.red.net.rev

      NOTE: We recommend the new file name ends with [.]rev to quickly identify it as a reverse lookup database file.

   2. Open the new reverse data file with any text editor

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

      1. Rename the comment at the start of the file to reflect its new purpose

         ; BIND9 reverse data file for red.net.

      2. Below $TTL add the following directive

         $ORIGIN 80.30.89.in-addr.arpa.

         NOTE: Once again, the octets are in LITTLE ENDIAN order. This dictates the base internet address (in-addr) that will be appended to any incomplete IP addresses later. For example, the IP address 35 will be interpreted as 35[.]80[.]30[.]89[.]in-addr[.]arpa[.] otherwise known as 89[.]30[.]80[.]35.

      3. In the Start of Authority (SOA) declaration, specify the master DNS server domain

         @     IN     SOA    ns1.red.net. hostmaster.red.net. (

      4. Increment the Serial value by one

         2      ; Serial

      5. Leave the Refresh/Retry/Expire/Negative Cache TTL values as their default for now
      6. Replace the current NS entry with the master DNS server domain

         @     IN     NS     ns1.red.net.

      7. Map the server’s currently assigned IP addresses (last octet) with its associated FQDN

         35   IN     PTR    ns1.red.net.

         NOTE: If you are mapping IP addresses with a shorted reverse ARPA address, then do not forget to include both host octets. For example, the address 176[.]55[.]2[.]15/20  would be represented as 55[.]176[.]in-addr[.]arpa[.] in the $ORIGIN directive and mapped as 15[.]2    IN     PTR      pc.example[.]com[.].

      8. Save the file and exit the editor
      9. Use this image for configuration reference
         

         

   3. Verify that the file was configured correctly

      > named-checkzone 80.30.89.in-addr.arpa. /var/lib/bind/db.red.net.rev

3. Repeat the above process and make another set of forward and reverse lookup files for blue.net
   

   NOTE: Don’t get confused.  The name server is in the red network.  That is why the SOA and NS will remain unchanged.

   1. /var/lib/bind/db.blue.net
      

      

      > named-checkzone blue.net. /var/lib/bind/db.blue.net

   2. /var/lib/bind/db.blue.net.rev
      

      

      > named-checkzone 5.168.192.in-addr.arpa. /var/lib/bind/db.blue.net.rev

4. Modify the permissions for the zone files
   1. Change the owner and group from root to the bind user

      > chown bind:bind /var/lib/bind/db.*

   2. Change the file permissions to have read and write access for both the owner and group

      > chmod 664 /var/lib/bind/db.*

5. Start the DNS daemon and ensure that all zones loaded properly

   > systemctl daemon-reload

   > systemctl enable named.service

   > systemctl restart named.service

   > systemctl status named.service

   

1. Start a Wireshark capture between NS1 and the router
2. Open the terminal of PC1
   1. Test the service by performing a DNS query on PC2

      > nslookup pc2

      

      NOTE: Since they are both in the same network, the blue[.]net domain does not need to be specified. To communicate with a device outside the LAN, the full domain name of the recipient is needed.

   2. In Wireshark, you should see a Standard query IPv4 (A) packet sent to NS1 and a Standard query response packet containing the resolution
      

      

      NOTE: You may see additional IPv6 queries (AAAA) in addition to IPv4. You can safely ignore these since we have not configured IPv6 on our DNS server.

   3. You can also perform a reverse DNS lookup with the nslookup binary to discover the hostname of a machine given its IP address

      > nslookup 192.168.5.102

      

   4. Again, you should see a Standard query hostname (PTR) packet sent to the NS1 and a Standard query response packet containing the mapped IPv4 address
      

      

3. From PC1, ping the DNS server

   > ping ns1.red.net

   1. If the full domain name is not given, the local name will be appended instead and the name will not be resolved

      > ping ns1

      

      NOTE: Notice how the domain ns1[.]blue[.]net was queried instead of ns1[.]red[.]net.

4. Congratulations! You have successfully configured an authoritative DNS server with static IP addresses in your network

End of Lab

Figures for Printed Document

There are no clickable figures in the digital edition which need to be placed here for the print edition.