Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Tim Rains: We're going to be talking about Microsoft® Windows® Server 2003 DNS today. Two new topics we're going to be focusing on in particular are stub zones and conditional forwarding (slide 2). It will be a lively presentation, I hope. What we're going to do right now is start with our discussion of stub zones, and then move on to conditional forwarding after that.

Let's just jump right into it. To understand the benefit of using stub zones and what stub zones are, let's quickly review some background information (slide 3). There are two types of queries that clients can send when trying to resolve a name to an IP address: iterative queries and recursive queries.

Let's discuss iterative queries really quickly. An iterative query requests the best answer that a DNS server currently has for a queried name. The DNS server checks its cache, checks the zones it hosts for an answer, and it may only have a partial answer. Whatever answer it has, it returns back to the client. In the case of a partial answer, the client will try to use this partial answer, which should identify the next DNS server to talk to. That DNS server that it was referred to, it will send another query to that DNS server, still looking for the answer to its question.

Typically, only DNS servers use recursive queries. You won't see clients using [iterative] queries unless there is some sort of third-party application written to use an iterative query.

In this graphic (slide 4), just to very quickly summarize what an iterative query is, you have a DNS server relationship called the client, it sends an iterative query for let's say AD.reskit.local. The Server A that it asked for responds back, saying, "I'm not authoritative for these zones you're talking about, but I do know who is authoritative for the .local zone; ask Server B." So that response goes back to the client. The client then sends an area of query to Server B, and it says, "I'm not authoritative for reskit.local, but I do know who is authoritative for AD.reskit.local; go ask Server C." That response goes back to the client, which then asks Server C about AD.reskit.local, and the response comes back. Finally, we have an answer to our question. That's sort of how an iterative query works.

Next, the other type of DNS query is the recursive query (slide 5). When a recursive query is sent to a DNS server, the client is not expecting a partial answer. It wants a complete answer or an error code, such as "name does not exist" or "server failure," for example. Windows clients typically send recursive queries. DNS servers may also send recursive queries.

Here in this graphic (slide 6) we can see what a recursive query is. Again, our client sends a query for AD.reskit.local. This time, it's a recursive query, as opposed to an iterative query. The same DNS server that we saw in our last example accepts the query, looks at the query, and decides, "Okay I have to start resolving this query." This time, it doesn't refer the clients to another DNS server. It handles all this heavy lifting. It queries DNS Server A, gets referred to DNS Server B, which refers it to DNS Server C, and finally DNS Server C is able to resolve the query, sends it back, and then the DNS server sends the complete answer, the resolved name, back to the client that originally asked for it.

The difference here is that that DNS server that we sent the recursive query to is handling all this heavy lifting. It's doing all the iteration, as opposed to the client. Those are the two types of queries that clients typically use; so where do stub zones come into all this?

A stub zone (slide 7) is a read-only copy of a zone. You can't update it. This zone contains only enough data to identify the DNS servers that are authoritative for the zone and all the records for that zone. Basically what we have here is a zone that contains specific information on what DNS servers are authoritative for that zone. It doesn't contain all of the data for a given zone. We'll look at this in a little bit more detail.

Specifically, stub zones contain the following types of data (slide 8): first, an SOA record for the zone. An SOA record defines TTLs, authoritative servers, who the administrator is, and so on. NS records for the zone are name server records; these records identify which DNS servers are authoritative for this zone. And A records, otherwise known as glue records, allow us to resolve NS records to actual IP addresses so that we can send queries, connect across the network, and do all sorts of things.

Again, we have SOA records, NS records, and A records. This data is used to identify authoritative DNS servers that host the entire zone that we're looking for. Because a stub zone is read only, administrators cannot modify records within the stub zone. All changes must be made in the primary zone on the authoritative DNS server. If we want to add records to this zone, we can't go to the stub zone and add records. It's a read-only zone. It basically gets all its data from a primary server, and we're going to talk about this a little later.

All the changes that you make to a zone have to be done from that primary server. The primary server can host a zone that's not read only; it's read/write. So we can make changes there, and eventually the stub zone will pick those changes up. We'll talk about this in just a little bit.

Moving on to the next slide (slide 9), how does this read-only copy of a zone that contains this name server data help resolve a query? The stub zone in some cases will improve the efficiency of how a query is answered. It's all about efficiency. Because the stub zone can tell us which DNS server is authoritative for the zone we want to query, we don't have to perform more queries, looking for authoritative DNS servers. So we can reduce the number of queries it takes to resolve a name.

This results in less DNS traffic and hopefully faster response times. Let's see how the use of stub zones affects the efficiency of the iterative and recursive queries that we reviewed earlier in the presentation. Referring to this slide (slide 10), we can see the iterative query that we reviewed earlier; let's see how the use of a stub zone makes this more efficient.

Our client sends out an iterative query for AD.reskit.local, to DNS Server A. The difference here is DNS Server A has a stub zone for AD.reskit.local. In that stub zone it has some records, as we mentioned earlier — it has an SOA record, it has an NS record, and it has an A record or a glue record. The SOA record identifies the authoritative servers for that particular stub zone, TTLs, and all sorts of information. The NS record, in this case, tells the server that Server C is actually authoritative for AD.reskit.local. The A record, the glue record, basically tells us the IP address of Server C.

Because DNS Server A has this stub zone, when our client sends it an iterative query and asks it about this, that server responds back to the client; but this time it is able to tell the client who is authoritative for the zone. Instead of just getting him one hop closer, like we saw in the last example, where it said, "I'm not authoritative for AD.reskit.local, but I know who is authoritative for .local; go ask DNS Server B." Here it knows that DNS Server C is authoritative for AD.reskit.local, so it tells the client that. Now, the client sends an iterative query to DNS Server C for AD.reskit.local, and the answer to the question goes back to the client, and everybody is happy.

Here what we've done is eliminated that hop. We've eliminated that extra query that would have gone from the client to DNS Server B. So we referred straight to DNS Server C. This was a more efficient approach, because we had this stub zone on DNS Server A.

Next, let's take a look at how it affected our recursive query (slide 11). Again, our client sent a recursive query for AD.reskit.local to DNS Server A, and that DNS Server A has a stub zone on it for AD.reskit.local. And we can see that in the stub zone it's the same deal, we have an SOA record, an NS record, and a glue record that all say Server C is authoritative for AD.reskit.local.

When the query comes into DNS Server A, last time what we saw (and before we had a stub zone there) was DNS Server A would do iterative queries, first going to DNS Server A, then B, and then C, where it finally gets the answer. Here, DNS Server A at the top already knows that DNS Server C is authoritative for this zone. Instead of querying DNS Server A or DNS Server B, it simply queries C, gets the answer, and returns it to the client.

Again, in this case we've eliminated two steps in this query process. We didn't have to query Server A and we didn't have to query Server B. Because we knew that Server C was authoritative, we went straight to Server C, asked it, got the answer, and returned it to the client. Here we've gained a little bit of efficiency in the query process.

With that in mind, what stub zones actually do and how they can improve efficiency, let's talk a little bit about where they fit in, and when to use them in a network (slide 12). In Windows 2000 DNS, we do not have support for stub zones. This is again a new feature in Windows Server 2003. In a typical implementation where we're using Windows 2000 DNS servers, a zone is delegated from a DNS server hosting a parent domain to a DNS server that will host a child domain. So we are delegating from parent to child.

The server hosting the child domain can be configured to forward back up to the parent server or use root hints to find names in the parent domain. What we've done is set up a system where we've delegated responsibility for a child zone down to a server, and then we've configured that child server, if you will, to forward back up to the parent or to use root hints, so that the parent knows where to refer queries for the child zone to, and the child knows where to find records for the parent zone. We have this situation where we're using a delegation and then forwarding back up.

This is a typical implementation today; a lot of our customers use this type of implementation. The issue with this particular type of implementation is that the delegation from the parent to the child must be kept up to date each time a DNS server is added or removed in the child domain. Any time we add DNS servers down in the child domain that are going to be authoritative for that child domain, we have to go up to the parent and add those DNS servers to that delegation. So just go into the delegation on the Windows 2000 server and say, "These new DNS servers are also authoritative," so that the parent knows that it can refer clients down to those servers in the child domain when queried for records in the child domain. That can be a lot of work.

One of the reasons why the delegation was done in the first place, possibly, was to help out the administrator of the parent domain. The administrator of the parent domain could delegate the authority for these records down to the child domain, and then another administrator down in the child domain can administer those records. So the administrator in the parent doesn't have to deal with it, it's out of his or her hair, and everybody's happy.

The problem is if the administrator down in the child domain makes changes or adds or removes DNS servers, they then have to talk to the administrator or the parent domain and get them to update the delegation. And sometimes that can be a hassle.

It's important to understand that this configuration is still applicable, even when using Windows Server 2003 DNS (slide 13). Stub zones do not replace delegations. When a delegation is created for a zone, a name server (NS) record is added to the parent that identifies the authoritative server or servers for the child zone. When the parent zone is transferred to another DNS server, through a DNS zone transfer, that delegation data is transferred with the zone. When we use delegations, all the delegations that we use at the parent are transferred when we perform zone transfers to other servers.

If we have a primary server and then secondary servers, they all get copies of that delegation information. They all know about the delegations to the child servers down in the child domain. That's really important. For instance, if we said we're going to use a stub zone instead of a delegation, what will happen is any secondary copies of that parent zone will be missing the delegation information. They won't know about the DNS servers down in the child zone. This is because when a stub zone is created on the parent or child zone, the stub zone data does not get transferred when the parent zone gets transferred. Secondary copies of the parent zone will not contain any data on the child zone. This can turn out to be a dangerous situation.

If you choose not to use delegations and choose to replace them with stub zones, you run the risk of all these other DNS servers in your infrastructure not having any knowledge about the child zone, which can turn out to be a problem. And obviously this can lead to some name resolution issues. It's important to understand that delegations and forwarding, that particular implementation that we talked about earlier, is still applicable in Windows 2003 DNS, and stub zones do not replace delegations — they enhance delegations.

That said, let's move on to the next slide (slide 14). We recommend that you use delegations in the same way that they were used in Windows 2000. Again, if you're not familiar with delegations, forwarding, and the sort of scenario that I discussed earlier, you can take a look at a KB article I wrote around the time Windows 2000 was shipped, called "Integrating Windows 2000 DNS into an Existing BIND or Windows NT® 4.0-Based DNS Namespace"; it's article number 255913. This article discusses how to do the delegation and how to do the forwarding, step-by-step. If you're not familiar with that, have a look at that article. That article is still applicable to namespace designs using Windows Server 2003 DNS.

Where do stub zones come in then? You're telling me that I should use care when using these stub zones. We recommend using stub zones when delegations can't be used effectively (slide 15). For example, environments with disjointed namespaces could benefit from using stub zones. If we have a namespace — not necessarily parent and child, because we've already seen that the best tool that we have when it comes to parent and child is delegations — stub zones can be helpful if we have, for example, two parent domains that have different names. We talked about reskit.local and maybe another domain, mydomain.local; they're two different names, two different namespaces. It's disjointed — they exist in the same environment, but they're two separate names.

In this case, we're not doing a delegation. It makes sense to use a stub zone, so that we can put a stub zone on the DNS servers that host zones for, for example, reskit.local. We can put stub zones on those reskit.local DNS servers that contain authoritative information on which servers are authoritative for the mydomain.local domain. That way we don't have to go up to the root; we don't have to chase records all around to find out which DNS servers are authoritative for that other domain. So in a disjointed namespace scenario, stub zones can be very effective.

A nice feature of stub zones is that they're updated automatically (slide 16). We mentioned earlier that delegations are not updated automatically, it is a manual process. One of the alluring aspects of stub zones is they are updated automatically. As authoritative name servers are added or deleted to a zone, the stub zone automatically gets these changes. We're going to talk a little bit about this.

The new Microsoft Management Console (MMC) in Windows 2003 DNS provides the ability to refresh the stub zone copy. It does this three ways: Reload, which means basically a local reload; Transfer from Master; and Reload from Master. We're going to talk about each one of these briefly.

The Reload (slide 17): Reload will reload data from the zone's Local.dns file on the DNS server or from the Active Directory®. It just depends on where that stub zone is being stored. If it's Active Directory integrated, the stub zone data is actually stored in an Active Directory partition. If we issue a Reload command, we would reload it from the Active Directory. Or if it's just a standard stub zone, that zone is stored in the .DNS file. If we had a stub zone for reskit.local, it would be stored in a file called reskit.local.dns on the local hard drive of that DNS server.

Issuing a Reload command would simply reload the contents of that file into memory, and the DNS server would start using that data. Transfer from Master (slide 18) is a little bit different. A Transfer from Master forces the DNS server to check if the stub zone has expired. It looks at the SOA record and asks, "Has this stub zone expired?" If it has expired, it will transfer the zone from the master. The master is basically where we're getting the copy of our zone from. We're taking a copy of the master zone, we're making it read only, and of course we're only using specific records from that master zone.

Because the stub zone only stores SOA, NS, and A records, those are the only records that are transferred from the master. We'll talk a little bit more about this. Again, the key here with a Transfer from Master is if the stub zone has expired, it will transfer those NS, SOA, and A records from the master and reload the zone with them.

The next one on our list is Reload from Master (slide 19). Reload from Master asks the DNS server to transfer the zone from the master unconditionally. We're not checking if anything has expired, we're not checking whether the zone has expired. We're simply telling it to reload this zone, from the master, unconditionally. I don't care if it's expired or not, just reload the zone; and that's what happens.

One of the other features that has been changed from Windows 2000 is the Dnscmd.exe command-line utility has also been updated with new features (slide 20). This utility is used to administer DNS from the command line within batch file scripts, and so on. You can run some of these commands, as you see on the slide here: dnscmd /ZoneReload, /ZoneUpdateFromDS, /ZoneRefresh. If we use a /ZoneReload that's the same as a Reload command, it will reload a zone from a .dns file. If we use /ZoneUpdateFromDS, that will reload from Active Directory, or what they call directory services. A zone refresh is basically Transfer from Master.

The dnscmd command supports the Reload and Transfer from Master functions. It is noteworthy that it does not support Reload from Master. It supports the Reload function and the Transfer from Master function, but not the Reload from Master function.

Let's talk a little bit more about masters and how these zone transfers work (slide 21). Stub zone data is transferred to the DNS server hosting the stub zone from a master server, as I mentioned earlier. The master server can either be a primary or secondary for the zone.

Here on the next slide (slide 22) there's a graphic of the General tab under the properties of a stub zone. So if you were in the Windows Server 2003 DNS MMC, and you right-clicked on a zone and selected Properties, you would see this dialog box. And there is a General tab there. You can add multiple DNS servers to the list of master servers for a stub zone. That list that you see with those three IP addresses in it identifies which servers are masters for the stub zone that this particular DNS server is hosting. It's going to start at the top of the list and try to contact that master first, and then do the zone transfer from that master. If that fails, it's going to use the next one on the list. Then if that fails, it's going to use the next one on the list, and so on. You can re-order this list using those Up and Down buttons, and I think I'll mention that a little bit later as well.

Stub zones that are Active Directory integrated have an option called Use the list above as local list of masters (slide 23). This can kind of be a little confusing, but hopefully I can shed some light on this. This check box appears below the list of master servers for a stub zone, just like the one we saw in the last slide. Basically, it's just a little check box down there, and you're only going to see that dialog box when the stub zone is Active Directory integrated. So in a standard stub zone, you're not going to see this check box.

If you check the check box, you're going to see that you have the ability to fine-tune our list of masters (slide 24). What does this mean? By default the list of masters is stored in the Active Directory. Every DNS server that hosts the same stub zone uses the same masters. You have this list of masters; it's in the Active Directory. If you have a stub zone for reskit.local, every DNS server that hosts that stub zone for reskit.local is going to use that same list of masters that's stored in the Active Directory.

The local master's list option that I just mentioned allows administrators to specify a list of masters on a DNS server-by-server basis. This way, matches can be specified that are in the same site as a DNS server hosting the stub zone. What does this mean? We have Active Directory, we have this list of masters stored in Active Directory, and all the DNS servers that host that stub zone for reskit.local, for example, use the same list of masters.

I can go to one of those DNS servers now, hosting that stub zone, and I can check that box that says "use this local master's list," and I can specify a different list that's specific just to that DNS server, so that the DNS server can use a different list of masters to reload the stub zone from all of the other masters. Again, this gives the administrator flexibility, so that they can specify, let's say, DNS servers that are close to this particular DNS server hosting the stub zone, so that we're not doing transfers across WAN links, satellite links, or something like that.

When this check box is selected, this location in the registry is checked for a local list of masters (slide 25). Two values are used for master list management: LocalMasterServers and MasterServers. The check box basically toggles this registry value. The MasterServers value contains a list of masters (slide 26) that all servers hosting the stub zone use. Stub zones that have the local list of masters option set will use the list of masters specified in the LocalMasterServers list value. The local list of masters option can also be set using Dnscmd.exe, which we mentioned earlier.

That's it for stub zones. Next, I will give you an overview of conditional forwarding (slide 27). Of course, you'll probably have questions at the end of this, so just write down your questions concerning stub zones, and we'll get into conditional forwarding right now.

Windows 2000 DNS supports forwarding, what we'll call standard forwarding or conditional forwarding. What does this mean? This feature allows the DNS server to forward queries that it can't answer to a specified DNS server or a list of specified DNS servers. Basically, with Windows 2000, if a client sends a query to a Windows 2000 server, and that Windows 2000 server can't answer that query, and he's been configured with forwarders, he's going to forward that query to the first forwarder in the list. Then, he's going to wait for an answer.

That functionality is very important, as we mentioned earlier, in namespace design, because when we do delegations, typically we use forwarding as well. If you have, for instance, a DNS server that hosts a domain for your Active Directory, it probably knows about names within your domain. So it knows, for example, that reskit.local is the root of your Active Directory domain. So it knows all about reskit.local. But does it know anything about another domain called mydomain.local, or does it know anything about names out on the Internet? Probably not, and that's where forwarders come into play.

When it's asked to resolve names in a different domain that it has no knowledge of, it forwards a query to one of these forwarders on this list. To illustrate this a little bit more clearly, here we have a list, and this is from a Windows 2000 DNS MMC (slide 28). Here you can see you select the Enable forwarders check box. Incidentally, this is underneath the properties of a DNS server object in the MMC. So you right-click the DNS server and select Properties, and you see this Forwarders tab and property sheet. You select Enable forwarders, and then you enter IP addresses into the list box.

You can see that you have an Up and Down button, so that you can change the order of the forwarders. This is basically the most functionality you have with Windows 2000 forwarding, is this ability to change the order of the forwarders that you use. So you can select a server closer to you to be at the top of the list, and the server across a WAN link to be at the bottom of the list. This is the type of functionality we have in Windows 2000.

Conventional forwarding or standard forwarding (slide 29) has a few drawbacks. The forwarders are typically under a heavy load, because they are asked to resolve recursive queries. When we looked at our recursive query graphic earlier, it showed the client sending a recursive query to this server, and then that server had to perform many iterative queries to find that answer to send back to the client. That's basically what's happening here. We have a DNS server that can't answer a query, so it sends a recursive query; it forwards a recursive query up to the forwarders. Now the forwarder that forwarded that query has to do all the heavy lifting, and all the iterative queries to try to resolve that name. Then it's going to return the answer back to our DNS server, who will in turn return it back to the client.

Forwarders can be under a heavy load, because they're handling all these recursive queries. Also, this type of forwarding does not provide administrators with much flexibility. As I mentioned, you can basically change the order that the list of forwarders is used in, but that's sort of the extent of it.

This can be limiting when you are trying to design a complicated namespace. And we're going to talk a little bit about this later, but many customers have demilitarized zones, DMZs, basically a network between a couple of firewalls. If they want, for example, Active Directory replication into and out of that private network, that can be a problem, because they have to have these firewalls configured to allow queries through replication to go through. A lot of times conditional forwarding will solve design problems within a DMZ, where traditional forwarding is limited. We'll talk a little bit more about this later.

This type of forwarding can be limiting when trying to design a complicated namespace. Conditional forwarding is a new feature in Windows 2003 DNS (slide 30). Many of our customers have been asking for this feature, and here it is. Basically it allows forwarding based on the domain name that is being queried. We can configure a DNS server to forward queries to let's say one DNS server, one queried for reskit.local, and forward to a different DNS server, one queried for AD.reskit.local. So we have some flexibility here.

Now, when my DNS server is asked about reskit.local, it forwards to DNS Server A. When it is asked about AD.reskit.local, it forwards to DNS Server B; so we have a little bit of flexibility here when we get into complicated namespace planning.

Again, each domain name can be forwarded to a different set of DNS servers (slide 31). If a DNS server can't resolve a name, using its zone data or from its cache, it will still forward the query to the specified DNS servers for that domain name. Again, each domain name can have a different forwarders list. This graphic (slide 32) shows you what the conditional forwarders list looks like. You can see that queries for resources in the reskit.local domain are forwarded to a DNS server with an IP address of 10.0.0.1.

On this next slide (slide 33) you can see that a different set of DNS servers are specified for the AD.reskit.local domain. So we have three other DNS servers, none of which are the 10.0.0.1 that we saw in the last slide. This means that when this DNS server gets a query for reskit.local, it's going to forward that query to 10.0.0.1. When it gets a query for AD.reskit.local, it's going to start at the top of this list, 169.254.33.9, and forward the query there.

When the DNS server forwards a query to a forwarder on the list, it waits for an answer. If it doesn't receive a response, it tries the next forwarder in the list. The amount of time it waits is specified in the bottom-right corner of the Forwarders tab, as you can see. The number 5 that's circled on the slide shows you this is set for five seconds. The forwarders list can be re-ordered using the buttons you see beside it, the Remove, Up, and Down buttons.

As we've seen, queries for reskit.local and queries for AD.reskit.local are forwarded to different sets of DNS servers. Queries for all other DNS domains can be forwarded to another completely different set of DNS servers (slide 34). Here we can see that All other DNS domains is highlighted in the DNS domain box, and below we have yet another different DNS server from the other two domain names. This one is 192.168.1.100.

To determine which list of forwarders to use (slide 35), the DNS server compares the queried name to the domain name conditions in this list. It uses the longest matching domain name condition in the list. To give you an example of what I'm talking about here, we have an example query (slide 36), host.na.ad.reskit.local. In our conditions list we have reskit.local and ad.reskit.local, so we're going to compare our query, host.na.ad.reskit.local, to these two conditions, reskit.local and ad.reskit.local. The longest matching domain name condition is ad.reskit.local. It matches most of the queried name. The query is forwarded to the list of forwarders for that condition. In this case, I believe it was 169.254.33.9.

Again, you can set the forwarder time-out and reorder the forwarder's list for each domain name condition in the list (slide 37). You can see the five seconds and the Up and Down buttons again.

One note, if an administrator disables recursion on the server (slide 38) — so what would you do is start up the DNS server's MMC, right-click the DNS server in the MMC, and select Properties. Under Properties there is an Advanced tab, and there's a check box that says Disable recursion. If you select that check box and disable recursion on that DNS server, all of these Forwarders tab options will be unavailable; you won't be able to add any forwarders, you won't be able to delete any forwarders, it's all unavailable. I just wanted to point that out, because some administrator somewhere is going to do this, and then ask, "Why are my forwarders all dimmed?" It's because recursion has been disabled on the server.

In the registry, each zone basically has its own key (slide 39). If you have a look you can see it's in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones, and then the zone name. So we'd have, for example, reskit.local there. Underneath that key you will see a lot of related values. For instance, ForwarderSlave toggles recursion for a domain; ForwarderTimeout sets the forwarder time-out for the domain; MasterServers is basically your list of ordered forwarders for the domain. There are a lot of different values under that key.

You know all about conditional forwarding now, except when to use it. When should we use conditional forwarding? We recommend that you use conditional forwarding sparingly (slide 40). Use it to solve problems that traditional methods can't solve. Again, traditional or standard forwarding is still going to be used in the enterprise, absolutely. The only time you should be using conditional forwarding is when you have a problem that can't be solved using normal forwarding or traditional/standard forwarding.

For instance, environments with disjointed namespaces could benefit from this new feature. As I mentioned earlier, many customers have DMZs implemented, and they have expressed interest in this feature, because it will help namespace design in environments with tight security constraints. When we're trying to streamline name resolution, let's say within a DMZ again, instead of, for example, a domain controller inside your DMZ, that domain controller would have to be able to send queries inside the actual network to find the Active Directory, and so on.

Using forwarding, if that domain controller also had to go inside the network to Internet names, that wouldn't be a good thing, because now the DNS server sends them right back out the Internet, gets name resolution, and then sends it back within the DMZ. It would be nice if conditional forwarding was enabled, so that server, that domain controller within the DMZ, can find the Active Directory using DNS inside the network. And then for all other queries that end up being out on the Internet, just forward them off to the ISP or some other DNS server upstream, so that we don't forward them back inside our network. It's just a more optimized design.

That's conditional forwarding 101. Thank you for listening to the presentation.

Otto Cate: Excellent. Thank you very much. Before we jump into the Q&A, I'd like to share a couple of quick program notes with our audience.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the topic that we discussed today. In addition, one-on-one product support issues are outside the scope of what we're able to address. If you do need some more complex technical assistance, please contact a support professional, either through an online incident or by phone.

Let's get rolling into the first questions.

Tim: Right. If I understand the question, the answer would be yes. This may turn out to be a source of confusion for administrators. Suppose you put a stub zone on a machine that also has a delegation, so let's say we have a DNS server and we delegate a child zone down to a child DNS server, let's call it AD.reskit.local. If I also put a stub zone on that server, on that parent server for AD.reskit.local, so for the child, that stub zone is going to handle queries to the parent server for AD.reskit.local before the delegation actually works. When the query goes to the server, data from the stub zone is going to be used to answer the question, as opposed to the delegation. That could definitely be confusing to administrators when they try to troubleshoot problems or figure out what's going on. It's important to note that the stub zone data is used first. I hope that answers the question.

Otto: Are stub zones basically a standard that's used by other DNS vendors as well, or is this something that's only found in Windows Server 2003?

Tim: Good question. The concept of stub zones has been around for a while. They have been available in BIND DNS for quite some time. Any administrators who have worked in UNIX-based shops or who have used BIND DNS before are probably already familiar with the concept of stub zones. Our customers have been asking us about this feature for a long time, and we're happy to finally be able to offer it to them. I guess I should point out that is an RFC-based standard, if that's what they're asking.

Otto: Next question: Using root hints in the child domain for the parent is an accepted practice, along with the use of private root hints if the parent doesn't hold the root zone. Is that accurate?

Tim: Okay. I think I see what they're asking. Is this an accepted practice? Any time that you can go back up to the root, you're actually using DNS the way it was intended to be used. You're using the top-down flow of DNS to resolve your query. A lot of customers bypass or short circuit that by using forwarders. We delegate down to the child, the child would forward back up to the parent, and then the parent would have the ability to use root hints, let's say, so everybody is happy. The recommended method is to use root hints whenever possible, because you're using the top-down flow of DNS.

Altering root hints is completely acceptable. I guess I shouldn't say we don't have very many customers who do it. We have some customers who do it. Sometimes they run into problems doing that. But certainly any time you can use DNS the way it was intended, using it top-down, that is good method.

Otto: Is there a standard TTL, I assume that's "time to live," for the stub zone? And how would we update that on individual records?

Tim: I'm looking at the console of a Windows 2003 DNS server right now. If I take a look at the standard TTL of a stub zone, it is set to one hour, which is basically the TTL for all our zones, by default, if I'm not mistaken. All of this property sheet here that I'm looking at, which has the SOA details for the stub zone, they're all unavailable options, because the stub zone is a read-only copy of the original zone.

If you wanted to change the TTL for the zone, you'd probably do that on the original parent that's hosting the zone. You go to the original zone and change the properties there. If you go into individual records within the stub zone, again, it's all read only. If you look at the properties of any of the records, you're simply looking at the same properties of the stub zone that I mentioned earlier. Again, if you want to change individual TTLs on records, you do that at the original master that hosts the primary for the zone.

Otto: Would that also apply if I wanted to modify the TTL for cached DNS queries?

Tim: You bet.

Otto: Excellent. Thank you. Moving on to the next question: Can't you use stub zones to keep the delegation records updated between the parent and child DNS servers?

Tim: No. Unfortunately, you can't. These are two different mechanisms. That was my first impression, when I first started playing around with stub zones. It was, "These actually replace delegations. This is great news. I don't have to keep the delegations up to date anymore."

The reality is, as I mentioned earlier in the presentation, there are two dangers here: one is the stub zone data gets used before the delegation does. And two, if you don't have a delegation, if you use a stub zone instead of a delegation, if you're doing zone transfers because you don't have any delegation information in the parent zone, then for everyone you perform zone transfer to, none of them are going to understand that there's a child zone and that there's a delegation in place. You'd have to make stub zones on every single one of those servers that have secondary copies of the zone, which can be an administrative hassle as well.

There are two different mechanisms; the stub zone is a completely different zone from the parent zone, and therefore delegation records are actually kept in the parent zone, separate from the stub zone. So they are completely different mechanisms.

Otto: There is a follow up on the root hints question that we asked a little bit earlier: Rather than setting up child.parent.tld to forward to parent.tld, you're saying that it's preferred to add or modify the root hints for parent.tld?

Tim: Yes, that's the preferred method. In that scenario, the KB article I wrote all that time ago, 255913, which I mentioned earlier, walks you through the step-by step method of forwarding back up to the parent. Realistically, if you wanted to use DNS top-down, every single time, which is the way you're supposed to do it, you wouldn't forward back up to the parent, you would actually use root hints, which then would leverage the power of top-down DNS. That's the preferred way to do it.

Forwarding it is completely valid, and that's the way the vast majority of our customers do it. If you call into a PSS engineer and tell them, "I have this problem, Active Directory is not replicating" or something like that, that's the way they're going to try to help you fix your DNS to get everything to work. That doesn't necessarily mean that it is the best and only way to do things. Certainly using root hints can also be a valid way of configuring the network.

Otto: I believe I need to set permissions to allow the DNS that hosts the stub zone to transfer from the master. Is that correct?

Tim: They might be talking about how they want to limit zone transfers to servers that have stub zones on them. One of the things that is a little different about stub zone zone transfers is that it's not really a zone transfer at all. The mechanism that the zone transfer uses is not the same as a normal zone transfer.

Because a stub zone only contains the SOA record, NS records, and glue records, an entire zone transfer is not necessary. Inside a zone, let's say reskit.local, we would have an SOA record, maybe some NS records, and some glue records, but we'd also have all the host records, MX records, and all the other types of records that are normally used in a network. Because we don't need any of those records in a stub zone, we don't transfer them.

In fact, if you were to do a network monitor trace of a zone transfer from a master to a DNS server hosting a stub zone, the first thing that would happen would be the DNS server hosting the stub zone would query its configured DNS server to find out who is authoritative for that stub zone. If it's already configured, it will just ask for the SOA record to make sure that it's authoritative for that stub zone. The answer will come back "yes" on authoritative.

Next what it will do, typically, is it will use TCP. It will connect to port 53 through TCP. And then it will send a series of queries, after it is connected. First it will query for the SOA record for our stub zones, so let's say reskit.local. It will get the SOA record back. Then it will send a query for NS records for reskit.local. It will get the list of NS records back. Typically, because this is a Microsoft DNS server, we should get the glue records, along with those NS records in the additional record section of the packets. Then all the NS records come back, all the glue records for those NS records, the TCP session is shut down with a four-way handshake, and we're done.

It's not really the same type of zone transfer that you have between a primary master and a secondary server, because we're not getting all the same records. Because of this, the security around zone transfers to stub zones is quite a bit different.

We're sending individual queries, and really there's no way to secure your server from individual queries. It was designed to answer queries, and that's what it's doing in this case. We have three queries, a query for an SOA record, a query for NS records, and a glue record query, if it's necessary.

Otto: Excellent. Can you explain the difference between a secondary and stub zone?

Tim: It's a good question. A secondary zone is a read-only copy of a primary zone. Let's say we have a primary zone on DNS Server A for reskit.local. A secondary zone is a read-only copy of that zone, of that entire zone. All of the records in that zone, MX records, all of the A records, records for your Web servers, records for all your hosts on your network, and so on; there are many different record types that our customers use. All of that data is in a secondary zone. One of the differences between a secondary zone and a stub zone is that the stub zone only contains a subset of those records, as I mentioned earlier. It only contains the NS records, the A records, and the SOA records, and that's it. It's quite a bit different, in that it only contains a subset — just enough information to identify authoritative servers.

However, the secondary copy of the zone holds all the records and can answer queries authoritatively for that zone. The stub zone simply refers clients to authoritative servers. It helps the name resolution process, and it doesn't resolve the names itself. Although it can lead to that.

Otto: Great. We have a follow up to one of the time-to-live questions that we addressed earlier, about individual records. They're wondering if we can provide a little more detail on the methods that should be used. Is there a registry key, for instance, that can be edited?

Tim: The time to live on the zone, maybe what they're asking is: Is there any way to change the TTL on the stub zone as opposed to doing it on the primary zone? The answer is, I don't know.

The stub zone is supposed to be read only, and it is refreshed from the master. Most of the properties are unavailable, because it is read only. Any changes should be made up at the master. Now, if you're asking about TTLs and that type of thing up in the master, you can either use the GUI, or yes, there are keys underneath the zone for TTL and that sort of thing. I think those are documented in the Knowledge Base.

Otto: Great. Thank you very much for the extra information there.

The next question: Can a stub zone use a dynamic master server list, using NS records in the stub zone as a list of master servers?

Tim: Right. That's a good question. Basically, the person is asking, "I have this list of NS servers that may change from time to time, and I have this list of masters that has set all my stub zone properties. It would be nice that if the NS records for this zone changed, the list of masters for the stub zone would change as well." I believe that they're all static. You go in there and you change the order manually, you can remove and you can add, but that list is not dynamic, as far as I know.

Another thing to note along the same lines is with the DNS client, it does some optimization. If it detects that on one of the servers, the Round Trip Time (RTT), is faster when querying one DNS server and slower on another one, it will re-order the list dynamically. That doesn't happen here with the list of masters. It's a static list and doesn't change, to my knowledge.

Otto: What sort of load necessitates the use of stub zones? It would seem that stub zones are used to avoid the cost of zone transfer to the querying server. Is that correct? If the environment was truly multimaster, then there would be no need for stub zones, because every zone to all resources would be on each server. Then you could just configure each server to be recursive. Is that pretty much accurate?

Tim: It's actually a really good question, and the person is making some good points here. It's true that you could have secondary zones all over the place, but typically customers in an enterprise environment don't want to do that. They want to have their own autonomous namespaces. Even if you have a massive namespace and it's going to be divided up into smaller chunks, typically you have administrators for each one of those chunks. They don't want to be dealing with another administrator, because of zone transfer issues, or the issues to set up a zone transfer, or something like that.

Plus, the other aspect of this is security. With secondary zones you can set up a list of servers that you'll do zone transfers to, and you'll only do zone transfers to those particular servers. If you had a small enough environment, you could have secondary zones transferred all over the place. That would really defeat the purpose of top-down name resolution. You want to minimize the amount of administrative overhead and make DNS work for you.

Any chance you get to go up to the root and work your way down, and find out what servers are authoritative, and resolve the name that way, it's going to beneficial, because that will lead to the least amount of administration on your network.

Where stub zones come in, and this person pointed it out, is it does in some cases reduce the cost of name resolution, where we are doing fewer queries to resolve a particular name. We don't have to chase around and find out who's authoritative for a zone; we already know who is authoritative for the zone, and we just go ask them.

Otto: How does netmask ordering affect conditional forwarding?

Tim: That's a good question. I don't think it does. I haven't read anything on that yet, but the netmask ordering typically is done on the client, and there is some optimization on the server as well, when the client queries for a name and we get a list of IP addresses, let's say a referral list. That list can be optimized so that the DNS server that's on the same subnet as the client is at the top of the list, and the client is smart enough to use that DNS server, as opposed to any other ones in the list.

That type of optimization is already in the product in some places. But to my knowledge, I don't think it's related to conditional forwarding. I could be wrong, but I just don't know at this point.

{Follow-up answer: Netmask ordering does not affect conditional forwarding. There is no relation between these two features.}

Otto: The next question, this is kind of a scenario question: We have a client running Windows XP on a small corporate network with Windows 2003 Server DNS, and it has access to the Internet through ISA or some other application. The Internet ISP has DNS servers as well. We're wondering when opening the client network connection and looking at the network connection details, which DNS servers should be listed? And what kind of order should be expected?

Tim: It actually turns out to be a fairly complex question, because it depends what they have on the client. Let's say that they're using ISA Server. ISA Server is going to handle some of the name resolution for you, in some cases. For instance, you have the firewall client or Winsock proxy client installed on the client, and we try to resolve the name that has more than one dot in it, so something like AD.reskit.local, which has two dots in it. That name is sent to the ISA Server, and the ISA Server is going to do name resolution, to try to resolve that name, and then send a response back to the client.

If we're just talking about a Web query, again it depends how many dots are in the name, what the exceptions list on the browser looks like, and all of that. ISA takes care of a lot of the Internet name resolution for us. Now, I think the key here is that your clients are probably a member of a domain. If they're a member of a domain, they have to be able to find domain controllers and other resources: LDAP servers, Kerberos, and all that.

Those clients are going to have to use a DNS server that's capable of finding all the records used for your Active Directory infrastructure. Those four underscore zones that are kept for your forest — _TCP, _UDP, _sites, and _MSDCS — your clients have to be able to find those records. Typically, the clients point to an internal DNS server, and that internal DNS server hosts those records. And they're able to query that server and find the answers.

Typically, when they want to go out to the Internet they ask the same server, and that server, either using root hints or forwarders, goes out to the Internet, resolves the name, brings it back, and gives it back to the client. Where stub zones may be an effective tool is if we had a disjointed namespace within our environment.

Some clients are members of reskit.local and some clients are members of mydomain.local. Let's say we merged companies, and they're both within our namespace. It's just completely disjointed. It makes sense for us to just go ask the server that's authoritative for the other domain about resources within that domain, as opposed to going all the way up and trying to find who is authoritative, and then going to ask that server anyway.

Stub zones and conditional forwarding can lead to some optimizations there. Under normal circumstances, in the environment that they described, there are a lot of things going on there. ISA is doing some name resolution for you. And it can lead to a complex environment. What you want to do is keep things simple. With the clients, if they can continue to use the DNS server they always used, and that DNS server can resolve Internet names and can resolve internal names, it's very simple.

Unless you have some performance issues or something like that, you probably won't use conditional forwarding or stub zones in that situation.

Otto: Next question. Do you support views in BIND 9?

Tim: Not that I know of.

Otto: Can you give us a little bit more detail regarding recursion and iteration? It looks like they're just asking for some more detail on those subjects, in a nutshell.

Tim: In a nutshell, if you have a Windows client, your Windows client will send out a query. Let's say you open up Internet Explorer and you type in a name, www.microsoft.com, that name has to be resolved to an IP address so that the http connection can be established to their Web server.

What happens is your client sends a recursive query to its locally configured DNS server. The recursive query tells the DNS server, "Look, I want an IP address for this name. Don't come back with a partial answer. I don't want to know where the .com root servers are. I don't want to know where any partial answers are. I want the full IP address of this destination that I want to go to."

The DNS server then could use iteration to find the answer. Meaning now he's going to go up to the root of the DNS and ask, "Who's authoritative for .com?" It will get a list of DNS servers. "Who's authoritative for Microsoft?" It will get a list of servers, and will go to those servers. "Can you tell me what IP address www.microsoft.com resolves to?" It will get the IP address and then send that back to the client.

The difference is, recursion really means give me a completed answer, do not give me a partial answer. Iteration is a way that we find a complete answer, so we find it one step at a time. Iterative queries are typically issued by DNS servers that are trying to resolve names for clients. Clients rarely send iterative queries. I can't think of an instance where our clients send an iterative query. Maybe there are some third-party applications or something that sends iterative queries. I wrote a utility called DNSLint that ships with the Windows Server 2003 Support Tools. In some instances I used iterative queries there. But for the most part, clients don't send iterative queries. I hope that answers the question.

Otto: Overall, it sounds like conditional forwarding in stub zones might provide the same features, but the conditional forwarding is easier to configure. Why would I use stub zones instead of conditional forwarding?

Tim: That's a really good question, and I think that question will be asked a lot. One of the big differences there is that conditional forwarding obviously is going to be processor intensive. Every time a query comes in, it's compared to the conditions in that list. If you really load up that list, if you create lots of conditions, you're going to start running up the processor utilization on your DNS server. Typically, you don't want to do that, you want to avoid that. In cases where you're asking, "Should I use stub zones or should I use conditional forwarding," stub zones are probably going to be a little bit easier on the DNS server, and your DNS server is going to be a lot easier for it to process, using stub zones rather than conditional forwarding.

Really, it comes down to if you have a need to use these features, as I mentioned, we sort of recommend that in disjointed namespace situation, in DMZs, in situations where conditional forwarding doesn't work effectively, or where stub zones can provide optimization, that's when you should use them. But just because they're in the product doesn't mean you should run out and just start using them without a specific problem to address.

Otto: Given the changes in Windows Server 2003 Kerberos to create transitive cross-forest trusts, and the acquisition and merger of companies, it's foreseeable there that there will be increasing amounts of disjoined name spaces in the enterprise. What are the possibilities of going to a truly multimaster Active Directory/DNS configuration where each server is authoritative for all zones contained within the organization? Is there a point where the incremental transfers of resources would be too intensive, possibly necessitating the use of delegation?

Tim: It's a good question, and it's a complex one. I think that we've taken a good first or second step toward that, in that with Windows 2003 DNS we now have the ability to use application partitions. Application partitions allow us to replicate DNS zone information outside a domain boundary.

I wrote a KB article a while back that kind of describes this. With Windows 2000 DNS, when you have an Active Directory-integrated zone, that zone only gets replicated to other domain controllers within that domain. If we have an Active Directory domain called AD.reskit.local, and that is the root of my Active Directory forest, that zone AD.reskit.local gets replicated to all the other DNS servers in the same domain, AD.reskit.local. But they don't get replicated to, for example, reskit.local or child.AD.reski.local, it's only within that domain. In Windows 2000 a domain is a replication boundary and a security boundary.

With Windows 2003 DNS and Windows 2003 Active Directory, you now have the ability to make application partitions. Your DNS records are going to be in a DNS partition within a system partition, and that gets replicated around a domain. Now you can move those records out into an application partition, and then you can pick and choose which domain controllers you want that partition to replicate to. So that if you don't want them to replicate to all domain controllers within a domain, you don't have to. You can specify replicating them to the machines that you want to replicate to.

I think that application partitions are the first big step toward doing what this customer is asking about.

Otto: Can I configure a stub zone pointing to a Windows 2000 SP3 DNS Server? The stub zone itself would reside in a Windows Server 2003 environment.

Tim: The answer is, yes, you can. Because the zone transfer basically works with a series of queries — a query for the SOA record, a query for the NS records, and typically the glue records come across with them — you can do that against a Windows 2000 DNS server, you bet.

Otto: The next question: Is that a good practice, to use both stub and delegation on the same server for fault tolerance?

Tim: It's a good question. I think I mentioned this a couple times. You can do that, you can add a stub zone onto a server. Let's say we had a DNS server and we've delegated a zone down to a child domain. We delegate AD.reskit.local from the parent down to the child. We could also add a stub zone on the parent for the child domain. We add a stub zone for AD.reskit.local on the parent domain. So now we have a delegation and the stub zone. You can do that, and that will work. Really, it's overkill, because you have two mechanisms to identify the authoritative servers that are really only one hop away.

Our recommendation is to continue using delegations, because it will be less administrative work for you. Do the delegation any time that parent zone is transferred. The delegation goes with the parent zone and the secondary server now knows about the delegated servers, whereas with the stub zone you have to create the stub zone on every DNS server that has a secondary copy, so that they know about the child.

We recommend continuing to use the delegations as you have in the past, and only use stub zones when you have a situation where delegations won't work.

Otto: Do we currently support automatically updating or populating delegation information?

Tim: No, we don't. It would sure be nice if we did. That would be another administrative burden taken off the shoulders of our DNS administrators. The DNS development team is looking at all of these features, they prioritize them, and they slowly but surely get them into the product. So you never know, in the future they may do that.

Otto: How can you leverage conditional forwarding, understanding the enterprise DNS servers are UNIX BIND? Compare Windows 2000 base forwarding configuration versus using Windows Server 2003 DNS stubs and conditional new features, if possible?

Tim: They want to compare BIND?

Otto: That's what it sounds like.

Tim: With our DNS server, it's been my experience that when customers call in with problems when they're implementing, let's say, Active Directory within an organization, a lot of our customers use BIND servers, and BIND servers are very popular on the Internet. It's been my experience that the flavor and the version of the BIND kind of dictates how successful you're going to be. A lot of our customers use other products as well, like QIP or products from Cisco or Nortel, and everyone seems to be making a DNS server product these days.

Really, in my experience, your Active Directory implementation goes a lot smoother if you use Windows 2000 DNS and now Windows Server 2003 DNS. I can't really compare and contrast the BIND implementation of stub zones and conditional forwarding to our new implementation at this time. I haven't seen enough of our customers using conditional forwarding and stub zones within BIND to really talk about it intelligently.

That doesn't mean they're not using it. They very well may be using it, but typically when they call in and they have problems, there are other problems that we look at, like interoperability problems between BIND servers and our own servers. We had zone transfer problems, and we worked those out. And when Active Directory first came out there were a lot of BIND flavors and versions that didn't support SRV records or support dynamic updates and secure dynamic updates, and so on.

We've been working out all these interoperability problems, and now the two DNS servers play very well together. Really, most of our customers who call in with problems rarely talk to us about their implementations on BIND, as far as stub zones and conditional forwarding go.

Otto: Is conditional forwarding also an RFC standard like stub zones are, and if so, do you know what the RFC number is?

Tim: That's a good question. I don't know, off the top of my head. I can follow up with that one, if it's RFC defined.

{Follow-up answer: This is not RFCed. This type of feature is outside the scope of RFCs.}

Otto: Next question: Would a stub zone be preferred over a large secondary zone?

Tim: Possibly. It depends, if you want to avoid using up bandwidth, or if they're across a WAN link or something. What you're doing is your deferring the traffic. So if you do a secondary zone — let's say we're talking about across a WAN link. You have two sides of the WAN link, and if you have a secondary zone, the WAN link is going to be utilized by the DNS server once in a while to do the zone transfers and keep the zone up to date. They can do incremental zone transfers or full zone transfers, if it's necessary.

Typically zone transfers won't take that long. Even the larger zones can be transferred in a few minutes. If you decide, "I don't want to do the zone transfer anymore, I want to stub zones," then anybody who asks about that zone is going to be referred to the DNS server across the WAN link. Now you're going to have queries going across the WAN link. And depending on how many queries you expect, the traffic might be more or less than actually just doing the zone transfer every once in a while.

What I would recommend in specific cases is to do some profiling and use Network Monitor, put it on the network and check, when you have a secondary zone there, just what percentage of the traffic in a given hour or a given day is actually DNS zone transfers. Then try some stub zones over across the WAN link and then check it out. Now how much is my network being utilized by DNS queries?

I suspect that having a large zone transferred, using a secondary zone across that link, is probably a better idea, because now the zone is local, if you have a lot of queries. If you have very few queries, it's probably a marginal difference. But if you have a lot of queries and a lot of traffic, you probably want to save that WAN link. So the secondary zone is probably the way to go.

Otto: What's the recommended order of use: cache, local zone, stub zone, delegation, forwarding, then route hints?

Tim: I think the way it works is when a DNS server receives a query, it's going to check its cache first, then it's going to check its zone data, and if it doesn't do any of that stuff, I believe it's going to use the forwarders, and then it's going to end up going to root hints.

Otto: Does any failover function implement in the stub zone? For example, we have two name servers for one stub zone, and one name server fails because of a hardware problem, let's say. If the Windows Server 2003 DNS can function in a way to avoid sending a query to a root name server, is that possible?

Tim: There is some logic built in. If we're talking about stub zones or if we're talking about conditional forwarding, both those mechanisms have a list. In the case of stub zones, we have a list of masters. And that list exists basically for that reason, for failover. If we try to go to the first master and get information, get a zone transfer from it, and that master fails to answer, we're going to go to the next master in the list, and then to the next master, and so on, until we find one that's working, or else we won't be able to transfer the zone. There is that optimization there.

If they're talking about clients, a client can query a server. And if the server doesn't respond, it's going to go to the next server in its list as well. The client code is a little different, in that it can optimize the server list. Whereas if some servers answer more quickly than others, it can put those servers at the top of the list for the best performance.

