TMG Firewall Name Resolution (Part 2)
If you would like to read the other parts in this article series please go to:
In my last article, we talked about some of the networking requirements and specifically the DNS server requirements for a TMG firewall environment. This time, let’s take a closer look at exactly how the Windows operating system resolves names and how the TMG firewall takes advantage of this process. Then we’ll discuss some of the best DNS server configurations for each type of TMG firewall deployment, and finally we’ll talk about some name resolution issues that can be tricky, so you’ll be able to avoid problems when you encounter them.
Of all the things that can cause the TMG firewall to not work correctly, or to exhibit poor performance, it’s name resolution that you’ll always see at or near the top of the list. We take name resolution for granted these days. If you’re not a DNS or WINS server admin, you probably haven’t even thought about name resolution much this week. It just works. At least, until it doesn’t. If you have thought about name resolution, it’s probably because something bad has happened in your name resolution infrastructure.
Evolution of name resolution
Back in “the olden days,” name resolution was easy – we were using flat networks and name resolution for NetBIOS names was accomplished, in many cases, using a broadcast mechanism. That was pretty nice because it truly did “just work.” What was not so nice was all the bandwidth that got sucked up by broadcasts on the slow 10Mbps networks we were working with at that time. After enough of those broadcast based network slowdowns, you probably figured out that you should do something about it before you lost your job. On those flat networks in those days, you could use LMHOSTS files to resolve names – remember those?
Of course, that was before TCP/IP became the dominant network protocol in use. When TCP/IP became the standard, it made our lives easier in some ways, but much more complex in others. We didn’t have to deal with broadcast nearly so much, since DNS servers became the de facto method for resolving names. However, because name resolution is so important, the Windows operating systems continued to support NetBIOS name resolution, so the broadcast issue didn’t go away completely. You’ll see how that’s the case later in this article.
Name resolution today
The modern Windows operating system’s name resolution process uses DNS as the preferred method of name resolution. If you recall, this has been the case since the introduction of Windows 2000. If DNS name resolution does not work, then the operating system will try to resolve the name via NetBIOS name resolution.
With NetBIOS name resolution, two methods can be used to resolve a name:
- Windows Internet Name Service (WINS). WINS is a NetBIOS name database that’s similar to DNS. However, instead of host names, WINS servers contain NetBIOS names, which are single label names in a non-hierarchical structure.
- Broadcast. If there is no WINS server, or the WINS server is not able to resolve the name for the client requesting name resolution, the NetBIOS broadcasts will be used. As you can guess, broadcast based name resolution is a bit limiting because it can’t cross subnet borders.
If your network does not have a WINS server, Windows will try to resolve the name by sending a broadcast for the NetBIOS name of the destination host. In modern networks, the NetBIOS name is mostly likely the same as the host name portion of the fully qualified domain name of the destination. Note that this doesn’t have to be the case – the NetBIOS name can be different from the DNS host name. However, in general the DNS host name and the NetBIOS name are going to be the same.
For example, when you run the command ping blah.msfirewall.org, Windows does the following:
Checks to determine whether it’s actually trying to ping itself – that is to say, it checks the local host name to make sure that the destination is not the local host name.
Checks the HOSTS file to find out if the name mapping appears there. If not, it moves on to a DNS query.
Checks the DNS servers that it’s configured to use. It will start with the first DNS server that’s configured in its DNS server search list. The operating system will send a query to the first server on the top listed NIC’s DNS server search list. This explains why it is important to have the internal interface at the top of the network adapter list.
After issuing the query, the DNS client will wait one second for a response. If the operating system does not receive a response from the first DNS server within one second, it sends the query to the top listed DNS servers on all NICs configured on the machine and waits two seconds for a DNS response.
If there is no response, the process will repeat in cycles of two, four, and eight seconds. If the operating system receives a positive response from a DNS server, the query process stops and it adds the result to the DNS cache. Note that you can monitor the number of name resolution failures by opening Performance Monitor, adding the Microsoft Firewall Service object, and monitoring the Failed DNS Resolutions counter.
Performs NetBIOS name resolution if no match is found in DNS.
NetBIOS on modern Windows operating systems
Current Windows operating systems will only use NetBIOS if all other attempts at name resolution fail. Windows continues to support RFCs 1001 and 1002. These RFCs define NetBIOS service for TCP and UDP, or NetBT. The RFCs also define something called a “NetBIOS Node Type”. The default configuration of Windows systems is BNode. You can change the NetBIOS Node Type setting by making changes in the Registry, as we discussed in the previous article. We didn’t go into the different node types, however, so let’s talk about that now. The possible NetBIOS Node Type values include:
Peer Node Type (PNode). PNode clients send queries to a NetBIOS name server, which in almost all cases is going to be a WINS server.
Mixed Node Type (MNode). MNode clients send a broadcast first and if broadcast name resolution fails it will send a query to the WINS server. You can think of this as a BNode + PNode configuration.
Hybrid Node Type (HNode). HNode clients send a query directly to the WINS server and if the query fails it performs broadcast name resolution, sends a broadcast. You can think of this as a PNode + BNode. Notice that this is the opposite of the NNode client behavior.
For example, consider the HNode client. The name resolution process would go like this:
The operating system checks the local NetBIOS name cache. By default, the NetBIOS Name Cache can contain up to 16 names and each name is held in cache for 10 minutes.
If the operating system fails to resolve the name from the local NetBIOS name cache, it will send a NetBIOS name query request to the primary WINS server configured on the NIC which is on the top of the network interface list. If this WINS server fails to respond, the operating system will try to contact all other WINS servers configured on each of the NICs on the system.
If the WINS servers are not able to resolve the name in the NetBIOS Name Query Request, the operating system will check the LMHOSTS file if LMHOSTS lookup is enabled on the WINS tab in the TCP/IP Properties dialog box. The LMHOSTS file is similar to the HOSTS file that is used for name resolution.
If the name is not contained in the LMHOSTS file, the operating system will send a NetBIOS local subnet broadcast (255.255.255.255). This enables the client to determine if the client is on the same subnet but not on other subnets since the local subnet broadcast will not be passed by routers.
Now that you understand the basics of how name resolution works for Windows operating systems, we’ve laid the foundation for taking a look at how we might best configure the TMG firewall’s name resolution settings based on the particular deployment scenario for the firewall. The best name resolution configuration will differ slightly from case to case, based on the deployment scenario. Keep in mind that, regardless of environment and configuration, you must remember to never configure TMG with a DNS server address on more than one physical network interface. If you have two or more NICs, DNS server IP addresses should be configured on only one interface and that interface should be at the top of the network interface list. And in almost all cases, the DNS server settings should be configured only on the internal interface.
In this article, we talked about how the Windows operating system uses different methods for name resolution. This is important because, without a solid name resolution mechanism, the system won’t be able to connect to resources by name. Of course, this can be a real problem since the system often is going to look for other machines based on names, not IP addresses. We saw that Windows uses DNS name resolution preferentially, and takes advantage of DNS to resolve names using the DNS databases contained in the DNS server. However, if good old DNS should fail, the Windows operating system will try to use NetBIOS name resolution to accomplish its name resolution task. However, this can take a long time, so you should configure your Windows systems as PNode NetBIOS clients. That way, they query a WINS server and if the WINS server doesn’t have the name, the system will give up. If they are configured as PNode clients and there is no WINS server configured on any of the system’s NICs, then it won’t even try NetBIOS name resolution. In Part 3 of this series, we’ll discuss how to configure the TMG firewall in a variety of deployment scenarios and which name resolution choices you should make. See you then! –Deb.
If you would like to read the other parts in this article series please go to: