Considerations for the TMG Firewall in Supporting Services (Part 1)

If you would like to read the other parts in this article series please go to:


In this series, we’ll tackle the topic of how to configure the TMG firewall to support various network favorites, and in Part 1, we’ll start with one of my old favorites. There are a number of issues that can complicate the lives of TMG firewall administrators; one that I hear about frequently is name resolution. The reason for this is that without an accurate and performant name resolution system in place, the TMG firewall can become essentially no more than a brick. This wouldn’t be the case if users and the TMG firewall’s supporting services used IP addresses to access resources, but fortunately, that’s not the case. Device access (for the most part) is done by name and the TMG firewall needs to be able to resolve those names to the IP addresses that allow the firewall to reach those devices.

For those who don’t work with the TMG firewall much, it must seem as if DNS is a pretty simple affair. Just assign a DNS server to the TMG firewall’s interface and there you go, right? That might work for a while, but you’ll find that sooner or later things will probably go haywire and you’ll end up wishing that you had done a little more research in advance before putting that TMG firewall into production. In spite of the well-worn canard “I don’t always test my solutions, but when I do, I do so in production,” you’re much better off knowing the best practices and implementing them before going into production. Trust me; it can save you a lot of grief. In this article, we’ll look at some of the “gotchas” involved in configuring TMG with DNS in a few different scenarios.

And even if you already have your TMG firewall in production, it might be a good idea for you to review some of the DNS best practices that we’re going to discuss in this article. You might even end up with a more stable and higher-performing name resolution solution – which can only make both you and your users happier.

Let’s look at the (short, you’ll be happy to hear) list.

Configure a DNS Server Address on only one NIC on your TMG Firewall

There are multiple deployment scenarios for the TMG firewall. One of them is the single-NIC configuration, which supports a limited number of TMG firewall features. If you’ve been a part of for a while, you’ve probably heard Tom refer to this as “hork mode.” That’s because it cripples many of the security features that are included with the TMG firewall. However, this single-NIC configuration remains very popular with organizations that are only interested in the firewall’s forward and reverse web proxy capabilities.

Configuring the DNS server settings on a single NIC TMG firewall is pretty easy; you just configure the DNS server addresses on that single NIC, since that’s all you have. If you have several DNS servers that you want the TMG firewall to use, then you configure them all on the single NIC. It doesn’t get much simpler than that.

Unfortunately, the simplicity begins to fade away when you have multiple NICs on your TMG firewall. If you haven’t worked with the TMG firewall before, or if you haven’t studied up on how to configure the DNS settings on the TMG firewall’s NICs, you might think that it would be most appropriate to put a DNS server setting on each NIC that is “logical” for the NIC.

What do we mean by that? For example, let’s suppose you have a dual homed TMG firewall that has an internal and an external interface. You might think that you probably should put an internal DNS server on the internal interface and an external DNS server on the external interface. However, if you think that, then you’re wrong.

When you’re configuring a multi-homed TMG firewall (and it doesn’t matter whether the firewall has 2 or 20 interfaces), configure a DNS server address on only ONE of the interfaces. It really doesn’t matter which one, but I generally recommend that you configure the DNS server address on the NIC that is closest to the network where the DNS server or servers you’re going to use reside. As we’ll discuss a little later in this article, the DNS server should reside on the corporate network and should not be a public DNS server.

Put the NIC with the DNS Server Address on top of Network Adapters List

Windows has what some might think is a funny way of determining which NIC to use for network services such as DNS and WINS. What it does is “crawl” the Network Adapters list in the Networks Node of the Control Panel, in order from top to bottom. The following graphic shows you what that list looks like.

Figure 1

This screenshot was taken on a Windows 7 machine, but the interface is the same on all modern versions of Windows (client and server). Notice the description that is provided for this configuration dialog box:

Connections are listed in the order in which they are accessed by network services”

OK, you have to think about what they mean here, because as is typical of Microsoft documentation and user interfaces, it’s not something that’s particularly intuitive. What they’re trying to say is that the system will use network services configured on the interfaces on this list, and it will begin with the one on top and proceed through the list. Consequently, what you need to do is move the interface with your DNS server address to the top of this list. You can do that easily enough, by selecting the interface and using the arrow button to move it to the top. Hey, it beats having to use a PowerShell cmdlet! 🙂

Use Internal DNS Servers for Name Resolution (Most of the Time)

In most cases, you are probably going to want to use your internal DNS servers for name resolution. There are a number of reasons for this, but the primary one is that in most cases, we want the TMG firewall to be a domain member. In order for the TMG firewall to be joined to the domain and use the Active Directory domain database to authenticate users, it will need to be able to resolve the names of your domain controllers and the DNS entries that are related to intra-domain activities. An external DNS server isn’t going to work, so you are going to have to use an internal DNS server.

It is also likely that you are using Active Directory integrated DNS servers, in which case you might want to consider adding multiple DNS servers to the DNS server list on the TMG interface that will contain the DNS servers listing. It’s always possible that one or more internal DNS servers might be unavailable at a given time, so it’s a good idea to have multiple DNS servers listed; this practice makes for a more resilient DNS name resolution configuration.

Things get a little trickier when you’re considering how the TMG firewall is going to carry out Internet host name resolution. We have our internal name resolution being handled by using internal DNS servers, but that isn’t going to guarantee anything related to Internet host name resolution. The good news is that there are a few options available here. Let’s take a look at them.

Some organizations are fine with allowing the internal DNS servers to resolve Internet host names on their own, using Root Hints. However, Root Hints can take a while, because name resolution using that method requires your own DNS server to walk the domain tree. In most cases, then, you’re better off using DNS forwarders that are hosted by your ISP. In that scenario, you get to benefit from the cached responses from all the other customers of the ISP, and there is a good chance that the ISP does a good job with performance and availability configurations on their DNS infrastructure. I say this because if the ISP didn’t do a good job at this, they would be hearing from hundreds or thousands of customers pretty quickly.

The above is primarily a solution for small businesses. Most larger organizations are not going to allow their Active Directory integrated domain controllers to communicate directly with Internet based DNS server, because there are some security issues involved with this. A compromised DNS server can do some pretty nasty things to the DNS servers that communicate directly with them. Because of this, most larger organizations will make the decision to configure their own DNS resolvers.

DNS resolvers are dedicated DNS servers that are Internet facing and therefore are specifically hardened in order to make sure that bad things don’t happen to them. Typically, these DNS resolvers are placed in DMZ networks in an organization’s own network, and the internal DNS servers use these resolvers as forwarders for Internet host name resolution. When the TMG firewall needs to resolve an Internet host name, it sends the request to the internal DNS server. The internal DNS server then forwards the DNS query to the resolver in the organization’s DMZ. The resolver then either resolves the name itself, or sends the request to another DNS server that acts as its forwarder. Sooner or later, the resolver gets the name resolved and sends that information back to the internal DNS server, which in turn sends it to the TMG firewall.

Ultimately, whether you have your Active Directory integrated DNS server resolve names directly or have them use corporate resolvers, the result is the same: point the TMG firewalls to DNS servers on the internal network and configure those server addresses on an internal NIC on the TMG firewall.

Non-Domain Joined TMG Firewalls

In most scenarios, the TMG firewall is going to be joined to the domain so that you’ll be able to fully leverage all the security features that the firewall has to offer. However, there might be times when you cannot join the firewall to the domain, or you don’t need to join the firewall or firewall array to the domain and have chosen not to do so. How do you handle DNS in that scenario?

In a non-domain joined scenario, there’s really no need to use internal DNS servers because you don’t need the DNS assist for domain location. However, if you’re publishing internal resources, you might want to leverage internal DNS for that, although you can use IP addresses instead of names for publishing rule configurations. If you don’t need internal DNS services, then you can configure the TMG firewall to use an external DNS server or DNS forwarder. Alternatively, you can do what many other TMG firewall admins do, which is to install and configure a DNS server on the TMG firewall itself. However, I don’t recommend putting a DNS server on the TMG firewall, because it just adds to the attack surface, which is something that you really should avoid on a firewall.

Something that you need to be careful about is name resolution for TMG firewalls that participate in a TMG array. External DNS servers won’t have any knowledge of the names of the array members, so you’re going to have to use a HOSTS file on each of the array members to assist you with intra-array name resolution. HOSTS files don’t scale very well and they can be a management nightmare, as you probably know if you’ve worked with them in the past, but if you have good processes in place, and make sure that all the firewall admins adhere to those processes, you shouldn’t run into too many problems.


This article is the first in a series that addresses issues concerning network services in relation to the TMG firewall. In this Part 1, we went over a few of the high level but critically important considerations that you’re likely to encounter when configuring DNS settings on your TMG firewall. In the next article in this series on TMG support services, I’ll talk about authentication and authorization support. See you then! –Deb.

If you would like to read the other parts in this article series please go to:

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