Otto: I was hoping that one of these new features would permit me to selectively transfer some of the records in a zone, sort of a partial zone transfer. I want to do this to control the public exposure of records to only a limited subset of all the records in my production zone. The only way I can think of to do this is to create and administer a separate standard primary zone on a stand-alone server with subsequent zone transfers to standard secondaries. Are partial zone transfers possible at all?

Tim: I don't think our product has a feature that allows a zone transfer through the standard zone transfer methods that we've been discussing to do that, to transfer a user-specified subset of records. One possibility is to write a script using Dnscmd.exe, where from a list you could export or create a zone using a particular set of records. Of course, that would be static, so you could refresh it every once in a while. It's just an idea off the top of my head. But our product right now doesn't support, to my knowledge, zone transfers using a specified subset of records.

Otto: We have a follow up to a question that we addressed earlier, about what sort of load necessitates the use of stub zones. The follow up is as follows: You replied that using stub zones would theoretically reduce the amount of querying because local DNS will know the authoritative server to query, two hops maximum. However, if all DNS were a multimaster for all zones in the organization, clients would never need more than one hop to get an authoritative answer. Is that correct? Thus a multimaster DNS would be the most efficient way to go, barring administrative boundaries as a function of delegation.

Tim: Sure. If every DNS server had all zones for an infrastructure for a given namespace on them locally, you would simply query those servers and you'd get the information that you want. Certainly, that's true.

Like the person said, barring administration, which is sort of one of the biggest costs in this whole enterprise, that would be true. Again, I think that application partitions will address a lot of this issue, where you can actually replicate DNS information across domains now. I think that's really what this person is asking. I agree with them. Again, there are going to be some costs with replication. A lot of replication is already being done through Active Directory anyway, so I guess it will be up to each individual admin, and what kind of network infrastructure they have, to see whether or not they have the infrastructure to handle something like that.

Otto: The order of name servers listed on the Name Servers tab changes. Can you explain this and how that list affects answers to queries it receives?

Tim: They must be talking about on a particular zone, if we have a list of name servers on a particular zone. So if you went to the properties of a forward lookup zone on a server, and looked at the Name Servers tab, those are the name servers that are supposed to be authoritative for that zone. They're stating that that list changes, or the order of the list changes.

The order of that list may change based on roundtrip time. So if we're contacting these servers and we find out that some servers are faster than others, by looking at the roundtrip time between those servers, that list may be optimized.

The other thing is name servers have a funny way of appearing and disappearing on a network. Name servers may very well fall out of a zone. And if they fall out of a zone, obviously you can't contact them. If the glue records go missing, if there's an NS record in a zone for a name server but the IP address, the glue record for that NS record is unavailable, we're not going to be able to contact that server. So some optimization is possible based on that roundtrip time, and whether these servers are even available. I don't know off the top of my head what the algorithm is to optimize the servers in this list.

Otto: Do you know the order of resolution for the DNS client when the PC is configured with WINS and DNS servers?

Tim: Sure. It depends on what type of query we're sending out onto the wire and what operating system we're using. Is it a NetBIOS name we're trying to resolve, or is it a DNS host name that we're trying to resolve? Are we on Windows NT 4.0, Windows 2000, or Windows XP?

Generally, Windows 2000 is going to try DNS first, unlike Windows NT 4.0, which would typically try NetBIOS first. The key to which mechanism it's going to use is really the length of the name. If the name is longer than 15 characters, and they also take a close look at whether there are any dots in the name — if the servers sees dots in a name or it is longer than 15 characters, it must be a DNS host name. They use the DNS resolver to try to resolve the name, as opposed to using WINS or a NetBIOS method. If the name is below 15 characters, it depends again what type of resolution we're looking for.

If I were to go to the command line on a machine and type ping, ping is like a Winsock application, it typically tries DNS name resolution first. If I were to go to the command line and use, let's say, a netuse command, here it uses a NetBIOS name. So it's going to try NetBIOS methods first, like WINS, Broadcast, LMHOSTS, and all that.

Otto: We're down to the last couple of questions here. Is there a list of DNS changes in Windows Server 2003, perhaps an enhancements versus Windows 2000 article, or something of that nature?

Tim: We can definitely follow up on that. There are DNS papers written, and they do have a list up there of some of the new features in Windows Server 2003. It definitely exists, it's just a matter of finding it on the http://support.microsoft.com/default.aspx?scid=http%3a%2f%2fwww.microsoft.com%2f&FR=1 Web site.

{Follow-up answer: The new DNS features list can be found at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/server/sag_DNS_ovr_NewFeatures.asp.}

Otto: Do you know off the top of your head if there are any really good white papers, for instance, in reference to DNS and Windows Server 2003, or possibly some information on TechNet that we can easily find?

Tim: Right. I'm now in the process of writing several new KB articles for Windows Server 2003 DNS that discuss everything from stub zones and conditional forwarding to application partitions and how all that new partitioning stuff works. Obviously, there are other people on the networking team who are working on DNS-centric content as well.

As far as a white paper goes, I'm not sure if the DNS white paper has been rewritten or updated for Windows 2003 DNS yet, or if it has been posted. Probably not, but we can certainly, again, follow up with this customer as well, and find them good information, if it's available yet.

{Follow-up answer: The are no public KB articles or white papers yet, but the link above (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/server/sag_DNS_ovr_NewFeatures.asp) may provide some details.}

Otto: I'm not sure if you've already addressed this. I'm going to ask it just in case: What problems do stub zones solve that couldn't be solved using secondary zones in delegation?

Tim: It's a very good question. Again, I think that the best example that comes to mind is disjointed namespace. If we have reskit.local, and we have mydomain.local, typically an administrator of mydomain.local is not going to be able to delegate any kind of authority for his mydomain.local zone over to the administrator in reskit.local. You could conceivably use a secondary zone. But it depends on the infrastructure and all sorts of things there. Typically, companies that merge already have secure infrastructures, they already have firewalls in place, and they already have their Active Directory forest in place, so they're not in the same forest to begin with. There are all sorts of issues involved here.

Again, stub zones are going to be really useful in the disjointed namespace situation where all we want to do is avoid iteration, trying to find who is authoritative for a zone, when it's right beside us. We know where it is, we know who the servers belong to, let's just specify their IP addresses in a stub zone, and that way we can take a little bit of the load off of our DNS servers and optimize this a little bit.

You have to remember, there's still caching going on here as well. So when one of these servers, even when it does host a stub zone, gets a query and answers a query for another zone, it puts that into cache, and it remains in cache for a TTL period. That also helps caching in all these servers, on the client and server; it typically helps.

Otto: All right. Thank you. With that, it appears that we've answered all the questions that were submitted today, so I'm going to wrap up the session. I want to thank you all for joining us, and hope that the information was useful. I certainly want to thank Tim for coming out and giving us a great presentation.

You can always e-mail us at supweb@microsoft.com. Feel free to submit any content suggestions, comments about the shows, what you'd like to see, and so on. That feedback is absolutely important to us, and we love hearing from you.

I hope that everyone has the opportunity to tune in again soon. Thanks, and have a great day.