Some history: While Microsoft has made every effort to drop the NetBEUI protocol and the NetBIOS-over-TCP/IP support that legacy protocol required, reality had to set in somewhere. Legacy OS’s like W9x, WinME and even NT all use NetBIOS to a very large extent in their day-today operations. Since these OS’s still require functional networks in which to operate, and there must also be a method for upgrading the network from NetBIOS/WINS -based to DNS-based name resolution, NetBIOS/WINS name support still exists in W2K. Definitions:
W2K Name Resolution: There are two client services on each and every Microsoft OS that are capable of resolving computer names:
You’ll notice that the name resolvers try to stay on the local machine as much as possible. This is because if the name can be resolved locally, we can avoid any potential networking issues that may slow the whole process. Also, you should be aware that prior to W2K, all Microsoft OS’s resolved names using unqualified methods first. Want some more fun? Let’s look at the ISA scenario. What many folks will do is place DNS resolver IPs in both NICs, ISP in the external, local in the internal. While this seems to make sense, it’s actually very inefficient and you can actually cause huge timeouts this way. Remember that TCP/IP will choose the route for a given packet based on its destination, not where it found the data. This means that DNS entries are not really NIC-specific, it’s just more meaningful to the person entering them. W2K uses each DNS resolver in this fashion:
..and so on down the DNS list. Add the whole DNS suffix search list to each DNS query, (can be huge in large deployments or those with multi-level domain names), and you have a potential DNS disaster of gargantuan proportions. Another feature of W2K DNS resolver usage is that if one DNS server in the list of a given interface fails to respond (not an “I don’t know” answer; that’s different), then that whole NIC is blacklisted from the DNS search. So if DNS2 on NIC1 fails to respond to a query, then DNS1 on that interface will also be ignored for a while. For those reasons, it’s best to place all DNS resolver IPs in the internal ISA NIC. Now let’s add even more fun to the game; Windows (all flavors) can use DNS to resolve NetBIOS names. What, you say? Didn’t I just say that DNS resolved fully qualified names? Yes, I did say that. What I haven’t fully discussed yet is a neat feature called the “suffix search list”. This is a list of domain “suffixes” that can be appended to a NetBIOS name to help resolve it via DNS. Why would we want to do this? Well, say you have an internal AD-based domain called “mydomain.com” and you want to ping your ISA server from a client to test name resolution. You could type ping isa.mydomain.com, but your fingers are just a little tired from all the typing today, so you just type ping isa. Guess what; if you’ve set up the domain properly, you get: Pinging isa.mydomain.com [192.168.0.1] with 32 bytes of data: for your efforts. How is that possible, you ask (go ahead; ask)? This is the result of the DNS cache service using the suffix search list that is provided by the AD when you join a domain. If you were to open a command window and type ipconfig /all, you’d likely see something like this: Host Name : client What the DNS cache service is doing is appending “mydomain.com” from the suffix search list to “isa” to create “isa.mydomain.com” and passing that to the DNS server for name resolution. This way, we stay in the DNS name resolution stage instead of dropping to WINS / NetBIOS broadcasts. Neat trick, huh? Obviously, this doesn’t work too well for Internet names, but then it wasn’t designed to. It’s only to make internal name resolution more zippily. Wait, what’s that you say; you don’t have an AD structure in your LAN? Not to worry; you can add your own search list either manually (for static IP’s) or via DHCP settings and we’ll cover both of those. Static IP
ISA DNS behavior: ISA web proxy service also provides for a DNS “proxy” above and beyond any other DNS services that exist on the ISA server. This proxy is only available to WEB and Firewall clients, not SecureNAT clients. Bear in mind that the DNS proxy maintains a 6-hour TTL for all records, regardless of the actual record TTL. This means that any name resolved by the WEB proxy service will remain in the ISA DNS proxy cache for six hours, or until you restart the web proxy service. The good news is that if the client has a DNS resolver IP in its IP settings, they’ll use that first, potentially avoiding the ISA 6-hour DNS cache. Things to consider when deciding how to set up your DNS solution: 1. Active Directory domains require DNS DNS services are needed, period. What kind of DNS solution fits you best is something only you can decide. DNS services can co-exist with ISA, but the setup isn’t as simple as when the DNS server is a SNAT client. The following table will help you define your DNS requirements:
NOTES
CAVEATS
Drawing 1 Drawing 1 is what you might use if you only wanted Internet name resolution (in a dial-up scenario, for example). Note that the clients including the ISA server have the ISP DNS server as their preferred DNS. You can publish servers using this setup, but it requires the cooperation of your ISP. Generally speaking, if they offer hosting services, you’re good to go. The disadvantages are that you have to email or call them to get your zone data changed and you can’t add your internal IPs to that zone, so it can’t serve your internal network. ISA Setup: 1. Packet Filters: 2. Protocol Rules: 3. DNS Publishing:
Drawing 2 shows another single-DNS server solution, using the ISA server. While this seems like an easily implemented scenario, be aware that it’s quite different both in concept and setup. You’ll notice that the ISA has “127.0.0.1” as its preferred DNS resolver. This is common for DNS server setup; it tells the server’s DNS client service to use the local server for DNS resolution. Although the ISP DNS server isn’t shown here, you can still make use of it as a forwarder or just a second DNS server. ISA Setup: 1. Packet Filters: 2. Protocol Rules: 3. DNS Publishing: Drawing 3 Drawing 3 depicts a somewhat more complex, but more flexible scenario; the use of separate internal and external DNS resolvers. It allows you to separate the functions of the internal and external DNS zones, while still making them both available to the clients. The “Client DNS#” paths indicate which logical path the client would take to use a given DNS server. You can choose to limit the client DNS resolvers to the internal DNS server by using the external DNS server as a “forwarder”. This simplifies client setup, but still resolves external names easily. Either way, the ISA setup is the same. ISA Setup: 1. Packet Filters: 2. Protocol Rules: 3. DNS Publishing:
Drawing 4 depicts separate internal DNS servers with redundancy. This is the scenario you might choose for a W2K AD environment. DNS and AD coexist easily enough, so that your primary and backup ADs can also serve as your primary and secondary DNS servers. Make your internal zone AD-integrated, and there’s no such thing as primary or secondary DNS zones. ISA Setup: 1. Packet Filters: 2. Protocol Rules: 3. DNS Publishing:
Drawing 5 shows the last variation on a theme, where the DNS server hosting the external zones and the DNS server hosting the internal zone are both located behind the ISA server. This is the one for the seriously paranoid (or just severely burned) among us. In this setup, the internal DNS is totally invisible to the Internet, because it can’t resolve Internet names without forwarding to EXT DNS. All other setups allow the internal-zone DNS server access to the Internet via ISA. ISA Setup: 1. Packet Filters: 2. Protocol Rules: 3. DNS Publishing: |