24 Domain Name System Part 2 – Forwarding DNS

In the last lab, we configured our network so our devices could communicate via human-readable names rather than IP addresses. However, we did not build the ability to interact with Internet domains. In this chapter, we will reconfigure our DNS server to forward non-authoritative domain queries (such as www.google.com) to a public resolver and further extend our network’s capabilities.

Estimated time for completion: 25 minutes

Learning Objectives

• Demonstrate how to configure and implement a forwarding DNS server for Internet communications
• Learn how to implement a network address translation (NAT) rule between a LAN and WAN

Prerequisites

• Chapter 23 – Domain Name System Part 1

Deliverables

• Screenshot of RED1
  • Successful nslookup of Google
  • Successful ping of Google
• Screenshot of BLUE1
  • Successful nslookup of Google
  • Successful ping of Google
• Screenshot of the dig trace of Google
• Screenshot of GNS3 environment

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

DNS Hierarchy Explained

When you look up a website for the first time, you may notice it will load considerably slower when compared to subsequent revisits. This is because your computer does not yet know the web server’s IP address, and must ask around first before it can start making HTTP requests. However, once the domain-to-IP translation is known, various entities such as your browser, computer, router, and ISP servers all have local storage reserved for caching this information, which speeds up query resolutions. This is a feature for end-user convenience and saving bandwidth, but how does your DNS server know where to look when it receives an unknown domain?

Reference the diagram below while you follow these steps to understand the process.

1. The client device makes a DNS query to the LAN’s server for the domain <erau.edu.>

2. The domain is neither cached nor listed under any of its zones, so it forwards the request to a DNS resolver

3. The Resolver has a built-in list of all of the root DNS servers

• There are 13 root <.> servers in the world.  They are named sequentially from <a.root-servers.net> to <m.root-servers.net>
• Each one knows the location of the Top Level Domain (TLD) servers

4. One of the root servers will provide the address of the <edu> TLD server, which is sent back to the Resolver

5. The Resolver will query the <edu> TLD server for the <erau> subdomain

6. The subdomain DNS identifies the webserver for <erau.edu.> and sends this information back to the end user

Now that we understand how a Forwarding DNS server works, let’s build one for our network.

Phase I – Building Network Topology

This lab is an extension of  Chapter 23.  If you have not completed it yet, it is recommended that you do so first before continuing.  You will be building a topology that looks  like this:

1. Start GNS3
   1. Open the Chapter 23 Lab
   2. Save lab as a new project: LAB_10
2. Add a NAT node to the workspace and connect it to the router
   1. Select browse all devices
   2. Drag the NAT cloud to the GNS3 Workspace
   3. Connect the NAT Cloud to the router (in this case we are using ether1 on the router, but you can use any available interface)
   4. Start the router and open the console
   5. Configure the ether1 interface for DHCP by typing

      > ip dhcp-client add interface=ether1 disabled=no

   6. Verify that an IP address has successfully been assigned to the router (Figure 1)

      > ip address print

3. Start the remaining devices in GNS3
4. Ensure that the Authoritative DNS server is working properly and troubleshoot network connectivity as necessary

1. Navigate to NS1 and log in
2. Open the DNS daemon configuration file using any text editor you prefer

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

   1.  Modify the file to allow recursion and allow the labnets ACL access cache and recursion services

      recursion yes;

      allow-query-cache { labnets; };

      allow-recursion { labnets; };

   2. Add the forwarders directive inside options to allow our network to use Google’s server as our DNS resolvers

      forwarders {
      8.8.8.8;
      8.8.4.4;
      };

   3. Use the following image for configuration reference (Figure 3)
   4. Save and exit the editor
3. Check the configuration file for syntax errors

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

4. Restart the BIND9 service and check its status to ensure it is active and that all zones were loaded properly

   > systemctl restart named

   > systemctl status named

1. Open the router console
2. Configure the router with NAT to allow both subnets to access the Internet
   1. Create a firewall group called labnets which includes both subnets

      > ip firewall address-list add list=labnets address=89.30.80.32/27

      > ip firewall address-list add list=labnets address=192.168.5.0/24

   2. Add a NAT rule to the router’s forward-facing interface (in our example it is ether1). Since it has a dynamic address, its action will be set to masquerade (masq). Otherwise, this value should be set to “src-nat” with its associated static destination address

      > ip firewall nat add chain=srcnat action=masq src-address-list=labnets out-interface=ether1 disabled=no

      Command	Description
      ip firewall nat	Needed to access the control menu for configuring internet protocol firewall network address translation (NAT)
      add	add the following commands to the configuration
      chain=srcnat	Mikrotik calls the grouping of firewall rules “chains”.  In this case, we are telling the router to use the srcnat chain – because the source (src) NAT for our packets that originate from outside the network are from our NAT cloud.
      action=masq	For all packets, the router will make a masquerade (masq) action and replace the source port of the IP packet with one provided by the router.  This is done because our NAT cloud is using non-static IPs.
      src-address-list=labnets	the source (src) addresses the firewall should be looking for are the ones in the list named ‘labnets’.  In step 2.1 above we added two IP addresses to this list: 89.30.80.32/27 and 192.168.5.0/24
      out-interface=ether1	the outbound packet interface will be ether1
      disabled = no	keep this rule in

3. Test the name resolution service by looking up any public website of your choice from all devices within the LAN

   > nslookup www.google.com

   > ping www.google.com

   View Figure 4 for an example of the results

4. Open the NS1 server for a more detailed examination of the DNS hierarchy with the following Domain Information Groper (dig) utility command

   > dig +trace www.google.com +nodnssec

View Figure 5 for an example of the results

End of Lab

Screenshots for Printed Copies