The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 1: DNS Resolvers, DNS Forwarders, DNS Caching and Recursion

If you would like to read the next parts in this article series please go to:
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 2
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 3


The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 4

Over the years I’ve found that the most common problem people have with their ISA Firewall is related to DNS setup and configuration. There are a number of reasons for this, such as DNS being inherently complex and how the ISA Firewall uses DNS varies with the client type being used. For these reasons and more, I decided that it might be useful to come up with a definitive guide for ISA Firewall DNS scenarios.

Discuss this article

The reason I’m using a scenario based approach in this series is that DNS, like most other networking services, does not lend itself to a one size fits all configuration. Configuration requirements vary with how you choose to deploy your outbound DNS name resolution configuration. What works for one company won’t work for another company and the different DNS scenarios will require different approaches to configuring the ISA Firewall and the clients located on ISA Firewall protected networks.

Before going into the details of the scenarios, I think it’s a good idea to get a based understanding of how DNS works. The goal of DNS (domain name services) is to provide a way to use names instead of IP addresses when connecting to network resources. It’s a lot easier to remember a name like www.microsoft.com instead of having to remember an address like 131.107.1.1.

When applications try to connect to a network resource based on a name, the application must first discover the IP address to send that connection request to. Applications can’t send a connection request directly to a name, because networks are based on IP addresses, and the Internet’s network routing infrastructure is based on those addresses – names are just for our convenience (for the most part – as names are very important when discussing SSL and IPSec related issues).

DNS Resolvers

The figure below shows the typical series of events that takes place when a client application needs to resolve a name before making the connection attempt. Note that column under DNS Resolver actually refers to a single server, as it makes it easier to understand the flow in the diagram.


Figure 1

The series of events in the figure above can be described as this:

  1. A client application needs to resolve the name www.microsoft.com to an IP address so that it can send a connection request to that address. The client system is configured to use the IP address of the DNS resolver machine. A DNS query is by the DNS client software on the client system to the DNS resolver. A DNS resolver is responsible for resolving the name for the client. In order to resolve the name, the DNS resolver will go through a process known as recursion. Steps 2 through 7 represent the DNS recursion process.
  2. After receiving the DNS query request from the client, the DNS resolver checks its Root Hints file to find the IP addresses of Internet DNS root servers. After finding the IP address of a Internet Root Server, the DNS resolver sends a DNS query request for www.microsoft.com to the Internet DNS Root Server.
  3. The Internet DNS Root Server is not authoritative for the microsoft.com domain, so it cannot provide the IP address of the host www.microsoft.com. However, it can provide information on the .com top level domain and returns to the DNS resolver the IP address of the .com DNS server.
  4. The DNS resolver sends a DNS query request to the .com DNS Server for www.microsoft.com
  5. The .com DNS server is not authoritative for the microsoft.com domain. However, it can provide the DNS resolver the IP address of the microsoft.com DNS server.
  6. The DNS resolver sends a DNS query request to the microsoft.com DNS server for www.mcirosoft.com. In this case, the micrsoft.com DNS server is authoritative for the microsoft.com domain, and contains a resource record for the www.microsoft.com host name.
  7. The microsoft.com DNS sends the IP address for host www.microsoft.com to the DNS resolver.
  8. The DNS resolver places the www.microsoft.com host name and it’s IP address in it’s DNS cache for the period of time noted in the TTL of the host record provided by the microsoft.com DNS server and then returns the IP address to the client that made the original request. At this point the client has the IP address for www.microsoft.com and can now make a connection attempt to that IP address on the Intenet.

DNS Forwarders

In the above example, we saw what happens when a DNS resolver performs recursion for a host name that isn’t included in its DNS cache. Another option available to you is to offload recursion onto another server. In this case, the DNS resolver becomes a DNS client of another DNS server. The DNS resolver becomes a DNS client to a DNS Forwarder in this scenario.

Discuss this article

There are some advantages to using a DNS forwarder. Some of these include:

  • The ability to leverage the larger cache on a DNS forwarder. For example, if you choose to use your ISP’s DNS server, the chances are that the DNS cache on their DNS server is much larger than the DNS cache that can be built up on your private DNS server
  • DNS forwarders can be placed on DMZ segments. This allows you to completely segregate computers from Internet access, such as Active Directory integrated DNS servers on network services segments
  • DNS forwarders can be dedicated as caching only DNS servers, so that these DNS servers are responsible for all Internet name resolution for all computers in the company and therefore have the potential of building a very large DNS cache in comparison to splitting up DNS server duties among dozens of Active Directory integrated DNS servers in the organization

The figure below shows what happens when you use a DNS forwarder for a name that hasn’t already been cached by the DNS resolver or the DNS forwarders.


Figure 2

The series of events described in the figure above can be described as this:

  1. A client application needs to connect to www.microsoft.com. The DNS client software on the client system sends a DNS query request to the DNS server configured on the system for www.microsoft.com
  2. The DNS resolver for that client is configured to use a forwarder for names for which is not authoritative. As a matter of record here, an authoritative DNS server is a DNS server that contains the actual host records for the domain in question. Since our DNS resolver does not contain the actual host records for the microsoft.com domain, it is not considered authoritative for microsoft.com. Since the DNS resolver is configured to use a forwarder, it will not perform recursion to resolve the name. Instead, our DNS resolver will act as a DNS client of the forwarder and wait for the forwarder to return the address for www.microsoft.com. The DNS resolver sends a DNS query request to the DNS forwarder for www.microsoft.com
  3. The forwarder is not authoritative for the microsoft.com domain and does not contain a cache record for the www.microsoft.com host. The DNS forwarder will need to perform recursion to resolve the www.microsoft.com host name to an IP address. It begins by checking it’s Root Hints file for the IP addresses of DNS Root Servers, and then sends a request to www.microsoft.com to one of the Internet DNS Root Servers.
  4. The Internet DNS Root Server is not authoritative for the microsoft.com domain, but it does have information about the IP addresses for the .com DNS servers. The Internet Root Server sends the IP addresses of the .com DNS servers to the DNS Forwarder
  5. The DNS Forwarder sends a DNS query request for www.microsoft.com to the .com DNS servers. However, the .com DNS servers are not authoritative for the microsoft.com domain.
  6. The .com DNS server does have information about the IP addresses of the microsoft.com DNS servers and sends this information to the DNS forwarder.
  7. The DNS forwarder sends a DNS query request for www.microsoft.com to the microsoft.com DNS server. The microsoft.com DNS server is authoritative for the microsoft.com domain and contains a host resource record for the host www.microsoft.com
  8. The microsot.com DNS server sends the IP address of the www.microsoft.com host to the DNS forwarder.
  9. The DNS forwarder caches the DNS record for the period of time designated on the TTL for that record and then returns the IP address to the DNS resolver.
  10. The DNS resolver caches the record for the period of time designed on the TTL for that record and returns the IP address for www.microsoft.com to the client that made the original request. The client application now has the IP address for www.microsoft.com and can now make the connection request to that IP address.

DNS Caching

I mentioned that DNS servers can cache information about records that were successfully resolved. All DNS servers have this ability because it reduces that amount of Internet traffic generated for DNS query requests. DNS caching can have a significant impact on how “quick” the Internet seems from the end user’s point of view.

The figure below shows the effect of DNS caching on DNS query requests.


Figure 3

The series of events described in the figure above can be described as follows:

  1. An application on a client system needs to connect to www.microsoft.com. The DNS client software on the system sends a DNS query request for www.microsoft.com to the DNS server configured on the client to use.
  2. The client’s DNS resolver receives the DNS query request and sees that the DNS query is for a domain for which it is not authoritative and that it has no cached record for the host www.microsoft.com. The DNS resolver forwards the query request to it’s forwarder.
  3. The forwarder has a cached record for www.microsoft.com and returns that record to the DNS resolver. Because the forwarder has a cached record, it does not need to perform recursion in order to resolve the name.
  4. The DNS resolver caches the record for www.microsoft.com and returns the IP address of www.microsoft.com to the client that made the original request.

What do you think will happen the next time a client makes a request to our DNS resolver for the host name www.microsoft.com? The answer is that the DNS resolver won’t need to even go to the forwarder, as it now has a cached copy and will return that information to the DNS client as along as the TTL on that record hasn’t expired.

In the scenario shown in the figure above, it’s not clearly evident what the advantage of the DNS forwarder might be in a DNS caching scenario, since when we have a single DNS resolver and a single DNS forwarder, the DNS resolver and the DNS forwarder will both contain cached copies. But imagine that you have dozens or even hundreds of DNS resolvers on your network. You can configure them to use a central DNS forwarder or a pair of central DNS forwarders. In that case, the DNS forwarders will contain cache information from all the queries made through all the DNS resolvers in your organization. The end result being that the resolvers will be able to much more quickly resolve names from the collective cache on the DNS forwarders.

Discuss this article

Summary

In this, the first part of our multipart series on ISA Firewall outbound DNS scenarios, we took a look at how some of the basic components of the DNS system work. We went over how DNS servers perform recursion by contacting multiple DNS servers on the Internet to perform host name resolution, we discussed DNS caching and how DNS caching reduces the total amount of DNS traffic moving over the Internet, and we saw how DNS forwarders can be used to leverage the DNS caching feature to centralize outbound DNS services. Now that you have the basics of how DNS name resolutions down, you’ll be ready for the next part of this series where I’ll discuss how various ISA Firewall client types use DNS differently. See you then! –Tom.

If you would like to read the next parts in this article series please go to:
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 2
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 3
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 4


About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top