If you would like to read the other parts in this article series please go to:
Introduction
In Part 2 of this series, we talked about some of the name resolution functionality included in the TMG firewall and things you could do to improve name resolution performance. This time, we’ll take a look at how to configure the firewall in a number of different deployment scenarios and determine what the best configuration options are in each of those cases.
Setting the ground rules
Windows name resolution always follows the steps I covered in the last article. That said, the deployment scenario should drive how you configure DNS settings on a particular TMG firewall. Regardless of environment and configuration, keep in mind that you never configure the TMG firewall with a DNS server address on more than one network interface. If you have multiple NICs, the DNS server IP addresses should be configured on only one of the interfaces and that interface should be on top of the network interface list. This is one of the most common reasons for poor name resolution performance when this fact is not heeded.
When the TMG firewall is in a workgroup, you still need to resolve names for internal hosts, and the general DNS recommendations remain the same: configure a DNS server address on one of the firewall’s interfaces. You should configure DNS to point to an internal DNS server and this DNS server should be configured to use forwarders or root hints so that it can resolve both internal and Internet host names.
Although this is the most common scenario that is encountered when it comes to DNS configuration on the TMG firewall, there are exceptions to this rule. In some deployments, the security team has set a policy where the corporate name resolution servers will not be allowed to resolve Internet host names. This is done to prevent internal users from directly accessing Internet sites and forces them to go out the TMG firewall’s proxy, which performs name resolution on behalf of the web proxy clients.
Options when DNS servers aren’t allowed to resolve Internel host names
If this is the situation in your deployment, there are some options that are available to you:
-
Configure the TMG Firewall to use a DNS server that does not resolve internal host names or one that resolves both internal and external host names but is not accessible to other computers on the network. You can enable full name resolution for internal and external resources by adding a DNS server that can use conditional forwarders. A conditional forwarder is a DNS server that can be used to forward DNS queries according to the DNS domain name received in the query. For example, a DNS server can be configured to forward all the queries it receives for names ending with endtoedge.com to the IP address of a specific DNS server, which in this case would be an internal DNS server that can resolve internal host names.
-
Make the TMG Firewall a DNS Server. In this design pattern, the TMG firewall has the DNS service installed on it and this DNS server can be configured to use a conditional forwarder for the internal domain and forwarders for external domains. This does require that you install the DNS role on the TMG firewall and that does increase the attack surface on the firewall. Another option is to create a secondary zone for the internal domain and use forwarders (or root hints) for external domains. Although this is a valid alternative and many TMG firewall admins will use this approach, it is not highly recommended because of the increased administrative overhead. Also, for security reasons, you don’t really want to add another service to the firewall, because now you will now have two components that could have separate maintenance windows.
Other scenarios
There is another (albeit unusual) scenario where the network doesn’t have internal DNS services and uses broadcasts for internal name resolution. You’ll never see this in an enterprise network but you might encounter this situation on very small networks run by small businesses that can take advantage of IPv6-based name resolution protocols. In this scenario, the TMG firewall uses an external DNS server of your choice for Internet name resolution. Note that this is the only time when you should configure the TMG firewall to use an external DNS server.
When the TMG firewall is joined to a domain, the firewall can take advantage of internal DNS services provided by the Active Directory infrastructure. The TMG firewall should be configured to use internal DNS servers and the addresses of the internal DNS server should be configured on TMG’s internal interface. Keep in mind that the same guidelines for how internal DNS servers resolve external names still apply, which means you should use forwarders or root hints along with separate DNS servers that cannot be accessed by any computers other than the TMG firewalls..
In a TMG Single NIC environment (which Tom referred to as “hork mode”), configure the preferred DNS server to use internal DNS servers and not use external DNS servers. The basic recommendation remains the same: use forwarders or root hints in your DNS Server configuration.
DNS misconfiguration
To get a better understanding of how DNS server configuration settings can create problems, let’s take a look at an example of DNS misconfiguration I’ve seen in the past. The person I was working with said that the TMG firewall was “very slow” and that web sites were coming up either very slowly or not at all and that his users were getting fed up with the situation. He asked if there was something I could do to speed up the TMG firewall, because otherwise he was going to have to get rid of it.
Using Microsoft Network Monitor, I determined that the delay was indeed due to name resolution problems. It turned out that the problem was due to the DNS server configuration on the TMG firewall. I took a look at the configuration and noticed that my friend had configured both NICs in the firewall to use internal and external DNS server addresses. Ouch. In addition, these DNS settings were stepping over each other to the point where the internal NIC was using an internal DNS server as its preferred server and external DNS as alternate, while the external interface was using the external DNS server as its preferred DNS server and internal DNS server as its alternate DNS server.
Many times I’ve seen TMG firewall admins configure the TMG firewall to use both an internal and external DNS server on one of the NICs. While it’s good that the configuration is only on one of the NICs, you still should not configure the firewall to use both internal and external DNS servers. The problem with this is that if the top listed DNS server fails to respond, the operating system will use the alternate DNS server and never switch back to the top listed DNS server unless the alternate DNS server fails to respond or until the TMG firewall is restarted. You can run into real problems when the TMG firewall tries to resolve internal names using an external DNS server and when it tries to resolve external names when it’s configured to use an internal DNS server that is not configured to resolve Internet host names.
Recognizing DNS problems
So what does it look like to you and your users when the problems are DNS name resolution related? Users will complain that web sites are slow to respond and authentication will take a long time because the firewall can’t find the domain controllers or is waiting for the name resolution process on the external server to complete the failure process so that it switches to internal DNS server. When you’re troubleshooting name resolution issues, you’ll see the following:
-
Delays in name resolution. When the TMG firewall sends a query and the DNS server does not respond before DNS timeouts take place, the TMG’s worker threads will be blocked pending DNS responses, causing the number of backlogged packets to increase, which consumes memory and can ultimate lock up the firewall.
-
Delays in authentication. If DNS servers cannot be found to help the TMG firewall find domain controllers, the TMG firewall will delay or fail to authenticate when firewall rules require authentication.
How TMG speeds name resolution
The TMG firewall maintains its own DNS cache that it can use to speed up name resolution. The TMG firewall’s DNS cache takes advantage of the Windows DNS resolver and is used to reduce the number of outbound DNS queries the TMG firewall has to make to DNS servers configured on its NIC.
Obviously, the TMG firewall can’t keep things in its cache forever, and needs to be able to flush entries from its DNS cache from time to time. The TMG firewall uses several methods to decide when entries should be removed from the DNS cache. These include:
-
DnsCacheNegativeTtl – This setting verifies whether the TTL provided by the original DNS server that answered the query and returned a record for that entry has been reached.
-
DnsCacheRecordMaxKB – This setting verifies whether the size of the DNS cache on the TMG firewall has reached a maximum threshold. The default settings is 10,000. When the TMG DNS cache contains this many entries, the oldest 25 percent of the entries in the DNS cache will be removed.
-
DnsCacheSize – The TMG firewall will check to determine whether the previous two events have occurred. If they have not, then the firewall service will scan the cache once every 30 minutes (by default) to remove cache entries where the TTL has been reached.
For more information on how to manipulate these values, check out the KB article 843127.
Finally, remember that when you’re troubleshooting name-resolution issues, the IPCONG /FLUSHDNS command can be confusing when performed on the TMG firewall. The reason for this is that the TMG firewall has its own DNS cache. In order to clear the TMG firewall’s DNS cache you will need to restart the firewall service. You can do this by running the command net stop fwsrv && net start fwsrv.
Summary
In this article, we went over some issues in name resolution that are related to deployment scenarios and domain membership. This brings us to the end of our series on name resolution issues with the TMG firewall. I hope you enjoyed it and please don’t hesitate to write to me if you have questions. Thanks! –Deb.
If you would like to read the other parts in this article series please go to:
