- Shopping Bag ( 0 items )
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 ...
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:
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. Readers will acquire a grounding in security issues, system tuning, caching, zone change notification, troubleshooting, and planning for growth.
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 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.
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.
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 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....
Posted November 28, 2001
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.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.