DNS on Windows 2000

DNS on Windows 2000

4.0 1
by Matt Larson

DNS on Windows 2000 is a special Windows-oriented edition of the classic DNS and BIND. The Domain Name System (DNS) is one of the Internet's fundamental building blocks: the distributed host information database that's responsible for translating names into addresses, routing mail to its proper destination, and many other services. As the preface


DNS on Windows 2000 is a special Windows-oriented edition of the classic DNS and BIND. The Domain Name System (DNS) is one of the Internet's fundamental building blocks: the distributed host information database that's responsible for translating names into addresses, routing mail to its proper destination, and many other services. As the preface says, if you're using the Internet, you're already using DNS—even if you don't know it.Besides covering general issues like installing, setting up, and maintaining the server, DNS on Windows 2000 tackles those specific to the Windows environment: integration between DNS and Active Directory, conversion from BIND to the Microsoft DNS server, and registry settings. You'll also acquire a grounding in:

  • Security issues
  • System tuning
  • Caching
  • Zone change notification
  • Troubleshooting
  • Planning for growth
If you're a Windows administrator, DNS on Windows 2000 is the operations manual you need for working with DNS every day; if you're a Windows user who simply wants to take the mystery out of the Internet, this book is a readable introduction to the Internet's architecture and inner workings.Topics include:
  • What DNS does, how it works, and when you need to use it
  • How to find your own place in the Internet's namespace
  • Setting up name servers
  • Integrating Active Directory with DNS
  • Dynamic updates, storing zone information in Active Directory, and incremental zone transfers
  • Using MX records to route mail
  • Configuring hosts to use name servers
  • Subdividing domains (parenting)
  • Securing your name server: preventing unauthorized zone transfers
  • Mapping one name to several servers for load sharing
  • Troubleshooting: using nslookup, diagnosing common problems

Product Details

O'Reilly Media, Incorporated
Publication date:
Edition description:
Second Edition
Product dimensions:
6.96(w) x 9.28(h) x 0.80(d)

Read an Excerpt

Chapter 11: New DNS Features in Windows 2000

In this chapter:
Active Directory
Dynamic Update
Aging and Scavenging
Incremental Zone Transfer
Unicode Character Support

The Hatter opened his eyes very wide on hearing this; but all he said was, "Why is a raven like a writing desk?"
"Come, we shall have some fun now!'" thought Alice. "I'm glad they've begun asking riddles--I believe I can guess that," she added aloud.
"Do you mean that you think you can find out the answer to it?" said the March Hare.

Windows 2000 includes many new DNS bells and whistles. The DNS server itself is much improved, with more features than ever that make it more functional and easier to manage. From a client perspective, Windows 2000 as an operating system is more dependent on DNS than any previous operating system from Microsoft. And then there's Active Directory....

Active Directory

Active Directory is the major new feature of Windows 2000. It's a hierarchical database of information about all objects in the network: computers, printers, users, and so on. Both users and computers access the information in Active Directory. The Active Directory database is partitioned into domains for administrative purposes, and one or more domain controllers store information about particular domains. (Compare this to DNS's namespace, which is partitioned into zones, with one or more name servers authoritative for each zone.) For more--much more--information about Active Directory, see Windows 2000 Active Directory by Alistair G. Lowe-Norris (O'Reilly).

The most important fact about Active Directory for our purposes is that it is integrated tightly with DNS.

Active Directory Domain Names

The most obvious connection between Active Directory and DNS is the naming of domains--Active Directory domains, that is. In the past, under Windows NT, domain names followed the NetBIOS host-naming rules: names consisted of a single label (i.e., no dots) and could contain letters, digits, and limited punctuation. Most Windows dialog boxes forced domain-name input to uppercase, so while they were case-insensitive, you usually saw domain names written in all uppercase. For example, Movie University's Windows NT domain name was MOVIEU.

With Windows 2000, all Active Directory domain names are DNS domain names, but--and this is important--not every DNS domain name is an Active Directory domain name.1 So while an organization's Active Directory namespace resembles its DNS namespace, the two don't have to be and probably won't be identical. While it's beyond the scope of this book to give an exhaustive explanation of Active Directory namespace design, we can give you some examples to clarify the connection between the naming of Active Directory domains and DNS domains.

Consider Movie University. After reading this far, you're familiar with Movie U.'s DNS namespace: the apex (or top) of the namespace is movie.edu, and there are subdomains named fx.movie.edu, classics.movie.edu, and comedies.movie.edu. This namespace is represented in Figure 11-1.

Now let's talk about Movie U.'s Active Directory namespace. An organization's Active Directory domain names correspond to some of its DNS domain names, and the Active Directory domain at the top of an organization's domain tree usually corresponds to a subdomain of the apex of its DNS namespace. In Movie U.'s case, however, the root of the Active Directory domain tree is the same as the apex of the DNS namespace, movie.edu. Figure 11-1 shows Movie U.'s Active Directory domain tree beside its DNS namespace. Note how the two diverge, though. For various administrative reasons, the folks over in fx.movie.edu need to run their own Active Directory domain. But everyone else at Movie U. is a part of the movie.edu Active Directory domain, even though individual hosts fall into different DNS domains.

DNS as Location Broker

You may be wondering why Active Directory domain names are DNS domain names. The answer is that Windows 2000 systems (running in native mode) use DNS as a location broker; that is, to find services. Previous versions of Windows used NetBIOS to find domain controllers, but Windows 2000 hosts use DNS. Take the case of a Windows 2000 Professional host at Movie U. that's been joined to the movie.edu Active Directory domain. When this system boots up, it sends a series of DNS queries to its configured name server to find a domain controller for the movie.edu domain.

The SRV resource record

The particular query sent by the Windows 2000 client is for a resource record type you may not have heard of: the SRV (service location) record. The SRV record, introduced in RFC 2782, is a general mechanism for locating services. Before we can talk in detail about exactly how a Windows 2000 client finds its domain controller using SRV records, we need to describe the SRV record itself.

Locating a service or a particular type of server within a zone is a difficult problem if you don't know which host it runs on. Some zone administrators have attempted to solve this problem by using service-specific aliases in their zones. For example, at Movie U. we created the alias ftp.movie.edu and pointed it to the domain name of the host that runs our FTP archive:

ftp.movie.edu.    IN    CNAME    plan9.fx.movie.edu.

This makes it easy for people to guess a domain name that will get them to our FTP archive and separates the domain name people use to access the archive from the domain name of the host on which it runs. If we were to move the archive to a different host, we could simply change the CNAME record.

Another option, for clients that understand it, is the SRV record. In addition to simply allowing a client to locate the host on which a particular service runs, SRV provides powerful features that allow zone administrators to distribute load and provide backup services, similar to what the MX record provides.

A unique aspect of the SRV record is the format of the domain name to which it's attached. Like the service-specific aliases described earlier, the domain name an SRV record is attached to gives the name of the service sought, but it also includes the protocol it runs over, concatenated with a domain name. The labels representing the service name and the protocol begin with an underscore to distinguish them from labels in the domain name of a host. So, for example:


represents the SRV records someone ftping to movie.edu should retrieve in order to find the movie.edu FTP servers, while:


represents the SRV records someone accessing the URL http://www.movie.edu should look up in order to find the www.movie.edu web servers.

The names of the service and protocol must come from the latest Assigned Numbers RFC (the most recent as of this writing is RFC 1700) or be unique names used only locally. Don't use the port or protocol numbers, just the names. When entering SRV records with the DNS console, the service name is limited to eight common services.

The SRV record has four resource record-specific fields: priority, weight, port, and target. Priority, weight, and port are unsigned 16-bit numbers (between 0 and 65535). Target is a domain name.

Priority works similarly to the preference in an MX record: the lower the number in the priority field, the more desirable the associated target. When searching for the hosts offering a given service, clients should try targets with the same priority value before trying those with a higher value in the priority field (lower priority values indicate higher priority--confusing, eh?).

Weight allows zone administrators to distribute load to multiple targets. Clients should query targets at the same priority in proportion to their weight. For example, if one target has a priority of zero and a weight of one and another target has a priority of zero but a weight of two, the second target should receive twice as much load (in queries, connections, etc.) as the first. It's up to the service's clients to direct that load: they typically use a system call to choose a random number. If the number is, say, in the top one-third of the range, they try the first target, and if the number is in the bottom two-thirds of the range, they try the second target.

Port specifies the port on which the service being sought is running. This allows zone administrators to run servers on nonstandard ports. For example, an administrator can use SRV records to point web browsers at a web server running on port 8000 instead of the standard HTTP port (80).

Finally, target specifies the domain name of a host on which the service is running (on the port specified in the port field). Target must be the canonical name of the host (not an alias), with address records attached to it....

Meet the Author

Matt Larson started Acme Byte & Wire, a company specializing in DNS consulting and training, with Cricket Liu in January 1997. Previously, he worked for Hewlett-Packard, first as Cricket's successor as hp.com hostmaster, then as a consultant in HP's Professional Services Organization. Matt graduated from Northwestern University in 1992 with two degrees: a bachelor of arts in computer science and a bachelor of music in church music/organ performance. He lives in Bethesda, Maryland, with his wife, Sonja Kahler, and their two pugs. In his spare time he enjoys playing the 10-rank pipe organ in his house and flying light airplanes. Cricket worked for five and a half years at Hewlett-Packard's Corporate Network Services, where he ran hp.com, one of the largest corporate domains in the world, and helped design the HP Internet's security architecture. Cricket left HP in 1997 to start his own company, Acme Byte & Wire, with his friend and co-author Matt Larson. Network Solutions acquired Acme Byte & Wire in June of 2000, and then subsequently, Network Solutions merged with VeriSign. Cricket became Director of DNS Product Management of the merged company, helping determine which new DNS-related products VeriSign would offer.

Cricket Liu matriculated at the University of California's Berkeley campus, that great bastion of free speech, unencumbered Unix, and cheap pizza. He joined Hewlett-Packard after graduation and worked for HP for nine years. Cricket began managing the hp.com zone after the Loma Prieta earthquake forcibly transferred the zone's management from HP Labs to HP's Corporate Offices (by cracking a sprinkler main and flooding Labs' computer room). Cricket was hostmaster@hp.com for over three years, and then joined HP's Professional Services Organization to cofound HP's Internet Consulting Program. Cricket left HP in 1997 to form Acme Byte & Wire, a DNS consulting and training company, with his friend (and now co-author) Matt Larson. Network Solutions acquired Acme in June 2000, and later the same day merged with VeriSign. Cricket worked for a year as Director of DNS Product Management for VeriSign Global Registry Services. Cricket joined Men & Mice, an Icelandic company specializing in DNS software and services, in September, 2001. He is currently their Vice President, Research & Development. Cricket, his wife, Paige, and their son, Walt, live in Colorado with two Siberian Huskies, Annie and Dakota. On warm weekend afternoons, you'll probably find them on the flying trapeze or wakeboarding behind Betty Blue.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >

DNS on Windows 2000 4 out of 5 based on 0 ratings. 1 reviews.
Guest More than 1 year ago
This was a good book and a solid read. It was slanted a bit towards a Primary/Secondary Zone DNS setup vs AD integrated, but it was not lacking useful information. Well worth the price.