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: Today, we’re going to be talking about DNS. We have a few slides to go through here, and then we’ll get to some questions. Let’s talk about exactly what we’re going to discuss today with this "Session Abstract" slide (slide 2). We’re going to be talking a lot about Windows^® 2000 DNS and Windows 2000 dynamic updates and how that all interoperates with different versions of BIND.

First, let’s define Windows 2000 DNS dynamic update so that everyone is up to speed with this, if they’re not already aware of what it is. Dynamic DNS updates are defined in RFC 2136. Basically, the point of dynamic updates is to reduce the administrative resources needed to manually manage DNS records. So they enable clients to dynamically register host and pointer resource records with DNS, so that administrators don’t have to manually enter those into DNS.

By default, Windows 2000 domain controllers also dynamically register SRV records. We’re going to talk about SRV records in a little bit more depth later, but for right now, just think of SRV records as records that allow clients to locate services and protocols using DNS. You can get more detail about SRV records if you search our Knowledge Base. You can refer to KB article Q232025 (http://support.microsoft.com/support/misc/kblookup.asp?ID=232025). So for example, Windows XP and Windows 2000 clients use DNS to locate LDAP servers when they start up and want to find a domain. So that’s an example of where SRV records are used.

For those of you deploying a new Windows domain in a pre-existing environment that already has DNS servers that do not support these dynamic updates, you may decide to leverage your existing DNS infrastructure rather than replace it. So we’re going to talk a little bit about how to integrate your old infrastructure with a brand new Windows 2000 domain. We’re going to discuss Windows 2000 domain deployment options, focusing on environments that have pre-existing DNS infrastructures.

So this session is really designed to help those people who want to deploy Windows 2000 in an environment that has a namespace based on BIND DNS or Windows NT^® 4.0 DNS, or even third-party vendor DNS products. We’re also going to point out some known issues with using BIND DNS and Windows 2000 in the same environment, just so you can try to side-step some of those issues ahead of time.

On this next slide (slide 3), I want to define some terms that we use quite frequently when we talk about DNS and interoperability. Let’s just do a quick terminology review to make sure I don’t confuse anyone when I use these terms. When I use the term BIND or BIND server, I’m referring to a UNIX-based DNS server.

I also want to point out that there is a difference between what’s called an Active Directory^® domain and a DNS domain. A DNS domain defines a namespace, whereas an Active Directory domain is a replication and security boundary. Sometimes, they refer to an Active Directory domain as Windows NT domain. So really, the Windows 2000 Active Directory is used to authenticate users and computers when they need to access domain resources. That’s how they maintain a security boundary. Windows 2000 domain controllers typically replicate with other domain controllers in this same Active Directory domain. So I just want to point out the difference between a DNS domain and an Active Directory domain. DNS domains are simply used to map names to IP addresses, sort of in an effort to organize network resources. So when I talk about Active Directory domain and DNS domain, please keep that subtle difference in mind.

Analyzing your current network infrastructure and planning changes are important steps to take before making any actual changes to a production network. What you need to do is consider what your network looks like today and what it might look like six months or a year from now. You need to consider several factors when planning changes to a DNS infrastructure. We’re going to take a quick look at each one of the factors that you see here on this slide (slide 4).

The functionality that your DNS servers must support depends in large part on your network clients and their abilities (slide 5). So Windows XP and Windows 2000 clients are designed to use all the features of Windows 2000 DNS, where legacy clients, like Windows NT 4.0 clients or Windows 95 clients, do not have dynamic DNS update support built into them. So for those clients, what we’ve had to do in the past is, a DNS administrator would have to go in and enter records manually into a DNS server’s database for those clients. Now, with dynamic updates, with Windows XP and Windows 2000, the clients are able to dynamically update a server that supports that function.

Windows 2000 DHCP server has been designed to overcome this limitation of legacy Windows clients. So a Windows 2000 DHCP server can be configured to dynamically register host and pointer records with DNS on behalf of network clients. So a DHCP server can be used to do dynamic updates to DNS for all the Windows 9x clients, Windows NT 4.0 clients, even Windows 2000 or Windows XP clients, if that’s what you choose to do.

Non-Windows clients may have their own unique name resolution limitations. The Windows 2000 DHCP server will certainly help overcome those. So your DNS design should take into consideration the types of clients on your network.

Another factor to consider when planning changes to your DNS infrastructure is the use of static IP addresses (slide 6). DNS servers obviously must have static IP addresses themselves, so that clients know which IP address to contact when they’re looking to either register or resolve names. The question is will your clients be using static IP addresses or DHCP-provided IP configurations?

Many environments use a combination of these two methods. The more clients that get their IP configurations from DHCP, the more helpful dynamic DNS updates become. Because DHCP client IP addresses may change frequently, their corresponding DNS records must be updated just as often. So consider how often a client’s DNS resource record should be updated.

Typically, you want to make sure that they’re updated every 24 hours to ensure the client’s DNS records don’t become stale. Whenever the client’s TCP/IP is changed, you want to make sure that an update is sent to DNS. When the client’s DHCP lease is renewed or when a new lease is obtained, obviously you’re going to have to update the DNS records to reflect any changes in IP addresses. When the client’s DHCP lease expires, we’re going to want to clean up those old records so that we don’t run into name resolution problems. When a Plug and Play event occurs on a client, we want to make sure that we take the appropriate action and update DNS, if it’s required. So when planning changes to your DNS infrastructure, it’s important to consider your client’s IP configurations and how often DNS records have to be updated. Just keep that in mind.

The other thing you want to consider when planning changes to your infrastructure is the type of DNS servers that are available to you (slide 7). So while planning a DNS infrastructure, consider these types of servers. Each type of server has its own characteristics that dictate administrative overhead and replication traffic for that server.

The release of Windows 2000 DNS introduced a new type of DNS server, called an Active Directory-integrated DNS server. Active Directory-integrated DNS servers have several advantages over traditional primary/secondary DNS model servers. In the past, we’ve had primary servers that do zone transfers to secondary servers. The secondary servers simply keep a read-only copy of the zone that’s used to answer name resolution queries. Now, with Active Directory-integrated zones, we have a couple of advantages over that old model.

One of them is secure dynamic updates. Secure dynamic updates help prevent name hijacking and other exploits that non-Active Directory-integrated DNS servers can fall victim to. So secure dynamic updates can be a very important feature to take into consideration when designing your infrastructure.

Another advantage of Active Directory-integrated DNS is called multi-master replication. This allows any Active Directory-integrated DNS server to accept updates to zones. So as I mentioned earlier, with the old primary/secondary model, secondary was always just a read-only copy of the primary zone. With multi-master replication, every copy of the zone is a read/write copy. So that allows us to do dynamic updates to any Active Directory-integrated server. Updates are then replicated to other Active Directory-integrated DNS servers without having to configure and manage zone transfers.

So with the old model again, the primary/secondary model, the administrator could go in and manage exactly how zone transfers were done. It didn’t take a lot of administration, but it’s just another thing for someone to do. So with Active Directory-integrated zones, DNS records are replicated using the Active Directory replication cycle, and you don’t have to do anything, as a DNS administrator, to make that work, which is a nice feature. Administrators have granular control over this replication, compared to standard zone transfers. We’re going to talk about sites and that sort of thing here in just a few slides, and hopefully what I mean will become clear.

Another factor to consider when planning a DNS infrastructure is Active Directory sites (as I mentioned in the last slide) (slide 8). If your network has offices connected by WAN links, you will want to use Active Directory sites to manage traffic across those links. For those of you who are unfamiliar with this concept, a site is defined as a well-connected subnet.

For example, let’s say we have two switched subnets, each moving data at 10 Mbps. These two subnets are connected together by a slower 56-Kbps link. Each subnet is considered a site.

We can control the Active Directory replication between the two sites, so that we don’t constantly tie up the 56-Kbps link. Your DNS infrastructure design should also take advantage of this concept. Typically, each site will have its own local DNS server.

Then, if you integrate the Active Directory zones on the server, you can leverage the Active Directory replication cycle to transfer the DNS zone data to other sites. As I mentioned earlier, on the last slide, Active Directory-integrated DNS servers have this advantage over non-Active Directory-integrated servers. Replication traffic between Active Directory-integrated DNS servers can be fine tuned, so that bandwidth between sites can be used in the most efficient manner, can be scheduled, and so forth.

A fifth infrastructure planning factor is namespace design (slide 9). This is a big topic. We could spend a lot of time talking about namespace design, but typically, one major goal of namespace design is to allow users to easily access network resources by name. It sounds simple, doesn’t it?

Depending on the environment, users may need to access internal resources as well as resources out on the Internet. So if you have a network that’s connected to the Internet, which most organizations do today, you’re going to have to allow your users to access the internal resources and resources out on the Internet as well. So the more complex the namespace design becomes, the more sophisticated users have to be.

Let’s take a quick look at some of these namespace design issues (slide 10). When you’re planning to make changes to your existing DNS infrastructure, should you continue using the same namespace, or should you create a new one? That’s a big question. Do you want to use the namespace that you have established, or do you want to create a brand new one? Well, you have several options here.

Many organizations choose to create a new child domain within their existing namespace. That’s what’s called a contiguous namespace. Contiguous namespaces are usually easier to administrate and support.

Some organizations end up with a disjointed namespace after merging with other organizations. You can see on the slide, a disjointed namespace is where a child domain does not share a parent’s name. Disjointed namespaces tend to be more confusing for users and are typically harder to administrate and troubleshoot. It really does confuse users. They don’t know, in a lot of cases, what name to use and why they’re using different names. It can be very confusing. At the same time, a disjointed namespace can solve many technical problems that some environments are burdened with.

The last DNS infrastructure factor that we’re going to discuss here is Internet presence (slide 11). This is a very important planning factor. Most organizations have private networks and expose a portion of that private network to the Internet. They use firewalls to control access to the public portion of this network.

So when you have an Internet presence, you need a registered domain name. You can use this registered name in several ways. For instance, in option A here, you can use the registered domain name as the Active Directory root domain.

There are some advantages to this approach. Basically we have a domain name. Let’s say we call it reskit.com or microsoft.com. If people out on the Internet want to hit our Web site, they type that URL into Internet Explorer, and they get there. Well, we’re going to use the same name for the root of our Active Directory domain.

So what are the pros and cons of using that particular approach? Well, first off, it doesn’t require additional Internet name registration. So you don’t have to worry about going to InterNIC or another Internet registration service to pay more money and register another name. You’re going to use the existing name registration that you already have.

The existing DNS infrastructure namespace may not have to be altered at all. DNS zones and topology may not have to be changed, which might be a big deal in some environments.

There are some disadvantages to this approach, though, in that your existing DNS servers may have to be upgraded to support SRV records. As I mentioned earlier, and actually I’m going to mention this again on a later slide, dynamic updates require support for SRV records. I mentioned earlier that clients use these SRV records to find things like the domain, the LDAP services, and so on.

So your infrastructure has to support SRV records. As we’re going to find out in later slides, some older versions, for instance Windows NT 4.0 and some of the earlier service packs, do not support SRV records. Some early versions of BIND servers don’t support SRV records. So it’s very, very important to understand this.

Also, security becomes an issue, because you’ll not want to allow DNS records for your Active Directory infrastructure to be visible to the Internet. I’ve seen this before, where an organization decides to use their Internet presence name as the root of their Active Directory domain. They use a single DNS server, and not only can people on the Internet see their DNS records that they publish for mail and Web sites, but they also get to see their Active Directory SRV records, A records, PTR records, and so forth. You want to limit that, obviously. You don’t want people out on the Internet to know how many servers you have, what their IP addresses are, and so forth.

The second option, option B on this slide, is that you can use a delegated subdomain for the Active Directory root. This approach allows you to isolate all Active Directory data within its own domain. Also, it should not require upgrading your existing DNS servers to support SRV records, because the new servers, typically Windows 2000 servers, will handle this function. Using this option makes your Active Directory name structure longer, and typically a delegated subdomain will require its own DNS server. There are a couple of drawbacks to this, in that you’ll probably need at least one more DNS server, or your namespace gets a little bit longer, but this is an approach a lot of our customers use, a delegated subdomain for the Active Directory root domain. It makes a lot of sense in a lot of different environments.

The third option is to use what’s called a reserved private domain name for the Active Directory root domain. So the .local domain is a first-level domain name that InterNIC and the other registrars have agreed to reserve for private use. So you’re not going to find any .local domains registered out on the Internet. So people can’t type in, for instance, www.example.local and get anywhere, because it’s a private namespace. For example, you could have an Active Directory root domain called reskit.local or example.local. You don’t have to worry about someone else on the Internet registering those names, if you use them for the root of your Active Directory infrastructure. There are no registration problems at all.

This allows you to also differentiate between your Active Directory and your Internet presence. So if you have a zone, let’s say example.com, now we have example.local, where example.com is used for our Internet presence, and example.local is used as a root of our Active Directory domain. So this approach provides flexibility to use any valid DNS name for your Active Directory domain, because it will not be registered on the Internet.

One drawback of this approach, though, is that if you change your mind and you want to use one of the other options that we discussed earlier, like option A or option B, after using this one, you’ll likely have to reinstall the Active Directory forest from scratch, because after you install it in a particular namespace, that’s it. You’re not going to be able to rename that forest without a lot of work to do that. So if you choose this third option, you just have to be careful. You have to decide that we’re going to have a completely private root from now into the foreseeable future.

If you decide to use the same name for your Active Directory and for your Internet presence, you will probably want to keep your Active Directory DNS records private (slide 12). You want to limit how much information you’re going to publish about your network on to the Internet.

Basically, you want to decide what records to publish out to the Internet. So you publish mail records. You publish Web site records, maybe some FTP sites, whatever your business needs dictate, but typically you don’t want to publish information about your Active Directory, your domain controllers, and your clients. You want to minimize how much information you show to the public, so that you avoid repercussions of that, like getting hacked.

So you can use two separate DNS servers that host the same domain and put a firewall between them. So let’s say we had a domain name called reskit.com. We have an Internet presence. When people type that into Internet Explorer, they get our Web site. Well, we’re going to have a DNS server out on the Internet that hosts those records that basically just have our mail records and our Web server records. Then, we’re going to have a firewall. Then, we’re going to have an internal DNS server that also hosts a zone of the same name, reskit.com.

The firewall is going to prevent anybody on the Internet from getting through to the internal DNS server, so that the internal DNS server is going to host all our Active Directory records, and no one from the Internet is going to be able to access those Active Directory records. We don’t have to worry about zone transfers between the two DNS servers. We don’t want them to transfer zones, because we don’t want the external DNS server to have any knowledge of those internal records.

So this approach requires a little bit more work, because you have to have a firewall, which typically isn’t a problem. Microsoft has a couple of products that do this, like ISA, Internet Security & Acceleration Server, a product that is a great firewall. A lot of our customers run the previous version to that, which was Proxy Server 2.0, and there are many, many third-party firewalls out there. But the key is you have to know how to configure and maintain that firewall, which is easy in some environments and not in others.

This method can also be confusing to internal users, unless you plan on mirroring public Web sites internally, or you train users to understand that internal Web sites are different from external Web sites, even though they have the same name. So we get a lot of questions like, "When I type in my company’s URL, I get the public Web site, but when I’m at work, I get a different Web site. Why is that?" Well, the company’s using the same name both publicly and privately, but they have separated the namespace. So it becomes a training issue. In some environments, it’s not a big deal. Users are very savvy, and they understand this. But in other environments, it can be a training issue, and it can be confusing for your users.

You could choose to use a different name internally. For example, your Internet presence can be registered as reskit.com, and your internal namespace can be called reskit.local, as I mentioned in the last slide. This approach allows you to avoid mirroring resources. Again, users may be confused by the different names. Why are some of the resources, when I’m at work, called .local, and when I’m out on the Internet, I type .local and I don’t get anything? So it really comes down to a usability issue and what your business needs are.

After you’ve made some decisions and done some namespace planning, you will want to take a look at the DNS servers in your existing infrastructure (slide 13). You may have Windows NT 4.0 DNS servers, various versions of BIND DNS servers, or even some other vendors’ DNS server products. A lot of vendors now are making DNS server products. So rolling out Windows 2000 Active Directory does not mean that you have to upgrade or replace your existing DNS infrastructure, although in some cases, it may be appropriate and a lot easier to do this.

To implement Windows 2000 Active Directory, you need to have a DNS infrastructure that supports dynamic DNS updates and SRV records. Now, there’s a caveat to that. The absolute minimum you need is SRV record support. You absolutely need a DNS server that supports SRV records. Otherwise, clients are never going to be able to find services and protocols, like we talked about before.

The other thing is, support for dynamic DNS updates. Now, this isn’t absolutely a requirement of Active Directory. In the past I’ve helped customers who tried to implement Active Directory without using dynamic updates. Theoretically, this approach is valid, and in some instances, it might be appropriate, but I can tell you from experience that doing this is typically not worth the effort. Most networks today change frequently, and that makes this approach impractical.

So SRV record and dynamic update support are required on servers used in your Active Directory infrastructure. Let’s say you have a network infrastructure based on BIND DNS servers (slide 14). It’s important to verify the version of BIND that you are using, because many older versions of BIND do not support SRV records. As I mentioned in the previous slide, we need SRV record support. Although several versions of BIND do not support dynamic updates, BIND versions 8.2.2 or later work best with Windows clients. So there are versions of BIND previous to 8.2.2 that do support dynamic updates, but what we have found is that version 8.2.2 or later worked best with Windows clients.

So your existing DNS infrastructure is going to influence the direction you take when rolling out Windows 2000 Active Directory. We’re going to take a look at some of those options.

For those of you who have a Windows NT 4.0 infrastructure (slide 15), and there are a lot of you, SRV record support was added in Service Pack 4 for Windows NT 4.0. One of the drawbacks there is that Windows NT 4.0 DNS servers do not have support for dynamic updates. So although Windows NT 4.0 can be used in your Active Directory infrastructure, because they have SRV support, you’re going to want to use some of these options we’re going to talk about here to integrate Windows 2000 into your Windows NT 4.0 infrastructure.

So if you have Windows NT 4.0 DNS servers in your environment, you have the option to continue using these servers, and we’re going to talk about how to delegate zones and that sort of thing from those servers. The other option you have is to upgrade these servers to Windows 2000, which supports SRV records and dynamic updates. This might be a move that makes your life a lot easier in the future, because dynamic updates are extremely important to Active Directory, and they make your life as an administrator that much easier.

Now, let’s say upgrading is not an option. You have some Windows NT 4.0 servers or you have some BIND servers that don’t have SRV support or don’t have dynamic update support. You can leave these servers in place, even though you’re going to roll out Windows 2000 Active Directory in your environment.

You still get a couple of options here. Another option is to migrate the DNS zones from existing DNS servers that don’t support SRV records or dynamic updates to DNS servers that do. So we can basically take the data from the DNS servers that currently don’t support SRV records and dynamic updates, and we can move that to some Windows 2000 DNS servers in your environment, if you have some already or if you’re planning to put some in.

There is a KB article I can refer you to on how to do this. It’s a popular question that we get, how to migrate zones from a BIND server to a Windows 2000 server or from a Windows NT 4.0 server to a Windows 2000 server. You can look at Q301192 (http://support.microsoft.com/support/misc/kblookup.asp?ID=301192).

Moving on with some of these DNS integration options (slide 16), a third option is to delegate a domain for your Active Directory infrastructure. So if you’ve decided to use a contiguous namespace and you have the flexibility to install Windows 2000 Active Directory in a child domain, this approach is probably a good one for you. You can keep the DNS server or servers that currently host the parent domain in place.

So let’s say we have a domain called reskit.com, and let’s say it’s hosted by some older versions of BIND that don’t support SRV records and don’t support dynamic updates. It’s not a problem. What we can do is delegate a subdomain, a child domain, from that BIND server down to a new Windows 2000 DNS server. The Windows 2000 DNS server supports SRV records and dynamic updates. So it’s going to be able to handle the Active Directory infrastructure for us. That way, you can leave the BIND server in place. Clients can continue to use that BIND server like they always did, and the Windows 2000 DNS server is going to take care of all the Active Directory stuff for us.

Moving on here, there is a fourth option (slide 17), and this option is a popular option. The fourth option is useful when the Active Directory domain name is going to be the same as the name of the root zone. For example, let’s say you have a namespace called reskit.com. Now, you want to deploy Windows 2000 in that namespace. Because the namespace is already hosted by existing DNS servers, the zone can’t be delegated directly to a Windows 2000 DNS server, as it was in the third option we discussed. So we’re not delegating a child domain here. We’re using the parent domain for our Active Directory infrastructure.

So reskit.com, in our example, will become the root of the Active Directory domain. If reskit.com happens to be hosted by BIND DNS servers without dynamic update support, our design must overcome this limitation. So as I mentioned, this scenario happens to be a very common scenario that I see.

Because Windows 2000 domain controllers register their SRV records in four subdomains, what we can do is delegate those subdomains to a Windows 2000 DNS server that can handle dynamic updates and SRV records. So in our example, those four subdomains would become _msdcs.reskit.com, _sites.reskit.com, _tcp.reskit.com, and _udp.reskit.com.

So what we’re going to do is delegate those four zones from our BIND DNS server down to a Windows 2000 DNS server. Any time clients go to look for our Active Directory, they’re going to ask the BIND server, the way they did before, and the BIND server is going to tell them, "Well, I’m not authoritative for that zone. Go talk to this Windows 2000 DNS server that is." Of course, the Windows 2000 DNS server understands SRV records and dynamic updates and will be able to help the clients with that.

I wrote a KB article that describes, step-by-step, how to do that, how to delegate those four subzones. If you want to take a look at that, it’s Q255913 (http://support.microsoft.com/support/misc/kblookup.asp?ID=255913). It’s a lengthy article, but it describes, step-by-step, in Windows 2000, how to achieve this.

There are also a couple of articles I’d like to refer you to. "Troubleshooting Windows 2000 DNS dynamic update problems," if you are experiencing dynamic update problems in your environment, whether you’re using BIND or whether you’re using Windows 2000 or some other third-party DNS product, this KB article will help you figure out what the problem is, because clients typically take the same steps to do a dynamic update, regardless of what the end point is. So that’s Q287156 (http://support.microsoft.com/support/misc/kblookup.asp?ID=287156).

Also, I get this question sometimes, "How do I determine what version of BIND I’m using?" Maybe you’re not the DNS administrator who originally installed the software. How do I figure this out? There’s an article, Q314780 (http://support.microsoft.com/support/misc/kblookup.asp?ID=314780), called, "How to Use NSLookup to Determine the Version of BIND DNS Running." It’s a simple article. It’s just a couple of NSLookup commands that you can use, and that will tell you what version of BIND you’re using, unless the administrator has set it up to keep that information private.

Anyway, moving on here, let’s talk a little bit about BIND integration issues (slide 18). For the most part, Windows NT 4.0 DNS servers and Windows 2000 DNS servers interoperate with BIND DNS servers well. As you can see from this partial list of articles, we do find interoperability issues from time to time, and we do our best to compensate for the differences between the two products. So using recent versions of BIND and installing the latest service pack on your Windows DNS servers will help you avoid interoperability issues.

I also recommend checking with Product Support Services, at http://support.microsoft.com/, for hotfixes for DNS. We add updates to DNS all the time, and it always helps to be using the latest and greatest versions of both Windows DNS and BIND DNS.

You can see, from this list of KB articles (on slide 18), that areas that typically are affected with interoperability issues are things like zone transfers and the like. So moving records between DNS servers sometimes can be problematic. Typically, it’s not. It just, again, depends on the versions that you’re using. But if you use one of the four methods we discussed earlier, you can avoid zone transfers altogether. Delegations and using separate DNS servers are good options, and they don’t require zone transfers between the two different flavors of DNS.

I think that’s the entire presentation. You made it through all that stuff. Thank you for listening to me. I think we’re going to segue into some questions at this point.

Jason Bennet: Thank you for the presentation, Tim. Just a couple of quick notes before we move on to the Q&A portion of this Support WebCast: to access information on all upcoming Support WebCasts and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

The Q&A portion of this Support WebCast is intended to encourage further discussion of the Support WebCast topic. However, one-on-one product support issues are outside the scope of what we’re able to address here today. So if you need technical assistance, please submit an incident on the Web, or call Microsoft Product Support Services and speak to a Support Professional.

We did get a few questions into the queue. Tim, here’s the first question: With a non-Microsoft DNS server, what are the consequences of dynamic update not working, especially if it was working, then broke?

Tim: That’s a good question, and it’s a common problem. What’s happened is, clients have in the past successfully done dynamic updates, and dynamically updated a DNS server. So if that DNS server is, let’s say, a Windows 2000 DNS server, we have some technology built into the DNS server called aging and scavenging. If aging and scavenging is enabled on the DNS server and the zone in which the clients have been dynamically updated, what will happen is, over a period of time, those records will be scavenged out of the database. So if the client’s IP addresses have changed over time, and they’re unable to update their dynamic updates for any reason, those old records will be stuck in DNS.

So with aging and scavenging, over a period of time those records will be moved out of the database. You can completely configure the period, how fast or how slow you want those records scavenged. Now, if you manage to dynamically update a third-party DNS server, and your clients are failing to dynamically update those records, each different technology is going to have to have some solution to this. So in some cases, that means the administrator has to go in there and manually delete the records, which can get ugly in a large environment. Yes, if you have a dynamic update that worked and now it doesn’t, and your IP address changes, clearly name resolutions may be broken. So like I said, in the case of Windows 2000, we do have the aging and scavenging mechanism that helps with that.

Jason: Is it possible to reserve an IP address for a particular MAC address, using a Windows 2000 DNS server?

Tim: It is, in that you can use DHCP to do that. So what you can do is create a reservation in a DHCP lease that says, "I always give this MAC address a particular IP address." Then, you can get the DHCP server to do the dynamic registration on behalf of the client. It gets even better if you use secure dynamic updates, because then the DHCP server updates DNS, and no one else can hijack that name, because the DHCP server is reserving that address, and the name registration has been secured in DNS, using the secure dynamic update feature of Windows 2000. So yes, if you use DHCP, is the short answer.

Jason: DDNS registrations could be globally all network adapters disabled at the client using the DisableDynamicUpdate registry value on Windows 2000 Professional, and they’re referencing Q246804. I haven’t found any mention of disabling the DDNS registration behavior in the Windows XP Professional client. Is the same registry modification supported under Windows XP Professional?

Tim: That’s a good question. The registry key for Windows XP clients has changed slightly, and I don’t have the KB in front of me, but I believe the Windows 2000 registry value is plural, and the Windows XP registry value is not. So I think if you just take the "s" off that registry value, it will work for you.

{Follow-up answer: In Windows 2000 DisableDynamicUpdate value is located under the following key:

Setting this to 1 disables dynamic updates.

In Windows XP, this changed to RegistrationEnabled, with the opposite parity.}

Jason: Okay. Is there a way to prevent the DNS client on the domain controller from registering the A and PTR records while allowing Netlogon to register SRV records?

Tim: That’s a good question. For those of you who aren’t familiar with Netlogon, Netlogon is a service on a Windows 2000 domain controller that is responsible for registering all your SRV records. The DHCP client service is responsible for registering A and PTR records. In the case of a domain controller, I believe Netlogon also registers A and PTR records. Netlogon will re-register those records with DNS periodically, I think it’s once an hour on a domain controller, to make sure the records are never stale.

Now the question is: Is it possible to stop it from registering A and PTR records and continue to allow it to register SRV records? If you go into the TCP/IP properties on the DNS tab there, there are some check boxes that say, "Register this connection with DNS." If you clear those, on a Windows 2000 Professional client, it will stop you from registering, but because you’re on a domain controller, even if you do that, the Netlogon server is still going to register those two records.

So my first impression is no, but there are some things that you can do to work around that. The A and PTR records, I guess it depends on what you wanted to accomplish. But the short answer is no. Netlogon is going to re-register those records all the time. What you can do is make manual entries in the DNS database and then use secure dynamic updates, so that they can’t be overwritten. That way, you can control where the A records and the PTR records point to. There may be a more elegant solution than that, but that’s just what I can come up with off the top of my head.

Jason: What’s the RFC for .local?

Tim: The RFC for .local, that’s a good question. I was trying to track down some information on the .local domain and where it’s defined as a reserved private address space. I went up to http://www.internic.net. I looked at some of the RFCs. I found references to it in non-RFC literature, but off the top of my head, I don’t know where, in the RFCs, it’s located.

Jason: Will Windows 2000 DNS support conditional forwarding?

Tim: No, it will not. Windows 2000 DNS does not support conditional forwarding, but Windows .NET Server, the next version of the Windows Server product, will support that feature. So just hold your breath, and it will be out soon.

Jason: Large multinational companies often have a requirement for IP management to sit on top of their DNS service products, like Lucent’s QIP, and this works well with the traditional BIND. Are there any products that are known to work well with Active Directory-integrated DNS?

Tim: Don’t let Active Directory-integrated DNS throw you for a loop, because really, when we talk about Active Directory-integrated DNS, what we’re talking about, besides the added features, is basically where the records are being stored. So on a non-Active Directory-integrated server, the records are being stored into a text file, a .dns. file. On an Active Directory-integrated DNS server, now they’re being stored in the Active Directory database.

So the records are being stored in two different places. But as far as zone transfers and all the other DNS functionality, it makes no difference at all where the records are being stored. So if you have other servers that are non-Active Directory-integrated servers, whether they’re Microsoft or third-party servers, zone transfers will be carried out just like they were before. So the Active Directory-integrated DNS server really isn’t an issue in those scenarios. Every single day I talk to really large corporate customers who have a mixed-bag DNS infrastructure and use Active Directory-integrated zones without a problem.

Jason: What was the minimum service pack for Windows NT 4.0 to support SRV records?

Tim: That was Service Pack 4, but I would encourage you to install Service Pack 6 or what they call the Security Rollup Package (SRP) for Windows NT 4.0, if you’re running Windows NT 4.0. There are numerous fixes in later services packs for DNS, DHCP, and so on. So I always try to get people to go to the latest and greatest binaries on their servers. As far as SRV record support goes in Windows NT 4.0, it started with Service Pack 4.

Jason: Per-zone forwarding, is that the same as conditional forwarding? Is there planned support for per-zone forwarding in Windows DNS? Didn’t you just answer that?

Tim: Right, that is conditional forwarding. For those people who aren’t familiar with the concept of conditional forwarding, basically you’re able to decide which DNS server to forward to.

For instance, what is a forwarder, right? You have a DNS server that hosts a particular zone, let’s say reskit.com. Now, if we want our clients inside our network to be able to access resources out on the Internet, let’s say, we have to have some place for our DNS server to forward to, if it doesn’t know the answer to the query. So we configure forwarders. So today on Windows 2000, we can configure a list of forwarders. If our Windows 2000 DNS server doesn’t know the answer to the query, and isn’t authoritative for the zone that’s being queried, it will forward the query to the forwarders on the list.

With conditional forwarding, it allows you to pick which DNS server in the forwarding list you’re going to forward queries to, based on the name that they’re querying. So if someone queries microsoft.com, we can pick a particular DNS server to forward that query to that will answer that query for us, which will be completely different than the reskit.com zone, which we can configure to forward to a completely DNS server. So that’s per-zone forwarding, that’s conditional forwarding, and that’s the whole concept. Windows 2000 doesn’t support that at this time.

Jason: If we choose to use a contiguous namespace, is it a good idea to not have the four underscore domains registered in the external DNS server to keep the Active Directory domains private? If so, how will the top-level domain controllers be able to register their SRV records into DNS?

Tim: That’s a good question. Basically, this particular individual has a situation where they’ve used their Internet presence, their name, let’s say reskit.com, as the root of their Active Directory domain. So here our DNS servers that host the zone for our Internet presence records are also hosting our Active Directory records. So that people from the Internet, if they’re savvy enough, could query and find out their domain controller SRV name registrations and A record registrations for internal resources.

I would recommend against doing something like that. I would use one of the options we talked about earlier, where if you’re going to use the same namespace, use different DNS servers to host your Internet records and your private internal DNS records. So as I mentioned earlier, have an external DNS server that simply hosts your public records, and use a separate DNS server to host the exact same zone, but it’s going to host all your Active Directory records. And don’t replicate between the two. You can get away with this even if the servers are in the same Active Directory domain. So I would highly recommend that you don’t allow the public to view your SRV records and other private registrations.

Jason: Is it correct that even if a BIND server supports DDNS, only one server can provide that capability, whereas any Active Directory Windows 2000 DNS can?

Tim: No, that’s not completely accurate. Basically the whole dynamic DNS process works like this: your client that wants to do a dynamic update, whether it's a domain controller or a simple Windows 2000 client, needs to find the proper DNS server to register with. So that client has been configured to use at least one DNS server. Otherwise, it would never be able to find the domain.

So it has a list of configured DNS servers. It’s one, two, whatever — 25 servers. It doesn’t matter. It starts at the top of the list. It queries his local DNS server to find out who’s authoritative for the zone in which it wants to register.

So let’s say it’s a member of the Active Directory domain called reskit.com. It queries its local DNS server to find the SOA record, which is authoritative for reskit.com. Its local DNS server may or may not be authoritative for that zone. Let’s say it’s not. It sends back a response to the client saying, "I’m not authoritative for this zone, but I know who you can ask about it," or it might refer it to the very DNS server that is authoritative for the zone.

After it finds out which DNS server is authoritative for that zone, then it can send dynamic update requests to that server.

Sometimes you’ll see that it sends prerequisite requests to see if the name has already been registered, if it should be registered, and so forth. If all the prerequisites have been met, the client will send a dynamic update request to that server.

With that server, it depends on whether we’re using secure dynamic updates or not. If we are, it’s going to reject the request, and the request is going to require a signature, because it’s secure. If we’re not using secure dynamic updates, no problem, the server is going to accept the request, register the record, and send a response back to the client, indicating success or failure. That’s the dynamic update process.

Using a BIND server for dynamic updates shouldn’t be a big deal. If your client asks the BIND server who’s authoritative for the zone, and the BIND server says, "Oh, this Windows 2000 DNS server is," no problem. If we’re referred to a BIND server as authoritative for that zone, it still shouldn’t be a problem. If the BIND server is version 8.2.2 or later, typically there are no problems with them accepting dynamic updates from clients.

Jason: Concerning DNS delegation, and I don’t know if this off-topic: What ACLs are required on Microsoft DNS if you’re not a member of DNS admins?

Tim: To do delegations, yes, that’s a good question. It’s a complex question as well. There’s a Knowledge Base article that you can look up. I don’t have the Knowledge Base in front of me, but if you queried on "ACL" "DNS" "Windows 2000", you’ll get list of articles to have a look at. There is an article that describes the steps to take to control administrative access on a per-zone basis. So off the top of my head, I can’t tell you what the ACLs are, but there are a couple of articles that will help you with that.

Jason: I understand .local is reserved for private use. What other names have been reserved that you’re aware of? Specifically, do you have any idea if .tld has been reserved for private use?

Tim: No, I don’t. I was just up on InterNIC this morning and noticed that they have a few new domain names that have been agreed upon, like .biz, and the like, but I did not see .tld or anything like that. That doesn’t mean it doesn’t exist. The best source for that are the registrars themselves. So if you go up to http://www.internic.net or one of the big registration databases, that’s your best source for that information. The other way to do is to dig through the RFCs. The DNS namespace is changing faster and faster all the time, so the registrars are your best source of information at this point.

Jason: Is there any way to block the creation of PTR records of hosts that fail to meet strict RFC naming?

Tim: Well, that’s a good question. I’ve never been asked that question before. Is there any way to block PTR registration if we don’t meet strict naming criteria? On a Windows 2000 DNS server, you do have the option to enforce what’s called strict name checking, which means if the combination of characters, letters, and numbers in the name doesn’t match the strict RFC definition of what should be there, then it’s not supported. So on a Windows 2000 server, you do have the option to enforce strict name checking. With third-party servers, I really couldn’t tell you. If your clients are trying to register and you have strict name checking enforced on your Windows 2000 DNS server, any spurious characters that aren’t defined in that RFC shouldn’t make it into the database.

Jason: How do you delete an abandoned domain controller after the join fails?

Tim: If I understand the question correctly, maybe what we’ve had here is a domain controller that managed to dynamically register SRV records and A records in DNS. Now, that domain controller either is having connectivity problems with the domain, or maybe it’s completely gone.

If you still have that domain controller and you want to get rid of the DNS records, go to the domain controller and find the Netlogon.dns file that should be on the hard drive of that system. The Netlogon.dns file shows you all the names that the Netlogon service is going to register with DNS. It’s an entire list. Then, you can use that list to manually delete all the records from DNS, or you can write a script and use Dnscmd or Netsh or one of the command-line commands to delete the records for you.

Jason: Are the Microsoft DNS servers available for Solaris?

Tim: Not that I’m aware of. Windows 2000 runs on Intel platforms, now. Alpha support was dropped, I think it was in Beta 3 of Windows 2000. So as far as I know, Windows 2000 only runs on Intel platforms, and there’s no talk about Alpha support, UNIX support, or Solaris support that I know of, at this time.

Jason: Has Microsoft considered providing IP management tools at any point in the future? The DNS MMC snap-in doesn’t lend itself very well to managing many devices.

Tim: That’s a really good point. I can tell you this: in .NET Server, what they call the UI object picker, which I think is really what you’re referring to, it’s not necessarily the MMC, but the functionality inside the UI, where you couldn’t do really nice things like drag and drop and that sort of thing. That’s been a big area of focus here at Microsoft and it has been drastically improved in .NET Server.

If you want to read more about that and most of the other changes that they’ve made to .NET Server, you can go out to http://www.microsoft.com/windows.net/server/, and they have an overview document up there that you can open up and read about some of this stuff. .NET Server is a very exciting product, and we’re working hard to make sure that we meet all customer expectations.

A lot of the features that people are asking for here in this WebCast and that people were asking for, when I attended NetWorld + Interop in Las Vegas last year, we got a lot of feedback from people. A lot of the features and functionality that people were asking for have been built into .NET Server. So I think that people are going to be very, very pleased with this next version of the server product coming out.

Jason: This customer is wondering about the node naming consistency between the NetBIOS name and the DNS name — I guess they came in late in the presentation: Do you have any comments about that, or if you can talk about the naming consistency between these two? We’ve seen the recommendation for this in several KB articles, but we haven’t found a technical explanation as to why this recommendation was made.

Tim: Okay, if I understand the question correctly, in Windows 2000, if you right-clicked on My Computer, went to Properties, went to Network Identification, and then clicked on the More button and drilled right down in there, there’s a check box there that says, "Change your Windows 2000 DNS domain name to match the name of the domain," meaning the Active Directory domain that you joined. When you do that, it's the same thing as when you promote a server to a domain controller, you specify not only a DNS suffix that you’re going to use for that domain, but also a NetBIOS name for the domain. So it’s a very good practice to keep the NetBIOS name for your domain the same, if you can, as the DNS name or the name of your Active Directory domain.

Technical reasons? Well, I’m thinking if there are any articles, off the top of my head, that describe technical reasons for this. I can tell you this: I work with customers with DNS issues all the time, and this issue pops up quite often. What you can do is load up the Windows 2000 Support Tools, which are included on the Windows 2000 CD. And there’s a very useful tool that we use in there 100 times a day, called Netdiag.

When you run netdiag /debug, it gives you a lot of information. It tests a lot of things, like your domain membership. It tests DNS and so on, there are a lot of different tests in there. If you have changed your NetBIOS name to be different from your DNS name, that will show you whether or not the particular machine that you’re running it from can still communicate using both those different names. I recommend keeping them the same, just for simplicity, because what will end up happening is your NetBIOS, or downlevel domain name, is going to be different from your Active Directory DNS domain name. The way a client finds a domain depends on the client.

So to try to answer the question a little bit more directly, when a Windows 2000 client boots up, there are two ways that it locates a domain. There is a Windows NT 4.0-compatible domain locator server, and there is a Windows 2000 domain locator service. So on a Windows 2000 client, it’s going to try to use the Windows 2000 domain service, which uses DNS. If that fails, it’s going to fail over to the Windows NT 4.0-compatible domain locator server, and it’s going to end up using that NetBIOS name.

Now, that NetBIOS name is different from the other name that you have configured in Windows 2000. Will that cause problems? Well, it just depends on your infrastructure and how you have it designed.

I can tell you that it makes it harder to troubleshoot problems when your NetBIOS name is different from your DNS name. So just from a troubleshooting perspective, it does make matters difficult. Because, in a sense, that is a type of disjointed namespace, because your NetBIOS name is different from your DNS name. So without really spending a lot more time on it, that’s the short answer.

Jason: If I enable DDNS on my root zone, is it possible for a workstation to name itself "Mail" and add itself to a round robin list of mail servers?

Tim: I don’t think the computer itself can pick its own name, but if someone configured it to use a name, they could name the computer anything they want and try to do a DNS registration. Indeed, they could succeed, if they’re dynamically updating a Windows 2000 DNS server and that server hosts a zone, and is authoritative for a zone in which that client wants to register. As long as it meets all the prerequisites, it’s going to register in that domain.

Now, one way to prevent this from happening, and this customer is really describing name hijacking, where we might have a mail server or some other resource that has a valid reason for using that name, and along comes someone that has some malicious or mischievous intent, and they register another system using the same name, they could potentially, for instance, bump that mail server off the network. So our solution there is secure dynamic updates, where the client will securely update the server using encryption and signatures and that type of thing. They will make a name registration.

For instance, in this case, the mail server will dynamically update with the Windows 2000 DNS server. Now that server, the mail server, owns that record in the DNS database. There’s no client on the network now that can send a dynamic update for the same name and overwrite that existing record. Only that mail server can overwrite that existing record. So the solution here is to use secure dynamic updates in environments where name hijacking could occur.

Jason: Can I use BIND DNS integrated with an Active Directory-integrated zone without migrating to Windows 2000 DNS?

Tim: Sure, absolutely. A lot of our customers use BIND DNS in their infrastructures. As long as the BIND server supports SRV records and dynamic updates, it shouldn’t be a problem. I recommend, again, going to BIND versions 8.2.2 and later, simply because they seem to work better with our clients. I know there are BIND versions, like Windows 9x versions out now, that work very nicely with our clients. Obviously, if you have Windows 2000 clients, Windows 2000 servers work the best with those clients, because they’ve been designed with those clients in mind. So if you do have a BIND infrastructure, absolutely, you can continue to leverage that with our products, and we work hard to make sure that we interoperate as well as we can.

Jason: Here’s a hypothetical: Let’s say that two shadow IP servers are handling DNS and DHCP. Then, let’s say the Active Directory domain's namespace is a subdomain, such as corp.example.com, delegated to Windows 2000 DNS. The shadow IP servers are dynamically registering host records for the clients in example.com. Will the servers and clients have any problems resolving to each other, because the server host records will be downlevel from the client?

Tim: I think what they’re asking here is how the clients are going to be able to find the records. As long as the delegations are made from the parent servers down to the child servers, everything should be fine.

What happens here is, on a parent server that’s authoritative, let’s say example.com, if we have a child domain, let’s say development.example.com, what we can do is delegate development, that subdomain, down to another server. So when clients come up and tell that parent server, "Yes, I’m looking for someone in development.example.com," the parent server knows that it’s going to refer the client down to the child DNS server that’s hosting that child zone.

Now, the other thing you have to do in a scenario like that is make sure the DNS servers that are hosting the child zones are set to forward back up to the parent, so that if anyone asks them for something that they’re not authoritative for, they can go up to the parent, and the parent will give them a referral or answer the question directly. I hope that answers the question.

Jason: How would someone set up a reverse zone when using a subset of Class C? Can that zone be transferred to an ISP CNS server?

Tim: Yes, subnetted reverse lookup zones are possible, but they are a lot of work. One or two KB articles, which you can find in the Knowledge Base, describe how to configure subnetted reverse lookup zones. There are some caveats to that, as far as replicating them to other servers. All of those topics are documented in the Knowledge Base. So if you were to just go up to the KB on http://support.microsoft.com/, there’s a Knowledge Base search link there. Go there and query "DNS" "reverse lookup zone" and "subnetted", and you would find at least two articles that describe how to do this and what some of the issues are.

Jason: What are some of the most common issues of clients not dynamically updating DNS records?

Tim: Well, if clients aren’t doing dynamic updates, someone has to be doing it for them. Their records should be registered with DNS, in most cases. If those clients’ IP addresses never have to be used, it’s not that big of an issue. But the easiest way to do this is if you have clients that are not capable of doing dynamic updates, you can use a Windows 2000 DHCP server that will do the updates for them. That way, they get dynamically entered into Windows 2000 DNS. If you don’t need anybody to resolve those clients’ IP address, and there are no services that require that their IP addresses be resolved, you might not even have to have them registered in DNS. But typically, on a network today, you want to have all your clients resolved, because you want to administrate clients remotely. So you want to have access to their IP addresses all the time. Again, if the clients aren’t doing dynamic updates themselves, you want them to update DNS. You either enter the records in manually or use the DHCP service to update for them.

Jason: Is there a way to change the default one-hour interval for a Netlogon re-registration on a Windows 2000 domain controller?

Tim: That’s a good question. Off the top of my head, I don’t remember. I believe there is. I think there is registry value that you can change that with. Check out Q246804 (http://support.microsoft.com/support/misc/kblookup.asp?ID=246804). That has most of the details about dynamic updates, the registry values to control dynamic updates and secure dynamic updates. That’s a really good place to start, that one KB article. I believe there is way to do that.

Jason: If this is off-topic, let me know. The user has come in late, so I’m not really certain how it falls into the topic: How do I do a major restriction for zone transfers? I cannot use the GUI, because the number of zones installed does not permit it. Apart from that, how can I restrict my outside domain queries to my namespace clients only? This is an ISP scenario where I do not wish outside customers to query our DNS server for address not our own.

Tim: That’s a really good question. As far as the zone transfers goes, I’m not sure I understand. But as far as queries go, being able to control them, let’s say I’m an ISP or an ASP, and I have a bunch of customers, and I host their DNS records for them. So I have example.com, abc.tld, reskit.com, and so forth. I want people who belong to example.com to be able to query and get information on example.com, but I don’t want clients within example.com to be able to query and get information about abc.tld or reskit.com. I want to be able to control that. There’s no way to do that in Windows 2000 DNS.

I don’t know if they have any plans to build that into the product. You’re basically asking about a feature that they have in BIND DNS called allow-query, where you can specify a range of IP addresses so that the DNS server will only answer to clients with the source IP address that matches that range of IP addresses. So unfortunately, I’m sorry, we don’t have a feature that does that.

Jason: Can there be more than one non-Active Directory-integrated BIND primary DDNS server?

Tim: In the primary/secondary model, typically you only have one primary, so that changes to the database happen on that primary. Then, secondary servers get read-only copies of that database.

The question sounds like they’re interested in knowing how BIND handles dynamic updates to zones from different clients. So can you have multiple primary servers that handle these zones? I can’t tell you, for sure. I know in Windows 2000 the way we do it is with Active Directory replication and multi-master replication. Any Active Directory-integrated server can take updates and update a zone, and then those changes are replicated among all the DNS servers in that domain. How BIND does that, I’m not sure. I’m not sure if they do handle that.

Jason: The next question refers back to an earlier question that we had. The user asked what the RFC for .local was, and they followed up and said: I can’t find the .local RFC either. It seems to have been removed. Is it still safe to use, and I guess based on that, does Microsoft support .local?

Tim: I can’t make any statements about whether Microsoft supports .local or not. I can tell you this, I work with large corporate customers every day. Many of those customers, some of the largest corporations in the world, use a .local namespace. When they call us for support, it doesn’t matter what they called their domain. We tell them like it is, "You’ve come to us with a description of a problem, and we’re going to help you try to solve that problem." We keep our eye on the technical issue. So as far as .local goes, will that work with Windows 2000 DNS? Absolutely. We have a lot of customers who use .local in their namespaces. When you call us for support with that namespace, will I help you out? Absolutely, you bet.

Jason: Will a mail server, say Exchange, register its MX record, or is that a manual process?

Tim: That’s a good question. Exchange 2000, running on Windows 2000, will certainly register records. Now, do you want to register MX records manually, or do you want to register them dynamically? Most customers do this process manually. I’m not an Exchange expert. I’m sure that you could register them dynamically, but most customers want to have granular control over the records, so that they can determine what priority is used on each record. Now, there may be a mechanism to do that in Exchange 2000. I’m not sure.

Jason: I do want to take a moment and solicit some feedback from our audience. If you’ve tuned in for the first time to one of these Support WebCasts, or maybe you’ve come in many, many times, and I see a lot of friendly names out there already, we’re definitely interested in your feedback. As you know, we try to adapt this program according to your needs. These WebCasts are about you guys, so please send us any feedback that you have about the presentation, the presenter, the questions, or whether your questions were answered to your satisfaction. We’re going to take all that into consideration as this program grows and evolves.

You can just send feedback to supweb@microsoft.com. If you do that, you’ll probably want to refer to the WebCast that you’re commenting on. You can give the topic or just give the date in the subject line, and that way we can more easily determine where that feedback is going.

With that: How do I create a dual namespace, one for internal clients and one for external Internet clients, yet allow internal clients to access the Internet, and the external Internet clients access only the external namespace?

Tim: That’s a good question. There are a few different ways that you can do that. The scenario is this: you have a namespace that may or may not be the same internally and externally. You have internal DNS servers, and you have external DNS servers. The external DNS servers host your Internet records, and the internal DNS servers host your internal records. You want to know how internal clients get to internal resources, but yet are still able to get to external resources. That becomes a complex issue when you have a namespace that uses the same name inside and outside.

That’s a good question. A lot of our customers get around that problem partially by using Microsoft Internet Security & Acceleration Server. ISA has a firewall client that is installed on clients if you need it. It also has a Web proxy client that you configure your Internet Explorer to use. So when you type in a name, you have very granular control inside Internet Explorer, whether to allow the client to resolve that name using its local DNS server, or resolve that name out on the Internet.

So the short answer to your question is, yes, Internet Explorer has that functionality built into it. If you’re using a Winsock application other than Internet Explorer, some sort of custom application, or an application that you bought somewhere and it uses Winsock calls, you could use the firewall client that you install from ISA to control that functionality as well. So basically there’s a domain filter that you can say, "I want to go internal or external, based on these names, these IP addresses, and so forth."

Jason: Can an Active Directory-integrated zone, a primary zone and a secondary, exist in a domain simultaneously?

Tim: Okay, I think I understand the question, where we have a server that has an Active Directory-integrated zone on it called, let’s say, example.com. That’s Active Directory-integrated, and we want to know if we can have a secondary zone that’s not Active Directory-integrated, for that zone. The answer is yes. Again, Active Directory integration simply defines where the records are being stored. Are they being stored inside the Active Directory database? Are they being stored on the text file? If we had an Active Directory-integrated zone, that would be considered a primary. Then, you have the secondary zone out on another DNS server. Yes, they’ll do zone transfers from the primary, the Active Directory server, out to the secondary without a problem. I hope that answers the question.

Jason: We did get a couple more questions into the queue: What DNS records are required for workstations to log on to the domain?

Tim: That’s a good question. The workstation itself has to be able to find the domain. If it’s a Windows 2000 workstation, I sort of mentioned this a little earlier, it has to find a domain controller. Then, it’s going to query that domain controller and find the domain and so forth.

So the way this works is, a Windows 2000 client boots up and wants to find the domain. As a Windows 2000 client, as long as it’s using that Windows 2000 domain locator service that I talked about earlier, as opposed to the Windows NT 4.0-compatible domain locator service, what it needs to do is find an LDAP server. So it’s going to send an SRV query to DNS and ask for an SRV record for an LDAP server. If it gets a response and is able to find an LDAP server, then it’s going to use LDAP queries, which are different from DNS queries, but it’s going to query the LDAP server and find a list of domain controllers in that domain.

Now, the other thing it could do is query DNS and get a list of domain controllers for that domain, and then try to connect to LDAP that way. There are several ways they can do it. But basically they’re going to use the SRV records that the domain controllers are registering.

So if you really want to see what your particular clients are doing, you can install Network Monitor, which comes with the server CD, or you can download it from the Web. You just start up Network Monitor and let it run while the client is booting up. You’ll probably need two clients to do that, though. You’ll be able to see what your client is querying for and what the DNS server responses are.

Typically, all the records inside the Netlogon.dns file on a domain controller are used at some point or another by the client. So if you find that Netlogon.dns file on a domain controller, it will be on the hard drive, and just go pop it open. It’s a regular text file. You can have a look at all those records that it’s registering. Some of the records won’t be used by clients, because they’re used by domain controllers to replicate with other domain controllers. So some of the records aren’t absolutely critical for clients, but they’re very important for domain controllers to talk to other domain controllers.

Jason: Is there any specific consideration that should be made when adding static records to an Active Directory-integrated zone? Is the practice of adding the static host or CNAME records to an Active Directory-integrated zone frowned on, or is this a normal practice, and are there any negative implications to adding static records in this way?

Tim: No, there are no limitations, and it’s not frowned upon or anything like that. Prior to Windows 2000, when Windows NT 4.0 was released, that was the way things were. You added records statically to DNS, and they sat there until you deleted them or changed them. It's the same thing with Windows 2000. Although it supports dynamic updates, it still works in the classic DNS server sense, where you can add static records, keep them, change them, and do whatever you want with them on the server.

So just because it supports dynamic updates doesn’t mean that static records are now frowned upon. The deal with dynamic updates is, they help you with administration. So they register, then the aging and scavenging can get rid of them if they become stale. It just takes that off your plate as an administrator, but if you have a need to register names and have them sit there forever, there’s not a problem with that. That’s a regular administrative function, you bet.

Jason: When a primary DHCP server updates DNS for down-level clients and that server goes down, the secondary DHCP server does not own the records. If the primary DHCP can’t be recovered, what happens?

Tim: That’s a good question. If we’re using dynamic updates, it’s not a big deal. The other DHCP server can do a registration for the client, obviously using a different IP address. So it’s going to go ahead. The way that that database is indexed is by name. So it’s going to make a name registration for that client using a new IP address.

The scenario becomes a little bit more complex when we’re using secure dynamic updates. So DHCP server A does a secure dynamic update on behalf of one of the clients. Then, that server goes down. Well, that server owns that secure dynamic update record inside of DNS. No other machine can update that record. So when the other DHCP server tries to send a secure dynamic update for the same record, or one with the same name, the DNS server is not going to allow it to go through, because it does not own that record.

So the way they work around this issue is with a security group called the DNS Proxy Group. You add your DNS servers into that group. The idea is that any server that’s a member of that group will be able to overwrite secure dynamic updates from other servers in that group. So that’s the way they work around that.

Jason: This is a follow-up to this question: Can the Active Directory-integrated zone, the primary zone and the secondary exist in the domain simultaneously? The follow-up question is: Is there any possibility to transfer the zone from an Active Directory-integrated zone to a secondary zone?

Tim: Absolutely. There are many different ways to do that. I mentioned a KB article earlier in the presentation that describes in detail how to migrate from Windows NT 4.0 and BIND servers to a Windows 2000 server, but this scenario is a little different, in that we have a Windows 2000 Active Directory-integrated zone, and we want to somehow migrate those records to let’s say a standard zone on another server. Not a problem.

Let’s say that other server is a Windows 2000 DNS server, and it’s in the same domain as the DNS server that hosts the records already. This makes it really easy. What you do is, you just create a new zone, using the same name, on the other DNS server and Active Directory integrate it. The next time the Active Directory replication cycle happens, all the records will be replicated over from the original DNS server to the new DNS server. Then, all you have to do is go into the properties of that zone on the new DNS server and change it from Active Directory-integrated to standard primary, standard secondary, or whatever you want. It will write the files down to the text file on the hard drive of that DNS server, and you’re done.

Tim: I’m not sure I understand the question, but basically what’s going to happen with the client is, it has to find out who is authoritative for the zone in which it wants to register, so it can query its local DNS server, and that local DNS server may or may not be authoritative for that zone. If it’s not, it should be set up to forward to another DNS server which will be able to find the answer. Then it just sends the update to that other server. I hope that was on target. I’m not sure.

Jason: Are A and PTR records for the workstation required to log on and maintain itself on the domain?

Tim: Strictly speaking, no. PTR records are typically completely optional. PTR records are used by some applications for security purposes, where we know the IP address but we want to double-check what the name of the particular workstation is before we give them access to a particular application. That’s a typical use for PTR records. They’re not required.

The A record registration typically isn’t required for domain access either, although in some cases (I don’t want to go too far down that road), like with Windows NT 4.0, for instance, it has a similar mechanism with WINS, where it tries to find a list of domain controllers in WINS, and then tries to connect using NetBIOS. In that scenario, the domain controller has to set up a secure channel with the client. It does this not by the client finding the domain controller via WINS, but the domain controller finding the client through WINS. If your Windows 2000 server, for some reason, fails over to the Windows NT 4.0-compatible domain locator from the Windows 2000 domain locator, you could end up having to have name registrations in both directions.

So I don’t want to categorically say no, you don’t need them, because in some instances, you will. But typically, you don’t need to have an A record registered for a client to find the domain. You could disable dynamic updates altogether on the client, and it would still query the DNS server to find the appropriate SRV records and so on for the domain.

Jason: Is it possible for a Windows 2000 system to register more than one host name with DDNS on Windows 2000 server? That is, register a long, detailed host name and also a short host name?

Tim: Yes, it is possible. You may run into some issues doing that, when it comes to accessing shares. One of the issues, and there’s a KB article that describes this, is if you looked up something like "alias" and "SMB" in the Knowledge Base, where under Windows NT 4.0, you simply go to the Run command and type //servername/sharename and you can access it, even if that server name is an alias or a CNAME. Under Windows 2000, they have a security feature that doesn’t allow access by an alias. So that if you had an alias published in DNS and you tried to use that alias to access the SMB server and a share on a target Windows 2000 server, it would say, "No, I’m not going to let you do that."

So some of our customers complained and wanted that feature changed. So in Service Pack 2, they added a hotfix for that problem, and a registry entry was added, so that you can control what aliases your SMB server will support connections on.

Jason: Regarding caching-only DNS, is there a way to save the acquired cached queries that are stored in RAM?

Tim: I’ve had that question before. In Windows 2000, there is no way to do that, to my knowledge. I know that there were quite a few questions about the cache in that regard, "how can we dump the cache" and "how can we see what’s in cache." In Windows 2000, you’re pretty much limited to just viewing the cache through the GUI. There’s no utility that I know of that will dump the cache out for you to have a look at it in a text file or something like that, which would be very useful. I have no idea whether that feature or a utility like that will be included with .NET Server or future DNS server products, but I agree, it would be something useful to have.

Jason: Concerning the DHCP proxy group, did you say to put the DNS or a redundant DHCP server into that group?

Tim: The DHCP servers. So the idea is, any server that’s a member of that group is going to be able to overwrite secure dynamic updates. So because the DHCP server is doing the dynamic update on behalf of the client, it’s going to own the records. So if another server is going to overwrite the records that that DHCP server registered, they both have to be in that group.

I would suggest making sure that you have Service Pack 2. There was a bug in the initial release of Windows 2000 with that group in particular. So I would recommend going to Service Pack 2. In fact, I’d check the KB and just make sure that there are no hotfixes. I know that there are at least two KB articles coming out, either going through tech review right now, or they may have been published already, with regard to that group, how to use them, and how to avoid problems with them.

Jason: If I add a static record to Active Directory DNS, is there any way to tell, in DNS manager, which ones they are? We have in excess of 10,000 static entries in our UNIX DNS. I would like to move some of them into the Active Directory, but I don’t want to end up with the same ugly mess in the Active Directory side. Also, is there any way around static entries for Windows 2000 servers that need an alias? We run into this with Web-based applications.

Tim: Right. As far as being able to determine whether a record is dynamic or whether it is static, I believe you can use Nslookup and each record will have a time to live. That time to live should be counting down on the dynamic records, and the static records will have either an outrageously high time to live or it simply won’t be counting down. I think they have a really high time to live, if I remember right, but you can use Nslookup or DNS CMD to try to determine which records are static and which records are dynamic.

As far as the CNAME thing goes, yes, you want to make sure that when you’re importing records from your BIND servers that you make appropriate use of CNAME records. You don’t want to bring in a bunch of records and have a whole bunch of CNAMEs for a server, unless there’s an application that requires something like that. I don’t know what else to tell you about that.

Jason: In Active Directory, do OUs get translated to subdomains in DNS? If yes, then for each OU, there will be a corresponding subdomain, which may not be ideal for a particular company. Is there a way in which I can have many OUs but not that many subdomains, and still get the FDQN of a host under a particular subdomain resolved properly?

Tim: Well, I think the short answer there is, an organizational unit isn’t necessarily translated to a subdomain in DNS. An organizational unit is an object inside the Active Directory database that’s used to organize other objects inside the Active Directory database. DNS is used to help organize your network and allow clients to get access to network resources. Yes, we leverage the Active Directory to replicate DNS records, but an organizational unit doesn’t necessarily get translated to a subdomain or a zone inside DNS. So I think that that kind of answers the question right off the top.

Jason: In a pure DNS environment, what happens to Dfs name resolution?

Tim: I’m not a Dfs expert. We have a team, the Directory Services Team within Product Support Services, that deals with Dfs. They’re pretty savvy with DNS as well. So they would be the guys to ask. I believe they have some online discussion groups you can go up to and get some expert advice from those guys.

Jason: Okay. I’ve not gotten any more clarifying information. I was trying to follow-up with one user through the Message Center, and I’ve not gotten a very good answer from him, but here’s the question, or here’s the comment he makes, and see if you can determine a question from it. NBT or NetBIOS functionality is not required, and I believe he’s following up on a question about the Windows 2000 system, is it possible to register more than one host name with DDNS on a Windows 2000 server. Okay, so his follow-up again: I think the presenter mentioned a KB article about allowing multiple host names to be automatically registered with Windows 2000 DDNS. Did you have a KB article on that?

Tim: No, I don’t have a KB article on that. I think that Q246804 (http://support.microsoft.com/support/misc/kblookup.asp?ID=246804) is a good place to start, because that has all the registry values for dynamic updates on clients and domain controllers and that sort of thing. That would be a good place to start, but off the top of my head, I don’t remember if there’s an article specifically on CNAMEs and dynamic registration.

Jason: Okay, that does clear all the questions we have in the queue. So I am going to wrap up this session. I want to thank everybody for coming in today and asking good questions. Thanks to Tim for sticking around through the many questions we got there right at the end. I appreciate everyone’s participation today.

Again, we’re very interested in your feedback regarding the WebCast program. If you want to send in your feedback, you can send us an e-mail at supweb@microsoft.com. Just reference the date or the title of the WebCast in the subject line, and that should be good enough to route it.

We hope you join us again in the near future. Thank you, and good-bye.