24 Domain Name System Part 2 – Forwarding DNS

Jacob Christensen

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



  • 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


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

Diagram of narrative
Diagram used with permission of Cody Shinkyu Park

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:

Final result diagram
Figure 2 – The infrastructure we are building
  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

Phase II – Configuring the Forwarding DNS Server

Here we will make some changes to our name server’s configuration. It will still have authority over the LAN’s zones (RED, BLUE, and GRAY), but now it will forward all other requests to an outside resolver.

  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 {;;

    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

Phase III – Configuring the MikroTik Router with NAT

If you were to test pinging www.google.com at this point, you would likely receive the following error “Temporary failure in name resolution.” This is because the network does not yet know where Google’s servers are, let alone how to reach them. Let’s configure our router so we can start communicating with the Internet.
  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=

      > ip firewall address-list add list=labnets address=

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


To receive credit for completing this lab, submit the following 4 screenshots

  • 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


NOTE: – some websites block DIG requests, so if you get no response, try another site

DIG is short for a tool named “Domain Information Groper”.  It is used to interrogate DNS name servers.  We use DIG to perform DNS lookups and evaluate the returned responses.  It is flexible to use and can be used as a command line or batch function.  Visit the man pages in a Linux machine to view all the options available.

Assignment 1 – Explore the functions of the DIG tool
  • Use the dig manual in the NS1 server (man dig) to explore various ways of using the dig tool.  This is very helpful when assessing how much information your web pages reveal or performing reconnaissance on a target.

     Assignment 2 – Use DIG in batch mode

  • Use dig’s batch mode to conduct the same 4 inquiries as Assignment 1 on three different websites.  You will need to create a file to contain the website names.  Submit 4 screenshots as evidence:


  • Demonstrated using Dig to perform a DNS lookup
  • Retrieved all DNS records along with the IP addresses using Dig
  • Utilized advanced Dig commands to retrieve only the IP address associated with the target domain name
  • Used Dig to look up the target domain by its IP address
Screenshots for Printed Copies
Screenshot of commands
Figure 1 – Configuring ether1 for DHCP


Screenshot of commands
Figure 3 – Modified NS1 settings


Screenshot of nslookup
Figure 4 – nslookup for google.com


DIG results
Figure 5 – Results of running DIG on www.google.com


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