Microsoft Windows 2000 DNS: Implementation and Administration (White Book)

Microsoft Windows 2000 DNS: Implementation and Administration Kevin Kocis 800 East 96th St., Indianapolis, Indiana, 46...

Author: Kevin Kocis

69 downloads 1020 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Microsoft Windows 2000 DNS: Implementation and Administration Kevin Kocis

800 East 96th St., Indianapolis, Indiana, 46240 USA

Microsoft Windows 2000 DNS: Implementation and Administration

Neil Rowe

MANAGING EDITOR Matt Purcell

PROJECT EDITOR Natalie Harris

COPY EDITOR Cheri Clark

INDEXER

International Standard Book Number: 0-672-32200-5

Rebecca Salerno

Library of Congress Catalog Card Number: 2001089503

PROOFREADER

Printed in the United States of America

Jody Larsen

First Printing: September 2001 02

ACQUISITIONS EDITOR

Steve Rowe

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

03

Jeff Koch

DEVELOPMENT EDITOR

Copyright © 2002 by Sams

04

ASSOCIATE PUBLISHER

01

4

3

2

1

Trademarks All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.

TECHNICAL EDITOR Michael Schene

TEAM COORDINATOR Vicki Harding

INTERIOR DESIGNER Dan Armstrong

COVER DESIGNER Aren Howell

PAGE LAYOUT Octal Publishing, Inc.

Contents at a Glance Introduction 1

Domain Name System Fundamentals

2

DNS Server Operations

3

Active Directory and DNS

4

Planning and Installing Windows 2000 DNS

5

Configuring DHCP and DNS Client Configurations

6

Administering DNS Servers Using MMC

7

Windows 2000 and DNS Security

8

Windows 2000 DNS and WINS Replication

9

BIND and Windows 2000 Interoperability

10

DNS Best Practices and Maintenance

11

Troubleshooting DNS

12

Remote and Command-Line Utilities for DNS Management

A

Resource Record Types

B

Internet Standards Supported by Windows 2000 DNS Index

Contents Introduction

1

1

Domain Name System Fundamentals 3 DNS Architecture ....................................................................................4 DNS Hierarchy ..................................................................................5 DNS Core Physical Components ..........................................................14 Name Servers ..................................................................................14 Zones and Zone Files ......................................................................15 Resource Records ............................................................................16 Resolvers ........................................................................................17 DNS Specifications and RFCs ..............................................................17 Governing Agencies ........................................................................17 DNS Naming Restrictions ..............................................................18 New Features of Windows 2000 DNS ..................................................19 Active Directory Integration ............................................................19 Secure Dynamic Updates ................................................................20 Record Aging and Scavenging ........................................................20 Unicode Character Support ............................................................21 New Administrative Tools ..............................................................21 Summary ..............................................................................................22

2

DNS Server Operations 23 Name Server Roles ..............................................................................24 Primary Name Server ......................................................................24 Secondary Name Server ..................................................................25 Master Name Server ........................................................................27 Forwarders and Slaves ....................................................................27 Caching Only ..................................................................................29 Zones and Database Files ....................................................................30 Primary Zones ................................................................................32 Secondary Zones ............................................................................32 Active Directory–Integrated Zones ................................................32 Resource Records ............................................................................35 Naming Standards ..........................................................................44 Resolver Roles ................................................................................46 The Name Resolution Process ..............................................................47 Recursive Queries ............................................................................47 Iterative Queries ..............................................................................47 Inverse Queries ................................................................................49 Delegation and Glue Records ..........................................................49 Root Hints ........................................................................................50

vi

MICROSOFT WINDOWS 2000 DNS: IMPLEMENTATION

AND

ADMINISTRATION

DNS Load Balancing and Caching ......................................................50 Load Balancing (Round Robin) ......................................................50 Caching and TTL ............................................................................51 Zone Transfers ......................................................................................52 Full Zone Transfer ..........................................................................53 Incremental Transfer ........................................................................53 DNS Notify ......................................................................................54 Summary ..............................................................................................54 3

Active Directory and DNS 55 Windows 2000 Active Directory ..........................................................56 Active Directory Features ..............................................................56 Active Directory Logical and Physical Components ......................62 Windows 2000 DNS Features and Components ..................................65 New DNS Resource Record Support (SRV) ..................................66 DNS Record Registration ................................................................67 _msdcs Subdomain ..........................................................................71 Dynamic DNS Update Support ......................................................72 Dynamic DNS Process ....................................................................73 Legacy DNS Cohabitation/Integration ............................................78 How DNS integrates with Active Directory ........................................78 Benefits of Active Directory Integration ........................................79 Windows 2000 DNS and WINS ......................................................80 WINS Query Process ......................................................................81 WINS Integration ............................................................................83 Summary ..............................................................................................85

4

Planning and Installing Windows 2000 DNS 87 Planning DNS Installation/Integration ................................................88 Registering Domain Names ............................................................89 DNS Namespace Overlap ................................................................89 Windows 2000 DNS and Active Directory Considerations ............92 Non–Windows 2000 DNS and Active Directory Considerations ..93 Zone Planning Recommendations ..................................................94 Planning a DNS Structure With Active Directory ..........................94 Planning the Number of DNS Servers and Their Location ..........102 Enterprise Planning ......................................................................104 Installing Windows 2000 DNS ..........................................................105 Administrative Requirements ........................................................106 Pre-Installation ..............................................................................106 Setting Up DNS for Active Directory ..........................................107 Configuring Servers ............................................................................109 Root Name Server ........................................................................110

CONTENTS Primary Name Server ....................................................................112 Secondary Name Server ................................................................112 Caching-Only Server ....................................................................113 Active Directory–Integrated Server ..............................................114 Verifying the Windows 2000 DNS Installation ............................115 Summary ............................................................................................116 5

Configuring DHCP and DNS Client Configurations 117 DHCP Server and Client Fundamentals ............................................118 DHCP Reservation Process ..........................................................118 DHCP Clients ................................................................................119 DHCP Server Terminology ..........................................................120 New for DHCP in Windows 2000 ......................................................123 DHCP and DNS Integration ..........................................................124 DHCP Server Monitoring Enhancements ....................................125 User Class Support ........................................................................125 Vendor Class Support ....................................................................126 Multicast Address Allocation ........................................................127 Unauthorized DHCP Server Detection ........................................127 Automatic Client Configuration ....................................................127 Windows 2000 DHCP Server Planning ..............................................128 Permissions ....................................................................................128 Windows 2000 DHCP Server Deployment ..................................129 BOOTP ..............................................................................................143 Dynamic DNS Update Configurations ..............................................145 Advanced DHCP/DNS Configuration Options ............................146 DHCP Leases ......................................................................................146 Optimizing Lease Management ....................................................147 Configuring Windows 2000 DHCP Server Clients ............................148 Windows 2000 Clients ..................................................................148 Windows NT Clients ....................................................................149 Windows 9x Clients ......................................................................149 Macintosh Clients ..........................................................................149 UNIX/Linux Clients ......................................................................150 Predefined Options for DHCP Clients ..............................................150 Summary ............................................................................................151

6

Administering DNS Servers Using MMC 153 Adding and Customizing the DNS Snap-in ......................................154 Administering and Configuring DNS Servers ....................................156 Adding DNS Servers ....................................................................156 Modifying DNS Servers ................................................................157 Managing DNS Server Properties in the MMC Console ..............159 Manual DNS Updates ....................................................................171

vii

viii


AND

ADMINISTRATION

Managing Zone Properties in the MMC Console ..............................171 General ..........................................................................................171 Start of Authority (SOA) ..............................................................173 Name Servers ................................................................................173 WINS ............................................................................................174 Zone Transfers ..............................................................................175 Security ..........................................................................................176 Managing Standard Primary and Secondary Zones ..........................177 Managing Resource Records in MMC ..............................................178 Managing Authority Records ........................................................179 Managing Other Resource Records ..............................................180 Modifying Resource Records ........................................................184 Resource Record Aging and Scavenging ......................................185 Summary ............................................................................................190 7

Windows 2000 and DNS Security 193 Windows 2000 Security ......................................................................194 The Active Directory Security Model ..........................................194 Kerberos Authentication ................................................................194 Object-Oriented Security ..............................................................196 Rights and Permissions ................................................................198 Security Descriptor ........................................................................199 Active Directory Object Security ......................................................201 Active Directory Objects ..............................................................202 Group Policy ......................................................................................204 Group Policy Fundamentals ..........................................................204 Windows NT 4.0 and Windows 2000 Policy Comparison ............205 Group Policy Administrative Requirements ..................................206 Group Policy Objects ....................................................................206 Creating Group Policy Objects ....................................................206 Configuring Group Policy ............................................................207 MMC Snap-in Extension Model ..................................................208 Settings and Templates ..................................................................211 Linking GPOs ................................................................................211 Group Policy Inheritance ..............................................................212 Windows 2000 DNS Security ............................................................214 DNS Service Security ....................................................................214 DNS Zone and Record Security ....................................................214 Dynamic DNS Security ................................................................217 DNS Client Security ......................................................................219 Summary ............................................................................................221

CONTENTS 8

Windows 2000 DNS and WINS Replication 223 DNS Replication ................................................................................224 Active Directory Replication ........................................................224 Enterprise Replication ..................................................................226 Replication Topology ..........................................................................228 Transports and Protocols ..............................................................228 Update Tracking ............................................................................228 Secondary Zone Replication ........................................................229 Managing Zone Transfers ..................................................................230 Incremental Zone Transfers ..........................................................230 WINS Configuration, Replication, and DNS Integration ..................230 WINS Server Installation ..............................................................230 WINS Configuration ....................................................................231 WINS and DNS Integration ................................................................238 WINS Lookup Integration ............................................................238 Configuring WINS Resolution ......................................................239 Summary ............................................................................................244

9

BIND and Windows 2000 Interoperability 245 Understanding BIND ..........................................................................246 BIND History ................................................................................246 BIND Configuration Files ............................................................246 Comparing BIND and Windows 2000 DNS File Types ....................247 BIND Security ..............................................................................249 Integrating BIND with Windows 2000 DNS ......................................250 Implement Windows 2000 DNS to Replace Current DNS ..........250 Integrating Windows 2000 DNS with BIND ......................................253 BIND as Root DNS ......................................................................253 Windows 2000 DNS as Root DNS ..............................................259 Disadvantages and Considerations ....................................................262 Using WINS and WINS-R Records ..............................................262 Using UTF-8 Characters Format ..................................................263 Non–RFC Compliant BIND Data ................................................263 BIND as Primary and Secondary (No Windows 2000 DNS) ......263 Interoperability Planning ..............................................................263 Summary ............................................................................................264

10

DNS Best Practices and Maintenance 265 DNS Suggested Standards ..................................................................266 DHCP Suggested Standards ..............................................................267 WINS Suggested Standards ................................................................269 Internet DNS Suggested Standards ....................................................270 Basic DNS Configuration Recommendations ....................................270

ix

x


AND

ADMINISTRATION

DNS Server Location ....................................................................270 DNS Server Redundancy ..............................................................271 DNS Server Configuration Verification ..............................................271 Verifying Server Configuration ....................................................272 Verifying Query Responses from the DNS Server ......................273 Verifying the Forward Lookup Zone ............................................274 Verifying Reverse Lookup Zones and PTR Resource Records ....275 Verifying DNS Configuration After Installing Active Directory ..275 Monitoring DNS Server Performance ................................................277 System Monitor ............................................................................279 DNS Server Performance Counters ..............................................283 Logging DNS Servers ..................................................................288 Tuning Advanced Server Parameters ..................................................291 Summary ............................................................................................292 11

Troubleshooting DNS 293 The Troubleshooting Process ..............................................................295 Troubleshooting Name Resolution ....................................................297 Registering Names and Locating Domain Controllers ................297 Identifying and Verifying DNS Problems ..........................................297 Verifying DNS Configuration ......................................................297 Solving Problems with Dynamic Update ..........................................305 Troubleshooting Zone Problems ........................................................307 DNS Server Log Errors and Event Codes ..........................................308 Informational Events ..........................................................................309 Initialization Errors ........................................................................309 WINS and NBSTAT Errors ..........................................................309 RPC Initialization Error ................................................................310 Winsock/Interface Initialization Errors ........................................310 Registry Boot Errors ......................................................................312 General Database Load Errors ......................................................313 File Loading Errors ......................................................................314 Boot File Problems ........................................................................314 Database File Parsing Problems ....................................................315 Directive Problems ........................................................................316 Domain Name Problems ..............................................................316 Resource Record Problems ..........................................................317 DHCP Server Issues ..........................................................................319 Network Monitor Analysis ................................................................319 Installing Network Monitor ..........................................................319 A Sample Network Frame of DNS Dynamic Update ..................320 The Capture Process ......................................................................321 Summary ............................................................................................321

CONTENTS 12

Remote and Command-Line Utilities for DNS Management 323 IPCONFIG ..........................................................................................324 NSLOOKUP ......................................................................................326 PathPing ..............................................................................................329 DNSCMD ..........................................................................................330 Syntax ............................................................................................330 DNSCMD Switches ......................................................................331 NBTSTAT ..........................................................................................335 The NetBIOS Remote Cache Table ..............................................336 NetDiag ..............................................................................................337 NetDiag Tests ................................................................................339 NETSH ................................................................................................342 NETSH Contexts ..........................................................................342 Saving Output from Troubleshooting Tools ......................................344 Summary ............................................................................................344

A

Resource Record Types 345 A—Host Address (A) Resource Record ............................................346 AAAA—IPv6 Host Address (AAAA) Resource Record ..................346 AFSDB—Andrew File System Database (AFSDB) Resource Record ....346 ATMA—Asynchronous Transfer Mode Address (ATMA) Resource Record ................................................................347 CNAME—Canonical Name (CNAME) Resource Record ................347 HINFO—Host Information (HINFO) Resource Record ....................347 ISDN—Integrated Services Digital Network (ISDN) Resource Record....348 MB—Mailbox (MB) Resource Record ..............................................348 MG—Mail Group (MG) Resource Record ........................................348 MINFO—Mailbox Mail List Information (MINFO) Resource Record....349 MR—Mailbox Renamed (MR) Resource Record ..............................349 MX—Mail Exchanger (MX) Resource Record ................................350 PTR—Pointer (PTR) Resource Record ..............................................350 RP—Responsible Person (RP) Resource Record ..............................350 RT—Route Through (RT) Resource Record ......................................351 SRV—Service Locator (SRV) Resource Record ................................351 TXT—Text (TXT) Resource Record ................................................351 WKS—Well-Known Service (WKS) Resource Record ....................352 X25—X.25 (X25) Resource Record ..................................................352

B

Internet Standards Supported by Windows 2000 DNS 353 RFCs: ..................................................................................................354 Drafts: ................................................................................................354 Index

xi

About the Author Kevin Kocis, MCSE, has been working in the Information Technology field for over 10 years. He is currently the Manager of Information Technology for a division of a Fortune 100 company, where he strategizes network and server infrastructure, Oracle implementation, platform and interoperability issues (Windows, UNIX, Macintosh). He has written several articles and reviews for Microsoft Certified Professional magazine. In addition, Kevin has presented at TechMentor conferences in Atlanta and San Francisco on Windows 2000 Server.

Dedication This book is dedicated to Patto, the love of my life, my eternal partner, my Caribbean Princess. I love you. . .

Acknowledgments I would like to thank the editing staff at Sams (Neil and Steve) for their encouragement and the Brickyard. Thanks to Michael Schene once again for his technical editing prowess. Many thanks to Ronnie G and Jill for their great wines and late-night discussions (MOVE!!). Hats off to my awesome technical staff in Northbrook, Tempe, and Pasadena—you guys rock! A special thanks to Bob Gentile and Greg Brinkmeier for their career support and guidance. Loving thanks to my three incredible children—Jeremy, Jordan, and Jennifer—who inspire me, make me laugh, and make me cry like nothing else in the world. I love you guys. Thanks for your patience.

Tell Us What You Think! As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we’re doing right, what we could do better, what areas you’d like to see us publish in, and any other words of wisdom you’re willing to pass our way. As an Associate Publisher for Sams, I welcome your comments. You can fax, email, or write me directly to let me know what you did or didn’t like about this book—as well as what we can do to make our books stronger. Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of mail I receive, I might not be able to reply to every message. When you write, please be sure to include this book’s title and author, as well as your name and phone or fax number. I will carefully review your comments and share them with the author and editors who worked on the book. Fax:

317-581-4770

Email:

[email protected]

Mail:

Jeff Koch Sams 201 West 103rd Street Indianapolis, IN 46290 USA

Introduction The Domain Name System (DNS) is the heart of the Internet. Microsoft seized the opportunity to design its new operating systems and directory service to utilize DNS standards. Windows 2000 DNS is significantly improved over Windows NT DNS, and it can interoperate with current third-party implementations of DNS. This book presents an introductory chapter on the basics of the DNS system (which began on UNIX as BIND), then proceeds through the functionality of Active Directory and its reliance on DNS. The middle chapters of this book focus on the implementation and integration of Windows 2000 DNS and Active Directory using the Microsoft Management Console (MMC). Later chapters focus on integration with third-party DNS solutions, troubleshooting, and command-line administration. This book was written with a focus on intermediate administrators new to Windows 2000 DNS, but it is accessible to those new to DNS administration. In writing this book, I tried to focus on integration, because this tends to be the least documented facet of Windows 2000 DNS (and also the most controversial). Based on my industry experience, I tried to write a book that would inform, enlighten, and provide troubleshooting assistance. I hope my efforts meet your expectations. Happy reading, Kevin

CHAPTER

Domain Name System Fundamentals

1

IN THIS CHAPTER • DNS Architecture

4

• DNS Core Physical Components • DNS Specifications and RFCs

14

17

• New Features of Windows 2000 DNS • Summary

22

19

4

This chapter briefly documents the transition of the Domain Name System (DNS) into Windows 2000 and how Windows 2000 DNS differs from legacy and previous Windows versions of DNS. DNS is primarily used for name resolution of computers, or hosts, using the Internet Protocol (IP). In 1969, the Defense Advanced Research Projects Agency (DARPA) developed ARPANET, a small network of computers. The TCP/IP protocol was developed in the early 1970s, was standardized in the early 1980s, and was promptly adopted as the default communication protocol for connectivity between the computers. In 1988, the government dropped the ARPANET program (which was created to allow government contractors to share expensive computing resources), but the networking concepts developed were too popular to abandon. At the time, all computer hosts and their respective IP addresses were contained in a single file called hosts.txt, which resembled a small directory assistance page (as illustrated in the following example): server1 server2 test1 test2 printer1 printer2

10.0.0.1 10.0.0.2 10.0.0.10 10.0.0.11 10.0.0.21 10.0.0.22

Although the hosts file contained only several hundred listings, it was quite unmanageable in terms of frequent updating and distribution. The problems with the text file included: • Heavy server load—From many clients accessing the file • Hostname collision—Because of conflicts with same name in the file • File maintenance and synchronization—Keeping the file updated and synchronized For these reasons, maintaining the file in a central location proved challenging, and the need for a new networking architecture emerged.

DNS Architecture The Domain Name System (DNS) emerged as the replacement to the unmanageable host file developed in the ARPANET days. DNS is basically a hierarchical and distributed database of information for mapping friendly hostnames (for example, www.kevinkocis.com) to IP addresses (192.168.10.200). Because name resolution with a single or flat file proved difficult and unmanageable, DNS needed to be hierarchical and distributed. No single file could suffice, and a layered model was

Domain Name System Fundamentals CHAPTER 1

NOTE You might recognize the Berkeley Internet Name Domain (BIND) as one of the original DNS implementations still widely implemented on the Internet, as well as internally in organizations. For more information on BIND and its history, visit the following Web site: www.isc.org.

DNS Hierarchy The hierarchical structure of DNS consists of a domain namespace that resembles the branches of an upside-down tree. The domain namespace consists of domains, hosts, and services. At the top of the DNS hierarchy is the domain called root. This zone contains root name servers that host information about the top-level domains directly below it. The root servers do not contain information about all the hosts on the Internet. Instead, they point to lower domains to resolve name-to-IP address mappings.

NOTE In DNS, domains are collections of hosts that have IP addresses, not the security boundaries created by Microsoft in Windows NT. DNS domains are considered nodes in the domain namespace.

A convenient way to think about the DNS hierarchy is to consider it like directory assistance. No single telephone directory contains all the telephone information for the entire world. Instead there are directories for each country, province, or state. There are more directories for counties, provinces, metropolitan areas, and cities. No single world entity tracks all the information in a single location. Instead, the responsibility for maintaining the information is delegated to a local or regional resource. These references are published annually or semiannually to maintain data integrity. The important concept here is delegation, or assigning the ownership of the information.

1 DOMAIN NAME SYSTEM FUNDAMENTALS

required. The result was a DNS tree (see the following section, “DNS Hierarchy”). Also, no single entity could manage DNS for every system that required connectivity, so the domain names needed to be distributed and delegated to different entities for load-balancing purposes. Another challenge was that the information needed to be redundant and available to all hosts in all locations looking for each other.

5

6

When directory service is contacted, the local area phone book is consulted for the queried area, and a phone number is returned to the caller. This is very similar to the way DNS functions. In DNS, the hierarchical structure starts with the root zone (think of directory assistance) and is distributed to various subdomains, starting with top-level domains. Figure 1.1 illustrates the simple process of delegation. In a simple query process, a computer attempting to contact the Web server at Sams Publishing would query a root server for www.samspublishing.com. The root server would point to the .com name server because it has no records of the samspublishing namespace. But it does know the .com domain. The .com domain knows of samspublishing.com and directs the client to the Web site. This process occurs rather quickly and is transparent to the user. 2. root server replies “I don’t know, let me forward this to .com.” “.” (root) 3. .com server replies “I don’t know, but I know samspublishing.com. Let me forward this request.” .com

1. client query “who is www.samspublishing.com?” samspublishing.com 4. samspublishing.com server replies “Yes, here is the IP address for www.samspublishing.com so you can contact it directly.”

FIGURE 1.1 A simple representation of the delegation process.

In this example, the root server delegates responsibility of the .com domain to a governing agency. This governing agency knows of the existence of top-level domains (such as microsoft.com or samspublishing.com), but it doesn’t know about any subdomains or hosts within the domain. These domains are administratively delegated to the companies or entities to maintain. The root servers basically redirect query traffic. They have “pointers” that direct queries to the appropriate servers for name resolution. Certain rules that apply to DNS nomenclature are mentioned in the section “DNS Specifications and RFCs” later in the chapter. Adhere to these rules when you send requests for names to DNS domains.


Domain Namespace

1

NOTE The Active Directory namespace is addressed in Chapter 3, “Active Directory and DNS.”

Other namespaces, such as the Hosts namespace from the ARPANET days or the NetBIOS namespace in previous Windows NT versions, cannot be divided and must be distributed in their entirety because they are nonhierarchical, flat text files. For this reason, network administrators struggled with using a hosts or lmhosts file as the number of networked computers and users increased. The Internet DNS namespace looks similar to the inverted tree diagram shown in Figure 1.2. Root domain

“.” (root)

Top-level domains (TLDs)

.com

ibm

edu

samspublishing.com

org

net

gov

whitehouse

FIGURE 1.2 A diagram of the Internet DNS namespace.

Recently, new first-level domains, also called top-level domains (TLDs), have been added to help distribute the load on some of the legacy domains such as .com and .org. The section “Top-Level Domains” later in this chapter addresses these domains in greater detail.

DOMAIN NAME SYSTEM FUNDAMENTALS

A namespace is used by DNS, Active Directory, and host files. The DNS namespace is the hierarchical grouping of domains in which names represent IP addresses, as shown in Figure 1.2. DNS rules allow for the namespace to be divided into subsets of names for distribution and delegation. These subsets are called subdomains, and they are “branches” in the DNS hierarchy. Specific rules determine how names can be created and used within a domain or subdomain.

Second-level domains (SLDs)

7

8

Organizations can also create private networks that are not visible on the Internet, using their own internal domain namespaces. See the section “Second-level Domains” later in this chapter for more discussion on this topic. The DNS domain name is usually a name separated by dots, as shown in the following example: sales.samspublishing.com

The DNS hierarchy of this name is hierarchically represented in Figure 1.3. “.” (root)

.com

ibm

samspublishing.com

sales

FIGURE 1.3 A representation of the DNS namespace hierarchy.

In this context, the root domain (“.”) is implied after .com even though it is not directly seen in the URL. Later chapters will address when the dot is implied and when it must be included in DNS. For convenience, it is implied in most representations. In Figure 1.3, the name path starts with the hostname and ends with the root domain name. Each dot represents a hierarchical level of the DNS namespace. The more dots in the name, the more levels exist. Consider the following example: server1.sales.samspublishing.com

This example is known as a fully qualified domain name, or FQDN. The FQDN is made up of the hostname (in this case a computer called server1 and the host’s primary domain name (in this case, sales.samspublishing.com). Even though the sales domain is a subdomain under samspublishing, which is a subdomain of the .com domain, the primary domain (or domain suffix) is still considered to be sales.sampublishing.com.


9

1

NOTE

Root Domain As mentioned earlier, the root of DNS is symbolized by a dot (“.”). The Internet Assigned Numbers Authority (IANA) manages the root domain. For more information on IANA and other Internet agencies, see the “Governing Agencies” section later in this chapter. The root domain is a group of name servers hosting a database that points to top-level domains such as .com or .org. The root domain branches down into sublevel levels (or subdomains) and is restricted to 127 levels, although it is highly improbable that the Internet or any business would have a need to reach that point. The root domain does not control nor is it responsible for information in the subdomains. Instead, the governing agencies delegate responsibility for subdomains to organizations that connect to the Internet. For example, other governing agencies managed the toplevel domains (such as .com and .gov), and companies registering their name on the Internet are responsible for maintaining their namespace (such as samspublishing.com). Delegation allows for hierarchical responsibility with distributed maintenance. First-Level Domains First-level domains or top-level domains (TLDs) are actually subdomains to the root domain and are also managed by Internet authorities and regulating bodies. These first-level domains typically fall into three categories: • Organizational • Geographical • Reverse Organizational domains are typically for United States organizations, and are usually identified by a three-character code indicative of the primary function or activity of the organization. For example, most for-profit organizations subscribe to the .com domain, whereas government organizations use the .gov domain. The following is a list of the leading first-level domains: •

.com—For-profit

•

.gov—Nonmilitary

•

.org—Nonprofit

•

.net—Network

commercial institutions government institutions

institutions

institutions

DOMAIN NAME SYSTEM FUNDAMENTALS

Fully qualified domain names (FQDNs) are combinations of a hostname concatenated with a domain suffix.

10

•

.edu—Educational

•

.mil—Military

institutions

government institutions

The Internet governing agency, Internet Corporation for Assigned Names and Numbers (ICANN), has recently introduced other new top-level domains. These new extensions are the first new global Internet domains approved by ICANN in over a decade. They include the following: •

.biz—Businesses

•

.info—Unrestricted

•

.name—Individual

•

.pro—Accountants,

•

.aero—Air

•

.coop—Cooperatives

•

.museum—Museums

use

registrations lawyers, and physicians

transport industries

Geographical domains are named by using the two-character country/region codes established by the International Standards Organization (ISO) 3166. These are typically international countries and regions. Examples include the United Kingdom (.uk) and Canada (.ca). Currently over 2000 geographic TLDs exist, and the list continues to grow. See Appendix A, “Resource Record Types” for a detailed list of all geographic domains. The reverse domain is named in-addr.arpa. This domain is unique because it maps IP addresses to hostnames. This process is referred to as reverse lookup. If an administrator had the IP address to a host but not the hostname, he or she would need to resolve the address through a reverse lookup. From the example earlier in the chapter, if you had a phone number but not a person’s name or address, directory assistance would perform a reverse lookup for that information. We take a closer look at name resolution and lookups in Chapter 2, “DNS Server Operations.” A special reverse domain, IP6.INT, is reserved for IP v6 reverse lookups. More information is documented in RFC 1886.

NOTE First-level domains are also called top-level domains or TLDs, even though they are below the root domain. Geographic TLDs suffixed by country codes are referred to as ccTLDs or country code top level domains.


Some examples of second-level domains include: •

microsoft.com

•

samspublishing.com

• netscape.com

NOTE Although a subdomain can be defined as any domain under another, it typically refers to those domains below SLDs.

Second-level domains can be used for public and private IP networks, as discussed in Chapter 4, “Planning and Installing Windows 2000 DNS.” Figure 1.4 is a diagram of the level of Internet and private authority of the DNS namespace. “.” (root)

Internet authority .com

edu

org

net

gov

delegation Private authority ibm

samspublishing.com

FIGURE 1.4 The Internet and private authority for the DNS namespace.

whitehouse


Second-Level Domains Second-level domains (SLDs) sit below the top-level domains. They are composed of two names rather than one, but point back to their respective parent domain, which is the domain located above them in the DNS hierarchy. For example, samspublishing.com is a SLD positioned below the .com top-level domain. Governing agencies of the Internet delegate authority of this domain to Sams Publishing, a company based in Indianapolis, Indiana. Sams Publishing is then responsible for maintaining DNS information regarding hosts in their respective domain, such as computers and network devices that Internet users will eventually contact. (Figure 1.4 clarifies this point.) Sams Publishing must abide by the DNS standards and regulations instituted by the governing bodies of the Internet to use the Internet. These standards are listed in the section “DNS Naming Restrictions.”

11

12

Figure 1.4 shows the authority division for the Internet domain namespace. The delegation line is where the Internet authorities assign or delegate ownership of the DNS information to companies and organizations. The number of names in a FQDN can easily determine DNS domain levels. For example, a TLD has only one name (.com), whereas a SLD has two names (north-rim.com) and subdomains are composed of three or more names (sales.north-rim.com). All subdomains inherit the parent domain name as a suffix to their own name. In the preceding example, the sales domain inherits its parent domain name, north-rim. Nodes, Domains, and Hosts Each node in the DNS tree represents a DNS name. Some examples of DNS names are DNS domains, computers, and services. A DNS domain is a branch under the node. Figure 1.5 shows north-rim.com as a DNS domain with subdomains of eur.com and jpn.com. DNS domains can contain other domains (subdomains) and hosts (computers or services). For example, if North Rim, Inc., established multiple business locations in Europe and Japan, they might want to consider establishing subdomains for these locations. They can be called eur.northrim.com and jpn.north-rim.com, respectively. This is subdividing, and it is an important concept in DNS to enable growth and expansion. Subdividing is typically based on location or departmental divisions. Figure 1.5 illustrates a domain containing subdomains and hosts.

NOTE Subdividing is an important concept in Active Directory integration with DNS as discussed in Chapter 3.

Each organization is assigned authority for a portion of the domain namespace and is responsible for administering, subdividing, and naming the DNS domains and computers within that portion of the namespace. For instance, the European group found in eur.north-rim.com would be responsible for maintaining their portion of the namespace. As mentioned earlier, FQDNs identify each node in the DNS namespace. FQDNs are unambiguous so they can be identified uniquely in relation to the DNS root. The FQDN is the combination of the relative name and the domain suffix. Referring to Figure 1.5, the FQDN for the ftp server node 1.5 is WWW1.north-rim.com. The relative name is WWW1. The domain suffix is north-rim.com.


13


north-rim

WWW1 DNS1

Delegation

eur

WWW1 DNS1

jpn

WWW1 DNS1

FIGURE 1.5 The north-rim domain and expanded subdomains and hosts that connect to the Internet.

NOTE Hostnames must be unique within each specific domain and subdomain. There cannot be two domain controllers called WWW1 in north-rim.com, although a server called WWW1 could also exist in eur.north-rim.com.

FQDNs use naming restrictions allowing only the use of characters A–Z, a–z, 0–9, and the dash or minus sign (-). A period (.) is allowed only between domain names or at the end of the FQDN. FQDNs are not case-sensitive. The Windows 2000 DNS server can be configured to enforce some or all RFC character restrictions or to ignore all character restrictions. For more information, see “DNS Specifications and RFCs” later in this chapter.

14

DNS Core Physical Components Although the concept of DNS is logical in nature, several key physical components make the name resolution process possible. This section focuses on the standard DNS components with references to Windows 2000 DNS.

Name Servers Name servers are the computers running the DNS server services or daemons (such as Windows 2000 DNS or BIND, respectively). Name servers contain DNS database information about the DNS domain tree structure and attempt to perform name resolution when a client computer needs a name resolved. Name servers store DNS information in zone files. DNS servers can host primary and secondary zones; if the name server is hosting a primary zone, it is regarded as the primary server or “start of authority” for that zone. The same applies to the secondary server hosting a secondary zone. Primary zones contain the master copy of the zone information, whereas secondary zones are read-only copies of the zone data. For more information on zones and zone files, see Chapter 2. Name servers are considered authoritative if they host naming information about their local domain. If DNS servers cannot locally provide the requested information (either from the zone file or cache), they can redirect or point to another name server that can help resolve the query, or indicate that the information is not available or does not exist.

NOTE DNS servers can be primary for one zone and secondary for a different zone.

Primary servers require local updates (an administrator entering updates at the primary server console), whereas secondary servers contact the primary (or master) for an update, called a zone transfer. Primary servers are required for each zone, and secondary servers are strongly recommended for fault tolerance as well as alleviating server and traffic loads. Primary servers can manage one or multiple zones, and the same zone can be stored on multiple name servers for fault tolerance as shown in Figure 1.6.

NOTE Windows 2000 DNS offers significant built-in features for security and redundancy when integrated with Active Directory. See Chapter 3 for more information.


Secondary name servers query the master server for updates on a scheduled interval basis.

Zones and Zone Files The difference between domains and zones can be confusing. Zones logically encompass different parts of the DNS structure and determine the domain names that a DNS server manages. Zones are hierarchical areas of the DNS namespace stored in files on name servers. Zone files contain records called resource records with information about local hosts and pointers to other DNS servers. Although zones are attached to specific domain nodes in the DNS namespace, they are not domains. Like name servers, zones can be primary or secondary, and multiple zones can exist within the same domain. See Figure 1.6 for clarification. “.” (root)

com edu

samspublishing.com dell

samspublishing zone

zone sales

samsdns1

tech techdns1 zone

tech zone

FIGURE 1.6 Domain and zone relationships within samspublishing.com.

Figure 1.6 shows the samspublishing.com domain that contains two primary zones: samspublishing and tech. In this example, authority for the tech subdomain has been delegated to the server techdc1.samspublishing.com. The name server in samspublishing.com (samsdc1) hosts the samspublishing.com zone, which includes information for the sales.samspublishing.com subdomain. However, the tech domain maintains its own zone.


Name servers also use load balancing or round robin to distribute network load on the servers. Load balancing is discussed in greater detail in Chapter 2.

15

16

NOTE A DNS zone can span multiple domains. This is a familiar situation with internally managed DNS zones.

Zone files are the database tables that host information about the resources in the respective domains. These resources are documented as resource records. The zone files are located on the DNS servers. In Windows 2000, DNS zones can be stored in different ways. In addition to being stored as zone files, they can also be stored in the Active Directory to provide additional availability and fault tolerance. See Chapter 3 for more information on Active Directory and Windows 2000 DNS.

NOTE In standard DNS, only one name server can manage the primary zone file for each domain. Two name servers cannot be authoritative for the same zone. Windows 2000 Active Directory-integrated zones are the exception; these zones are discussed in Chapter 3.

During name resolution, name servers parse their zones files (which are loaded into memory at startup) to view their resource records (RRs) that contain resource information for the DNS domain.

Resource Records Resource records are groups of information in the zone file used to process and redirect client queries. A name server that is authoritative for the zone contains the resource records required to process queries for that portion of the DNS namespace. Resource records can include information about other name servers in the DNS domain, and define which are authoritative for which zones. These resource records, the SOA and NS resource records, are described in more detail in Chapter 2. The following is an example of a standard resource record hosted by a Web server in the north-rim.com domain: www.north-rim.com.

IN

A

10.10.2.230


Resolvers Resolvers are the client-side programs that use DNS queries to query name servers. Resolvers can communicate with either remote DNS servers or the computer’s local DNS server programs, and are usually built into utility programs of modern TCP/IP implementations. A resolver can run on any computer, including a DNS server.

NOTE Depending on the platform and implementation, resolvers can vary in performance. The Windows 2000 resolver differs from the BIND resolver, although the result is the same.

Windows 2000 DNS has a caching resolver service, which reduces DNS network traffic and allows for quicker name resolution. The caching resolver service provides a local cache for DNS queries. This service will be addressed further in Chapter 5, “Configuring DHCP and DNS Client Configurations,” in the section “Windows 2000 Clients.”

DNS Specifications and RFCs Many specifications and Requests For Comments (RFCs) are associated with DNS. RFCs are documents that are used for the informal process of proposing new technologies to the Internet. RFCs are very technical documents available for anyone to review, but tend to be of particular interest to those implementing the new technologies. RFCs are usually initiated and processed by members of groups listed in the following section, although they can be written by anyone interested in sharing or implementing new standards or practices.

Governing Agencies Internet DNS is governed and regulated by an assortment of agencies. These agencies and their roles are identified as follows: • Internet Corporation for Assigned Names and Numbers (ICANN)—Responsible for technical functions previously performed by IANA. Coordinates domain names and IP addresses and operates the Internet’s root name servers. For more information, review their Web site at www.icann.org.


In this example, the server name is www.north-rim.com. The IN is short for Internet, meaning that the server is part of the Internet; the A indicates that this is an Internet host; and the numbers 10.10.2.230 are the IP address. For more information on resource records and their format, see Chapter 2.

17

18

• Internet Assigned Numbers Authority (IANA)—Manages unique parameters of the Internet such as domain names and IP addresses. For more information, review their Web site at www.iana.org. • Internet Network Information Center (InterNIC)— Assists with management of domain names and IP addresses. For more information, review their Web site at www.internic.org. • Internet Society (ISOC)—Assists with policy comments and steers groups that assist with Internet policies and standards. For more information, review their Web site at www.isoc.org. • Internet Engineering Task Force (IETF)—Develops the Internet’s protocols and standards. For more information, review their Web site at www.ietf.org. • Internet Architecture Board (IAB)—Defines the overall architecture for the Internet, guides the IETF, and serves as advisory group for the ISOC. For more information, review their Web site at www.iab.org. • Internet Engineering Steering Group (IESG)—Manages technical facets of IETF efforts and standardization, including final approval of standards. • Internet Research Task Force (IRTF)—A collection of research groups focusing on all parameters of Internet technology, including architecture and protocols. For more information, review their Web site at www.irtf.org. ISOC serves as the organizational home to the IETF, IAB, IESG, and IRTF. Review their Web site at www.isoc.org for more details on the roles and responsibilities of each group.

NOTE Currently, most of the top-level domains are managed by IANA and InterNIC, but this may change as the number of TLDs increases.

DNS Naming Restrictions Different DNS implementations impose different character and length restrictions for the names used on the Internet. Table 1.1 shows the restrictions for naming a host or domain for each DNS implementation.


TABLE 1.1 Restrictions for Naming a Host or Domain for DNS Implementations DNS in Windows 2000

Characters

Supports RFC 1123, which permits A–Z, a–z, 0–9, and the hyphen (-).

Supports several different configurations as described in Chapter 2

Fully qualified domain name length

63 bytes per label and 255 bytes for an FQDN

63 bytes per label and 255 bytes for an FQDN; Active Directory domain controllers are limited to 155 bytes for an FQDN.

Restriction

NetBIOS Unicode characters, numbers, white space, symbols: ! @ #$%^&‘)(.-_ {}~ 15 bytes

In Windows NT 4.0 and earlier, a computer is identified primarily by a NetBIOS name. The NetBIOS name is restricted to 15 characters, and defines how the computer is known on the network (for example, FILESRV1). A NetBIOS name of WINDOWSFILESERVER1 would be an invalid NetBIOS name due to its character length. Microsoft’s earlier attempt to implement DNS in Windows NT 4.0 proved fairly lackluster and troublesome. With the release of Windows 2000 DNS, Microsoft is migrating from nonstandard proprietary naming schemes to RFC standards. Although WINS is still supported in Windows 2000, the main naming system and location service is DNS, not NetBIOS and browsing.

New Features of Windows 2000 DNS Windows 2000 DNS server has new additions over its predecessor that feature standardization and integration capabilities. Some of these new additions are not standard to the DNS community as a whole, and provide new integration options for Microsoft that are not approved standards.

Active Directory Integration Because DNS is an integral portion of Active Directory implementation, implementing Windows 2000 DNS with Active Directory enhances availability by eliminating single points of failure. Active Directory uses multimaster replication between its domain controllers (where


Standard DNS (i.e., BIND and Windows NT 4.0)

19

20

DNS is typically hosted). This means that all domain controllers can host identical directory information, and updates are replicated to all of them concurrently. Also, all domain controllers contain information about the Active Directory-integrated zones (which are new DNS zones defined by Microsoft). In contrast to the conventional implementation of DNS, featuring primary and secondary transferring database files, Active Directory hosts the data and manages the replication. Some of the advantages of integrating DNS and Active Directory are as follows: • Centralized management of DNS information • Active Directory replication, no additional DNS replication scheduling • Secure replication through use of Active Directory • No single point of failure as in single-master DNS • Simplified administration • Integration with BIND and third-party DNS systems

Secure Dynamic Updates In native Windows 2000 environments, Windows 2000 DNS allows for secure dynamic updates. This process preserves DNS records registered by clients supporting dynamic updates. When a name is created in a DNS database that is protected by secure dynamic update, the system or service that created the record owns that record. This security prevents other systems from deleting or modifying the records with that name. DNS records can be updated by Windows 2000 clients and by a Windows 2000 Dynamic Host Configuration Protocol (DHCP) server that supplies IP addresses for non–Windows 2000 clients.

Record Aging and Scavenging Windows 2000 DNS also prevents the build-up of stale records in the DNS database by tracking aging and releasing unused names. Stale resource records can occur over time with manual scavenging. The presence of stale resource records can impact performance and compromise data integrity. Stale resource records (albeit their small size) can eventually consume memory and disk space and increase load time for the zone data. From an integrity standpoint, a stale resource record could cause a DNS server to erroneously respond to client queries resulting in name resolution problems on the network. Scavenging enables the DNS server to search its database for aged records and delete them. For more information on record scavenging, refer to “Resource Record Scavenging” in Chapter 6, “Administering DNS Servers Using MMC.”


Unicode Character Support

Unicode is an ISO standard (10646) character set that includes all the characters used by the world’s major languages. Unicode is implemented as a double-byte character set and is beneficial to systems that require multilingual text or high-level mathematics. Unicode is required by modern scripting languages and protocols including XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, and WML, and it is supported in many operating systems and browsers. Traditional DNS implementations restricted more characters than Windows NetBIOS nomenclature. The standard DNS characters listed in Table 1.1 are also referenced in RFC 1123 and RFC 952. As a result, Microsoft proposed RFC 2181 to expand the character set to include any text string as an acceptable name for Windows 2000 DNS. This proposal eliminates the complex renaming of machines that are forced to follow the strict name system of traditional DNS.

NOTE The difference in the character sets between DNS and NetBIOS could have proved a significant burden for those enterprises upgrading from NT4 to Windows 2000.

The Clarification to DNS Specification (RFC 2181) broadens the character to accommodate the UTF-8 character encoding (RFC 2044) set, a superset of ASCII, and a translation of the UCS-2 (Unicode) character encoding. The Windows 2000 DNS is designed to support UTF-8 character encoding.

New Administrative Tools Windows 2000 DNS offers new tools to ease administrative tasks with managing DNS. They are as follows: • DNS Console • Windows Management Instrumentation (WMI) Support • DNScmd.exe, a DNS command-line troubleshooting tool Here we touch on these features briefly; later chapters explore them in greater detail.


Unicode character support is most important to Windows implementations because most legacy DNS implementations abide by a strict character set (refer to Table 1.1 for an illustration).

21

22

DNS Console The DNS console is built into Windows 2000 Server products and functions as a Microsoft Management Console (MMC) snap-in. With this console, administrators can manage DNS servers, zones, and security from a GUI. The DNS console offers a new server wizard in addition to enhanced filtering and security options to better manage local DNS zones and information.

WMI Support for DNS Server Administration The Windows Management Instrumentation (WMI) is Microsoft’s execution of Web-Based Enterprise Management (WBEM), an initiative based on standard technologies to manage cross-platform information in enterprise computing environments. WMI simplifies the driver and application architecture of the Windows operating system, provides information consistent with different vendors’ products, and also provides access from non–Windows-based environments to Windows instrumentation. WMI can support monitoring and management of the DNS servers, zones, and records, including updates and other modifications.

DNS Server Troubleshooting Tool (Dnscmd.exe) DNScmd.exe is a command-line tool for local and remote DNS administration. DNScmd is the improved version of Dnsstat.exe, a tool included in previous Windows NT Resource Kits. DNScmd is a tool in the Windows 2000 Server Resource Kit from Microsoft, and can be used to manually modify various DNS properties, including zones and resource records. DNScmd can also force replication events between DNS server physical memory and DNS databases and datafiles. For more information on DNScmd, see Chapter 12, “Remote and CommandLine Utilities for DNS Management.”

Summary DNS is a hierarchical mapping of names to IP addresses that evolved from an inefficient host system implemented by ARPANET. The standard implementation of DNS is Berkeley Internet Name Domain (BIND), which is still predominant in today’s DNS architecture. DNS consists of a root domain that is divided into top-level domains (TLDs) and secondarylevel domains (SLDs) and so on. Subdomains are typically delegated authority or responsibility for maintaining their DNS information (both internally and externally). The physical components of DNS are name servers, zone files (which consist of resource records), and resolvers. DNS is governed by various agencies to design and implement standards and policies for maintaining the Internet space of DNS. Windows 2000 DNS offers some enhancements to legacy DNS, but may face some challenges integrating with legacy implementations of BIND software.

CHAPTER

DNS Server Operations

2

IN THIS CHAPTER • Name Server Roles

24

• Zones and Database Files

30

• The Name Resolution Process

47

• DNS Load Balancing and Caching • Zone Transfers • Summary

54

52

50

24

For DNS and Active Directory to function properly, DNS servers must be available at all times. To ensure availability, you may not want to only rely on AD domain controllers for DNS. You should provide at least a primary and a secondary name server per domain. This way you can load balance between servers and provide quicker access and redundancy. Make sure clients query both a primary and secondary DNS server. You can configure this with DHCP, which is discussed in Chapter 6, “Administering DNS Servers Using MMC.” Because DNS was instituted on UNIX servers running BIND, it is important to understand how the technology and terminology have evolved. This chapter focuses on standard DNS with notes regarding Windows 2000 DNS and Active Directory. Chapter 3, “Active Directory and DNS,” provides a greater focus on Windows 2000 DNS and Active Directory. For now, let’s take a closer look at the various basic DNS server roles.

Name Server Roles Several roles can be assigned to the name server, depending on the infrastructure where it resides. We’ll address location of name servers in Chapter 4, “Planning and Installing Windows 2000 DNS.” The various DNS server roles are: • Primary • Secondary • Master • Forwarder • Slave • Caching-only

Primary Name Server The primary name server is the original source of address data (zone files for zone transfers) for the domain, and it has ultimate authority over names in the domain. It publishes the DNS information to secondary servers, as requested or scheduled, and is also the start of authority (SOA) for the domain. The primary name server holds the master files. The primary zone server hosts the only version of the zone file that is both read and write enabled, and there can be only one primary name server per DNS zone. See Figure 2.1 for an example. In Figure 2.1, note that the name server dc1 in the kevinkocis.com domain is the primary name server for the kevinkocis.com zone.

DNS Server Operations CHAPTER 2

25

2

An example of an SOA record in an Active Directory–integrated zone.

When the primary name server is started, it receives zone data locally or from Active Directory (in the case of Active Directory–integrated zones). The primary server should also have all the records for the domain, and all modifications to zone data must be performed locally to ensure data consistency. If updates are not performed on the primary name server, delegation to subdomains are required to make sure all the records for the domain exist.

Secondary Name Server The secondary name server contains authoritative address data for the domain, which it receives from a master server in the form of a zone transfer (discussed later in the chapter). Zone transfer configuration is covered in Chapter 6, in the section “Zone Transfers.” Secondary name servers relieve the primary name server’s load by answering queries. As mentioned earlier, a secondary name server provides redundancy and load balancing, and is also considered authoritative for the zone.

NOTE You should have at least one secondary name server for each zone to ensure availability in the event of a primary name server failure or outage.

Secondary name servers know where the primary is located because its name is listed in the SOA and NS resource records (addressed later in this chapter). The big difference between

DNS SERVER OPERATIONS

FIGURE 2.1

26

primary and secondary name servers is that the primary name servers host the read/write copies of the zone information files, whereas the secondary servers host only read copies of the files. Although both server types are authoritative, the secondary must obtain its information from primary or master name servers through zone transfers. Secondary name servers provide a backup, support local queries, and assist with load balancing.

NOTE Secondary servers are referred to as slaves in BIND version 8. BIND is the common DNS product used with UNIX servers.

Secondary name servers provide the following benefits: • Fault tolerance • WAN traffic reduction • Query load reduction Secondary name servers provide both redundancy and a distributed workload. Should the primary name server experience an outage or failure, secondary servers (also referred to as secondaries) can continue to handle client queries and resolutions. With multiple servers handling queries, the result will be improved response time for query resolutions. Client resolvers log the name servers and which provided fastest resolution.

NOTE Zone data is not maintained on the secondary server because a read-only copy is transferred from the master name server. There is no local modification of resource records on a secondary name server.

A secondary name server for the zone can be set up in a remote location to reduce WAN traffic over slow links. If the remote site has a significant number of hosts, the secondary name server can be the first source for local name resolution. This process prevents clients from issuing DNS queries over slow WAN links. Finally, the secondary server can answer queries for the zone, reducing primary server queries for the zone.


27

TIP It is a good strategy to locate secondary name servers on physically different subnets or networks, or in different sites.

Master Name Server Master name servers are those servers that provide copies of the zone data files to secondary name servers. Master name servers can be either primary or secondary name servers, because their primary role is to respond to update transfers from secondary servers.

2

In smaller networks, primary name servers usually perform the role of the master name server. In larger networks, secondary name servers may act as masters to other secondaries to alleviate network traffic and maintain zone data integrity.


Forwarders and Slaves When a DNS server receives a query, it attempts to locate the requested information in its cache as well as its local zones. If it cannot locate the requested information and is not authoritative for the requested information, it may communicate with other servers to resolve the request. Although forwarders are not mandatory for DNS functionality, some network administrators might not want the server to communicate directly with other servers (such as Internet DNS servers over a slow WAN link). Forwarders are DNS servers designed to provide forwarding of off-site queries for other DNS servers. For example, one DNS server could be configured as a forwarder for Internet computer names, and then configure your other servers to use that forwarder to resolve names for which they are not authoritative.

NOTE The most common use of forwarders is bridging a firewall to the Internet. Because of security issues such as exposing internal network and host information, forwarders can be configured to reply to queries outside an organization’s domain.

DNS forwarding servers do not require any special configuration except forwarding DNS IP addresses. If the forwarder does not respond with the information, the DNS server then queries the root name servers, and follows the iterative query process (mentioned later in this chapter).

28

Figure 2.2 illustrates the forwarding process as outlined in these steps: 1. The DNS client (resolver) issues a query to the local DNS server. 2. The local DNS server forwards the request to another DNS server (forwarder) and awaits the response. 3. The forwarder tries to resolve the query. If it fails, it queries the Internet name servers, and awaits the response. 4. If the forwarder cannot get a reply, the local DNS server attempts to resolve the query itself by querying the Internet name servers.

Internet

4

1

Client

3

2

DNS server

Forwarder

FIGURE 2.2 The forwarding process.

There are two modes of forwarding: nonexclusive and exclusive. In nonexclusive mode, a forwarder is basically a designated machine for handling queries. It will wait for a response, and if it doesn’t receive one, it will search for an answer itself. In exclusive mode, the forwarding servers are called slaves because they rely entirely on the forwarder servers to provide query results. A slave performs similarly to the forwarder except it does not attempt to resolve the address itself. When a slave receives a DNS query that it cannot resolve through its own cache or local zones, it passes the query to a designated forwarder. The forwarder then attempts to resolve the query and returns the results to the slave. The slave, in turn, provides the results to the original requester. If the forwarder cannot resolve the request, the slave returns a query failure to the original resolver. The slave name server does not attempt to resolve the query directly if the forwarder cannot satisfy the request.


29

Figure 2.3 illustrates the forwarding process as follows: 1. The DNS client (resolver) issues a query to the local DNS server. 2. The local DNS server (slave) forwards the request to another DNS server (forwarder) and awaits the response. 3. The forwarder tries to resolve the query. If it fails, it queries the Internet name servers, and awaits the response. 4. If the forwarder cannot get a reply, it responds with an error, and the slave will not attempt a query itself.

3

1

Client

2

Slave DNS server

Forwarder

FIGURE 2.3 The forwarding process in exclusive mode (slave role).

Caching Only All DNS servers perform caching when they receive information from other servers, and store the information for a certain amount of time. This enhances DNS resolution and reduces traffic associated with DNS queries. Caching-only servers simply perform queries and cache the answers. They are not authoritative for any DNS domains and do not host any zones. They only store data that they have cached while resolving queries. The only requirement for caching-only servers is that they host a valid root cache file that includes the local name server in addition to the Internet root servers. The benefit provided by caching-only servers is that they do not generate zone transfer network traffic because they do not contain any zones. They also cache many query responses.


Internet

2

30

The caching-only server does have some drawbacks. One disadvantage is that when the server is initially started, it has no cached information and must build up this information over time as it services requests. Another disadvantage is that the caching-only server may not have recent information. To remedy this, you can adjust the time-to-live (TTL) feature on cached information.

NOTE To ensure that the caching-only name server has recent information, set the TTL to a low time value.

However, implementing a caching-only server can improve performance, providing quick responses to queries without incurring administrative problems of primary or secondary name servers. Caching-only servers are ideal for companies with an ISP providing primary DNS services.

Zones and Database Files A zone is a contiguous portion of the DNS namespace that contains resource records stored on a DNS server. Zones are hosted at a particular domain node in the DNS hierarchy, but are not domains. Domains can be partitioned into various zones to allow other DNS servers to manage name resolution. A DNS domain is a branch of the namespace. A zone is a segment of the DNS namespace that is typically stored in a file. The zone enables the DNS server to respond to queries about local hosts (within its zone). In the example shown in Figure 2.4, the samspublishing.com domain contains subdomains called books and software. These subdomains are configured as separate zones (with different zone files) to help manage the name resolution. These files can be stored on the same or different DNS servers, because a DNS server can host multiple zone files. Zone information can be stored in different ways. For example, resource records can be stored in separate, physical zone files. On Windows 2000 servers, zones can also be stored in the Active Directory database. Some secondary servers store zones in memory and perform a zone transfer whenever they are restarted.

NOTE Two different name servers cannot be configured to manage the same primary zones, although zones can contain multiple domains.


31

“.” (root)

com

domain

samspublishing books

software

zone

FIGURE 2.4 The DNS namespace in relation to zones.

Name servers can host a combination of primary and secondary zones (see the following), depending on practicality. Microsoft defines the primary zone as the read/write copy of the zone data file. Secondary zones are those replicas that are read-only. This means that a name server might host the primary copy of one zone and the secondary copy of another zone, or it might host only the primary or only the secondary copy for a zone. The name server hosting the primary zones is considered the primary server for that zone, and the name server hosting the secondary zones is considered the secondary server for that zone. Zone files consist of resource records, and fortunately for Microsoft, DNS standards do not specify the internal data structure that stores resource records. As a result, BIND and Windows 2000 DNS vary in terms of their implementations. On both platforms, name servers can store zones in plain text format, but it is not required. However, Windows 2000 DNS allows for integration of the DNS database with the Active Directory database. As a result, the zone information is stored in the Active Directory database and follows the replication and security architecture of Active Directory. See Chapter 3 for more information on Active Directory architecture and DNS integration.

NOTE Active Directory is not required to implement Windows 2000 DNS. However, Windows 2000 DNS is recommended (but not required) if Active Directory will be implemented in your enterprise. This may cause interoperability concerns as documented in Chapter 9, “BIND and Windows 2000 Interoperability.”


samspublishing.com domain

2

32

Primary Zones Primary zones are, as the name implies, the primary location for zone data. They are locally updated and are replicated to secondary servers as necessary (per schedule or modification). All changes to the zone data must be made on the primary DNS server for that zone. Such changes can include delegating or resource record modification.

Secondary Zones Secondary zones serve as a backup for zone data. These zones are replicated from another server (either primary or secondary), which is often referred to as a master server for the zone. Secondary zones are configured with the master server’s IP address for replication purposes.

Active Directory–Integrated Zones As mentioned in Chapter 1, “Domain Name System Fundamentals,” one unique feature in the Windows 2000 DNS service is the capability to store DNS zones within the Windows 2000 Active Directory database. An Active Directory–integrated zone is a primary DNS zone stored in AD and replicated to other domain controllers and possibly secondary name servers. Active Directory–integrated zones are Microsoft proprietary, and use AD replication (as opposed to traditional zone transfer). Both processes are explained later in this chapter. A considerable advantage of AD-integrated zones is the capability to use AD’s multimaster replication, which increases DNS fault tolerance. This process also allows for greater efficiency of replication across slow links because AD typically compresses replication data between sites. Active Directory–integrated zones contain forward and reverse lookup zones as well.

Forward and Reverse Lookup Zones Forward lookup zones contain information needed to resolve names within the DNS domain. Forward lookup zones provide the necessary information for most client queries where the client supplies a DNS name and requests the corresponding IP address. Queries of this type are often referred to as forward lookups. Figure 2.5 shows the contents of a forward lookup zone stored in Active Directory, including resource records listed under the name column. The resolver provides the IP address listed in the data column when the name is queried.

NOTE Forward lookup zones require SOA and NS records, but can include other resource records except for PTR records, which are reserved for reverse lookup zones.


33

2 DNS SERVER OPERATIONS

FIGURE 2.5 A forward lookup zone integrated with Active Directory.

Reverse lookups are used if a client has a host’s IP address and requires its DNS name. Reverse lookup zones contain information needed to perform reverse lookups, such as SOA, NS, PTR, and CNAME resource records (for more information on resource records and their functionality, see the following section, “Resource Records”). Figure 2.5 shows the contents of a reverse lookup zone. The PTR is a required resource record for reverse mappings of IP addresses to their corresponding FQDNs. Because reverse lookups through all DNS domains would be far too exhaustive and inefficient (because each host file would need to be searched), a special DNS domain called in-addr.arpa was created to mirror the forward lookup process. Figure 2.6 shows the hierarchy of this namespace. This domain uses a reverse ordering of the numbered octets of the IP addresses. For example, if a client needs to identify the FQDN associated with the IP address 192.168.10.10, the client queries for the PTR record of the 10.10.168.192.in-addr.arpa domain name. Similar to DNS secondary-level domain (SLD) delegation, branches of the in-addr.arpa domain can be delegated to organizations corresponding to their class A, B, or C IP network IDs. Figure 2.7 shows the reverse lookup zone with its associated PTR records. In reverse lookup zones, the IP address is listed under the name column and the hostname appears under the data column in the details pane (opposite of the forward lookup zone).

34

FIGURE 2.6 A reverse lookup zone integrated with Active Directory.

FIGURE 2.7 The in-addr.arpa namespace stored in Active Directory.


35

Resource Records Resource records are collections of information in the DNS database used to process client queries. Each DNS server should contain the resource records required to answer queries for the portion of the DNS namespace for which it is authoritative.

NOTE A DNS server is authoritative for a contiguous portion of the DNS namespace if it contains information about that portion of the namespace.

Resource records use the following syntax: Owner

TTL

Class

Type

RDATA

Table 2.1 describes each of the resource record fields. TABLE 2.1 Resource Record Fields Name

Description

Owner

Host or DNS name to which this resource record belongs. The length of time that a record is allowed to remain in memory on a resolver (client or DNS server) is allowed to exist cache before being discarded. This field is optional, and if it is not specified, defaults to the Minimum TTL in the SOA record. TTL is a 32-bit integer represented in seconds. Defines the protocol family, which is predominantly represented by “IN” for the Internet system. The other value defined in RFC 1034 is “CH” for the Chaos system (an experimental implementation at MIT). Identifies the type of resource record. A variable type that identifies the resource record data.

Time to Live (TTL)

Class

Type RDATA


Resource records are represented in binary form in packets when lookups and responses are made using DNS. However, resource records are represented as text entries in the database files. Most resource records are represented as single-line text entries. In many implementations of DNS, only the Start of Authority (SOA) record can be multiple lines. For readability, blank lines and comments are often inserted in the zone files (and ignored by the DNS server). Comments always start with a semicolon (;) and end with a carriage return.

2

36

Different types of resource records can be used to provide DNS-based data about computers on a TCP/IP network. This section describes the following resource records: • SOA • NS • A • PTR • CNAME • MX • SRV (New in Windows 2000) The first three areas or fields in several resource records are the standard owner, class, and type fields. Let’s take a closer look at the popular resource records.

SOA Resource Records Every zone contains a Start of Authority (SOA) resource record at the beginning of the zone. SOA resource records contain general information on the zone, including the authoritative DNS server for the zone, and various update and expiration parameters. The following is an example of an SOA resource record: @

IN

SOA

dns1.north-rim.com. admin.north-rim.com. ( 205936 ; serial number 3600 ; refresh [1h] 600 ; retry [10m] 86400 ; expire [1d] 3600 ) ; min TTL [1h]

SOA resource records include the following fields: • The authoritative server area displays the primary DNS server authoritative for the zone. In the example, the authoritative server is dns1.north-rim.com. • The responsible person area displays the e-mail address of the administrator responsible for the zone. The typical at symbol (@) is replaced by a period. In the example, the responsible person is [email protected] (displayed as admin.north-rim.com). • The serial number field reveals the number of times the zone has been updated. Because zone transfers are determined by the serial number value (when a secondary compares with a primary), if the primary or master’s serial number is greater, the secondary name server initiates a zone transfer. • The refresh field area displays the timeline for how often the secondary server verifies whether the zone has been changed. This value is recorded and displayed in seconds. In the example, 3600 seconds=1 hour, so the secondary verifies with the primary every hour.


37

• The retry field area displays the interval for how long a secondary server for the zone waits for a response from the master server after submitting a zone transfer request. After this interval expires, the secondary attempts to resend the request. This value is recorded and displayed in seconds. In the example, 600 seconds=10 minutes, so the secondary retires every ten minutes. • The expire field area displays how long since the previous zone transfer the secondary server continues to respond to client queries before regarding its zone information as invalid. This value is recorded and displayed in seconds. In the example, 86400 seconds=1 day, so the secondary will regard this file as being invalid after one day.

NOTE FQDNs must contain the ending period signifying that they are under the root (“.”) domain. For example, the SOA entry of dns1.north-rim.com would result in an error.

NS Resource Records The name server (NS) resource record indicates which servers are authoritative for the zone. NS resource records indicate primary and secondary servers for the zone that is specified in the SOA resource record. NS records also indicate the servers for any delegated zones.

NOTE Every zone must contain at least one NS record at the zone root.

In the following example, when an administrator for kevinkocis.com delegated authority for the na.kevinkocis.com subdomain to nadc1.na.kevinkocis.com, the following line was added to the kevin.com and na.kevinkocis.com zones: na.kevinkocis.com.

IN

NS

nadc1.na.kevinkocis.com.

A Resource Records The address (A) resource record maps an FQDN to an IP address, so the resolvers can request the corresponding IP address for an FQDN. These records are used for forward lookups when you want to discover the IP address for a given FQDN.


• The minimum TTL area is the default time to live for all resource records in the zone (unless another value is specified in the individual record). This value is recorded and displayed in seconds. In the example, 3600 seconds=1 hour, so the secondary verifies with the primary every hour.

38

For example, the following A resource record, located in the na.kevinkocis.com, maps the FQDN of the server to its IP address: nadc1

IN

A

192.168.10.10

PTR Resource Records The pointer (PTR) resource record, in contrast to the A resource record, maps an IP address to a FQDN. PTR records are used for reverse lookups, when you want to discover the FQDN for a given IP address. PTR records use the reverse lookup domain for resolution. For example, the following PTR resource record maps the IP address of nadc1.na.kevinkoto its FQDN (see Figure 2.8 for the hierarchical mapping of this PTR record):

cis.com

10.10.168.192.in-addr.arpa.

IN

PTR

nadc1.na.kevinkocis.com. “.” (root)

.arpa

.com

.in-addr 0

255

.192

255

0

.168

0

255 .10 255 .10

Each level of the in-addr.arpa domain ranges from 0 to 255 mirroring the IP address range

FIGURE 2.8 The hierarchical representation of the domain controller nadc1 in the in-addr.arpa namespace.

CNAME Resource Records The canonical name (CNAME) resource record creates an alias for a particular FQDN. CNAME records can protect the details of your hosts and network from connecting clients. CNAME records are common in the Web and FTP arenas. In these scenarios, it is suggested that CNAMEs be created for the servers that are sharing information to the public. For example, for an FTP server named ftp1.na.kevinkocis.com in my na.kevinkocis.com domain, use a CNAME to point to this server without revealing its FQDN. If the FTP server is


39

migrated or changes address, this change is transparent to users. Only the server name needs to be changed in the CNAME resource record. For example, the following CNAME resource record creates an alias for ftp1.na.kevinkocis.com: ftp.na.kevinkocis.com.

IN

CNAME

ftp1.na.kevinkocis.com.

In this example, if the server changed to ftp2.na.kevinkocis.com, only the end area or field needs to be altered. The change is transparent to users.

NOTE There can be only one canonical name per alias, in accordance with RFC 2181.

MX Resource Records The mail exchange (MX) resource record specifies a mail exchange server for a DNS domain name. A mail exchange server is a host that will either process or forward mail for the DNS domain name. Processing the mail means either delivering it to the addressee or passing it to a different type of mail transport. Forwarding the mail means sending it to its final destination server, sending it using Simple Mail Transfer Protocol (SMTP) to another mail exchange server that is closer to the final destination, or queuing it for a specified amount of time.

NOTE Only mail exchange servers use MX records.

If your enterprise has multiple mail exchange servers residing in a single DNS domain, you can enter multiple MX resource records for that domain, with different weight preferences assigned to each. When mail is sent to a domain, a DNS server for that domain is contacted and retrieves all the MX records. It then contacts the mail server with the lowest preference value. The following example shows MX resource records for the mail servers for the north-rim.com domain: * north-rim.com. * north-rim.com.

IN IN

MX MX

0 10

mailsrv1.north-rim.com. mailsrv2.north-rim.com.


When a client resolver queries for the A resource record for a server, the DNS server locates the CNAME resource record, resolves the query for the server’s A resource record, and returns both the A and CNAME resource records to the client.

40

As mentioned earlier, the first three fields in this resource record are the standard owner, class, and type fields. The fourth field is the mail server priority. This preference value is weighted among the MX records listed on the name server. The lower the priority, the greater the preference, so in the preceding example, mailsrv1 has priority for mail sent to the zone. When mail is sent to a domain, the DNS server for that domain is contacted. The name server then parses all the MX records and contacts the mailer with the lowest preference value.

NOTE MX resource records do not configure mail servers for the domain; they merely direct mail to the mail server.

SRV Resource Records Service (SRV) resource records are new to Microsoft Windows 2000 DNS. SRV records allow for specification of the location of the servers for a specific service, protocol, and DNS domain. The format of an SRV record is as follows: _Service._Proto.Name ➥ Target

TTL

Class

SRV

Priority

Weight

Port

• The Service field indicates the service name, such as http or telnet. • The Proto field indicates the protocol, such as TCP or UDP. • The Name field indicates the domain name referred to by the resource record. • The TTL and Class fields are the same as the fields defined earlier. • The Priority field is the same as the MX records, where the lower value receives precedence. • The Weight field allows for load balancing in the event that two or more records in the same domain have the same value in the priority field; clients should try records with higher weights more often. In some cases, a client may support another load-balancing method. • The Port field indicates the port of the service on this host. • The Target field indicates the FQDN for the host supporting the service. The following example shows SRV records for Web servers: _http._tcp.kevinkocis.com. IN _http._tcp.kevinkocis.com. IN

SRV SRV

0 10

0 0

80 80

web1.kevinkocis.com. web2.kevinkocis.com.


41

Note that neither SRV records specify a TTL, because this variable is inherited from the SOA resource record. To locate a Web server in the kevinkocis.com DNS domain, the client resolver sends the following query: _http._tcp.www.kevinkocis.com.

The DNS server then replies with the SRV records listed in the example. The resolver selects between the two records by reviewing their priority values. The client would select web1 over web2 because it has a lower priority value.

NOTE Even though identical priority resource records would result in a random selection, the weight value influences the outcome by giving higher priority to the record with the higher weight.

In the preceding example, the A record for web1.kevinkocis.com would then be sent from the DNS server to the client, and the client would attempt to contact the server directly.

Uncommon Resource Records The previous sections addressed and illustrated the most common resource records used in Windows 2000 DNS. Table 2.2 shows some other resource records and the RFCs that define them. Most of these records are considered experimental and are used mostly in limited or private capacities. TABLE 2.2 Uncommon Resource Record Types Record Type

RFC

Description

AAAA AFSD

1886 1183

HINFO

1035

Hostname mapping to an IPv6 address. Gives the location of either an Andrew File System (AFS) cell database server or a Distributed Computing Environment (DCE) cell’s authenticated server. Maps DNS name to server. The host information resource record classifies a host’s hardware type and operating system based on those values listed in RFC 1700.


If both records had the same priority value, the client would have selected the Web server randomly.

42

TABLE 2.2 Continued Record Type

RFC

Description

ISDN

1183

MB

1035

MG

1035

MINFO

1035

MR

1035

RP

1183

RT

1183

TXT

1035

WKS

1035

X.25

1183

The Integrated Services Digital Network (ISDN) resource record is a variation of the A (address) resource record where the FQDN is mapped to an ISDN address. This record is combined with the route through (RT) resource record for utilization. The mailbox (MB) resource record is an experimental record that identifies a DNS host with the specified mailbox. This record is used in conjunction with the mail group (MG) resource record, the mailbox rename (MR) resource record, and the mailbox information (MINFO) resource record. The mail group (MG) resource record is an experimental record that identifies a mailbox that is a member of the mail group specified by the domain name. The MINFO resource record is an experimental record that identifies a mailbox that is responsible for the specified mailing list. The MR resource record is an experimental record that identifies a mailbox that is the proper rename of another specified mailbox. Identifies the responsible person (RP) for the specified host or domain. The route through (RT) resource record identifies a “middleman” host that routes packets to a destination host. The RT record is used with the ISDN and X25 resource records. The RT syntax and functionality is similar to the MX record type. The text resource (TXT) record links text information with an object in the DNS database. A TXT record can contain multiple strings, up to 64 kilobytes (KB). The well-known service (WKS) resource record describes the services provided by a specific protocol on a specific interface. The protocol is usually UDP or TCP. The X.25 resource record is a variation of the A (address) resource record. Rather than mapping a FQDN to an IP address, the X.25 record maps the name to an X.121 address, which is the International Standards Organization (ISO) standard that specifies the format of addresses used in X.25 networks.


43

Non-RFC Resource Record Types In addition to the resource record types listed in the RFCs, Windows 2000 uses the several resource record types that are not specified in any of the existing RFCs (nor will they likely ever be). These records are shown in Table 2.3. TABLE 2.3 Non-RFC Resource Record Types Description

WINS

Used to locate a host using WINS when the DNS name does not exist in the DNS zone authoritative for the name. Used to locate a host using WINS when the DNS lookup name does not exist in the DNS zone authoritative for the name, and the client knows the IP address. This record is used only in the reverse lookup zone. The ATMA resource record maps DNS domain names to ATM addresses. This resource record was defined by the ATM Forum.

WINS reverse (WINS-R) ATMA

Resource Record Structure The IP structure and format of a resource record is somewhat technical. In previous sections of this chapter, the name, type, class, and TTL have been addressed. The IP structure also requires areas for data (such as queries and resolution information). Figure 2.9 shows the field format of a resource record.

Name - (length varies) Type - 16 bits Class - 16 bits TTL - 32 bits Data length - 16 bits Data - (length varies)

FIGURE 2.9 The field format of a resource record.


Name

44

DNS domain names are expressed by labels. For example, the kevinkocis.com domain name is represented by two labels (kevinkocis and com) formatted using a length-value format. Each label is formatted with a 1-byte-length field preceding the label name. The domain kevinkocis.com is represented by 0x10kevinkocis0x03com0x00. The hex digits represent the length of each label while ASCII characters represent the individual labels. The last hex zero represents the end of the name.

Naming Standards Your naming convention should follow the Internet standard character set permitted for use in DNS host naming. Refer to Table 1.1 for details on the RFC 1123 standards. If you implemented NetBIOS with more unconventional names, existing computer names might not conform to the DNS naming standard. If this is the case, consider revising the computer names to DNS-compliant names as specified in the DNS RFCs. To ease the transition from NetBIOS names to DNS domain names, the Windows 2000 DNS service includes support for extended ASCII and Unicode characters.

NOTE ASCII and Unicode character support can only be used in a pure Windows 2000 DNS network environment. This is because most other DNS client software is based on RFC 1123, the specification that standardizes Internet host-naming requirements.

If a nonstandard DNS domain name is entered during Windows 2000 setup, a warning message appears recommending that a standard DNS name be used instead. All Microsoft operating systems before Windows 2000 relied on NetBIOS names for network identification. Hostnames were available (but not required) on most of the pre–Windows 2000 operating systems, and they were set to be the same as the NetBIOS name by default. In Windows 2000, a computer can be identified by its NetBIOS computer name (which is optional and used for pre–Windows 2000 interoperability), and the fully qualified domain name (FQDN) for the computer and is its primary (or default) name. Also, a computer might be identified by the FQDN composed of the computer (or host) name and a connection-specific domain name, where one is configured and applied for a specific network connection on the computer.


45

The full computer name is a combination of both the computer name (hostname) and the DNS domain name for the computer (such as host1.kevinkocis.com). The DNS domain name for the computer is part of the system properties for the computer and is not related to any specifically installed networking components. However, computers running Windows 2000 that do not use either networking or TCP/IP do not have a DNS domain name. To ensure interoperability between NetBIOS and DNS naming in Windows 2000, a new naming parameter called the NetBIOS computer name was introduced. The value of this parameter, which is not required in a pure Windows 2000 environment, is derived from the first 15 octets of the DNS full computer name.

NOTE Although you can create long, complex DNS names, it is recommended that you create shorter, user-friendly names.

Adherence to RFC 1123 can present a problem on Windows 2000 networks that still use NetBIOS names. NetBIOS names can use additional characters, and it can be time-consuming to convert all the NetBIOS names to standard DNS names. To simplify the migration process to Windows 2000 from Windows NT 4.0, Windows 2000 supports a wider set of characters that goes beyond the scope of the 128 ASCII character set. RFC 2181, “Clarifications to the DNS Specification,” defines larger character sets that are allowed in DNS names. It states that a DNS label can be any binary string, and it does not necessarily need to be interpreted as ASCII. Based on this definition, Microsoft has proposed that the DNS name specification be readjusted to accommodate a larger character set: UTF-character encoding, as described in RFC 2044. UTF-character encoding is a superset of ASCII and a translation of the UCS-(also known as Unicode) character encoding. The UTF-character set includes characters from most of the world’s written languages (such as the different types of O’s (ÔÕØÒÓ). The Windows 2000 DNS service includes support for UTF-character encoding.


When the full computer name is a combination of the computer name and the DNS domain name for the computer, the impact of renaming and making the transition from a NetBIOS namespace to a DNS namespace can be minimal. Users continue to focus on the short computer name. If this name is 15 characters or less, you can keep the name identical to the NetBIOS computer name. You can then also assign a DNS domain name for each computer. This can be done using remote administration tools.

2

46

You can configure the Windows 2000 DNS server to allow or disallow the use of UTF-characters on your Windows 2000 server. You can do so on a per-server basis from within the DNS console. From the Advanced tab of the server properties page, set Name checking to one of the following: • Strict RFC (ANSI)—Allows “A” to “Z,” “a” to “z,” the hyphen (-), the asterisk (*) as a first label; and the underscore (_) as the first character in a label. • Non RFC (ANSI)—Allows all characters allowed when you select Strict RFC (ANSI), and allows the underscore (_) anywhere in a name. • Multibyte (UTF-)—Allows all characters allowed when you select Non RFC (ANSI), and allows UTF-8 characters. • Any character—Allows any character, including UTF-8 characters. If you enter a DNS name that includes UTF-8 or underscore characters that are not listed in RFC 1123 when you are modifying a hostname or DNS suffix or creating an Active Directory domain, a warning message appears explaining that some DNS server implementations might not support these characters.

Resolver Roles As mentioned in Chapter 1, DNS clients use libraries called resolvers that perform DNS queries to servers on behalf of the client. For clarification sake, a DNS server can also act as a client to another server. The Windows 2000 TCP/IP stack is typically configured with the IP address of at least one DNS server to which the resolver queries for DNS information. In Windows 2000, the DNS Client service contains the resolver portion. This service is installed automatically with TCP/IP, and runs as part of the services.exe process. The DNS Client service will log on using the Windows 2000 System account. The Windows 2000 resolver performs the following tasks: • Name resolution • General caching of queries • Negative caching • Tracking Plug-and-Play network adapters and their IP configurations • Tracking connection-specific domain names


47

• Queries for cessation (for a period of time) when a name server fails to respond to a query • Prioritizes A resource record resolutions from a DNS server based on IP addresses

The Name Resolution Process Windows 2000 prefers the Domain Name System (DNS) as its main name resolution. DNS is an integral part of Active Directory and must be installed on your network. Active Directory clients use DNS servers to locate Active Directory domain controllers. DNS clients can make two types of queries: recursive and iterative.

A recursive name query is a fairly absolute process. In a recursive query, the client resolver requires the name server to respond with either the requested resource record or an error message indicating the record or domain name does not exist.

NOTE In a recursive query, the name server cannot refer the client to a different name server. It will query other servers until it obtains the information or responds with a name query failure.

The recursive query process is illustrated in conjunction with the iterative query process in Figure 2.10.

Iterative Queries In an iterative name query, the client lets the DNS server return the best answer based on cache or zone data. If the resolution is not in its cache or zone data, the name server offers a referral to the root level of the DNS hierarchy. The client follows the referral, and the process continues downward until the client locates a DNS server that is authoritative for the queried name, or the query errors out. This process is illustrated in the iterative portion of Figure 2.10. This process is sometimes referred to as “walking the tree,” because it starts at the top of the domain “tree” and works its way down. This is the default resolution process for the Windows 2000 resolver.


Recursive Queries

2

48

Iterative Queries 2 3

4 5

kevinkocis.com DNS server Recursive Query

1

6 7

“.” root name server

“.com” name server

“north-rim.com” name server

8

host1.kevinkocis.com Resolver

FIGURE 2.10 The recursive and iterative query process.

If none of the servers have the requested information in their caches, the following processes occurs for a client (host1.kevinkocis.com) attempting to obtain the IP address for ftp.north-rim.com: 1.

contacts dns1.kevinkocis.com with a recursive query for ftp.north-rim.com. must provide either the answer or an error message.

Host1 dns1

2. Because dns1 does not have the answer in its cache or zones, it contacts a root server authoritative for the Internet with an iterative query for ftp.north-rim.com. 3. The root server does not know the answer, so it offers a referral to an authoritative name server in the .com domain. 4.

dns1

contacts the .com authoritative name server with an iterative query for

ftp.north-rim.com.

5. The .com authoritative name server does not know the answer, so it offers a referral to an authoritative name server in the north-rim.com domain. 6.

contacts the north-rim.com authoritative name server with an iterative query for ftp.north-rim.com. dns1


49

7. Because the north-rim.com name server knows the answer to the query, it replies to dns1 with the proper IP address. 8.

dns1

then replies to the client query with the IP address for ftp.north-rim.com.

Inverse Queries In addition to reverse lookups, some legacy DNS servers support a process known as an inverse query. Just as with a reverse lookup, a client making an inverse query provides the IP address and requests the FQDN.

Because support for inverse queries is optional and because servers often cannot provide a definitive answer, inverse queries are of limited use. There is no direct searchable way of performing a reverse lookup, and the in-addr.arpa domain was created for this purpose. The in-addr.arpa domain contains nodes named after reversed IP addresses. RFC 1035 offers more information about inverse queries.

NOTE Windows 2000 DNS servers respond to inverse queries with the queried IP address enclosed in brackets. For example, if it receives an inverse query for 192.168.10.15, it replies with [192.168.10.15], not 15.10.168.192 as the in-addr.arpa.com reverse lookup. This is essentially a “fake” response, because it is not the typical response to an inverse query.

Delegation and Glue Records To delegate a subdomain into a separate zone, delegation and glue records must be added to the local (parent) zone. A delegation is a NS record in the parent zone listing the authoritative name server for the delegated zone, and is required for name resolution. A glue record is an A record for the same server, and is required because it is a member of the delegated domain.


Inverse queries are intended to map an IP address to a hostname using a nonstandard DNS query operation (similar to a reverse lookup). The use of inverse queries is limited to some of the earlier versions of NSLOOKUP.EXE, a utility used to test and troubleshoot a DNS service. The Windows 2000 DNS server recognizes and accepts inverse query messages and answers them with a “fake” inverse query response (see the following note for more on “fake” inverse query responses).

50

In the following example, the name server (NS) for the kevinkocis.com domain is dns1, which has been delegated authority for the kevinkocis.com zone. kevinkocis.com. IN dns1.kevinkocis.com.

NS IN

A

dns1.kevinkocis.com. 192.168.10.15

Root Hints The root hints file (which is also known as the cache hints file) contains host information for names outside of the authoritative DNS domains. It contains the names and IP addresses of the 13 root DNS servers. If your company connects to the Internet, the root hints file should contain records for the root DNS servers on the Internet. In Windows 2000, the root hints file is installed as the file Cache.dns in the directory %SystemRoot%\System32\Dns. If your company does not connect to the Internet, all the NS and A records in the cache file must be replaced with NS and A records for the authoritative DNS servers at the root of your private network.

NOTE The Windows 2000 Configure DNS Server Wizard will create a cache file based on a best effort to determine whether your network is connected to the Internet.

DNS Load Balancing and Caching If a server experiences load issues because of heavy network activity, additional servers can be configured in the same zone to provide load balancing. After installing additional servers in the zone, they can be configured to balance the network load for the zone. This is called load balancing or “round robin.”

Load Balancing (Round Robin) Name servers can be configured to provide round robin, or load balancing (as explained in RFC 1794), to share and allocate the query load and free up network resources. In this process, if multiple resource records of the same nature exist in the zone (such as Web server in this case), the order of the replies rotates for a queried DNS domain name. For example, if the north-rim.com domain has three Web servers configured in the domain to display its Web page for www.north-rim.com, and the need exists to balance the load between them, the administrator could create the following resource records:

DNS Server Operations CHAPTER 2 www.north-rim.com. www.north-rim.com. www.north-rim.com.

IN IN IN

A A A

51

192.168.10.1 192.168.10.2 192.168.10.3

The name server hosting these records then performs round robin by rotating the order of the A resource records when responding to client requests. In this example, the name server responds to the first client request by sorting the addresses as 192.168.10.1, 192.168.10.2, and 192.168.10.3. For the second client query, the name server would respond by sorting the addresses as 192.168.10.2, 192.168.10.3, and 192.168.10.1. The rotation process continues until the cycle is complete (in this example, the rotation would be three rotations).

Windows 2000 DNS server uses a different method to order the records returned to a client. By default, the name server tries to locate the resource record containing the nearest server to the client, and responds with this resource record first in the list. However, this default can be altered to perform the traditional round robin.

Caching and TTL During the query process, the name server caches all data it receives for the amount of time specified in the time to live (TTL), which is specified in seconds. This value is set by the DNS administrator, and can be set to a smaller value to help ensure consistency. The drawback to reducing the TTL is that it increases the load on the name servers that contain the name, in addition to Internet traffic. The drawback to increasing the TTL (as mentioned in the caching-only sever section) is that cached data may not be the most up-to-date, particularly if recent changes have occurred on the Internet. After the data is cached, the DNS server starts decreasing the TTL value (expressed in seconds). When the DNS server answers a query with its cached data, it includes the remaining TTL for the data so the client will know how long the data is valid. When the TTL value reaches zero (0), the data is removed from the cache on both the name server and the client resolver.

DNS Resolver Cache Windows 2000 hosts implement a special DNS cache called the DNS Resolver Cache. This cache is created by the DNS Client service when query responses are received from an authoritative DNS server. The information is held for the set TTL and is referenced in subsequent queries until the TTL expires. By default, the cache TTL is based on the TTL value received in the DNS query response, typically as set on the authoritative DNS server for the zone.


NOTE

2

52

Negative Caching In addition to caching successful query responses, resolvers and servers can also cache negative responses (such as a nonexistent domain). Negative caching can reduce the response time and network traffic for negative answers. As with most caching functions, the TTL is also applicable to negative caching. RFCs 1034 and 2308 specify negative caching, whereas RFC 1034 addresses configuration of cache negative responses and makes negative caching optional. Negative caching is discussed in further detail in Chapter 6.

Zone Transfers Zone changes made at a master server must be replicated to all secondary servers for the zone to ensure consistency of resource records throughout the zone (as shown in Figure 2.11). The process of updating the secondary servers is called a zone transfer. The original form of zone transfer is known as a full zone transfer (AXFR), which copies the entire zone file. Active Directory incorporates a new type of zone transfer called the incremental zone transfer (IXFR), which transfer only the resource record modifications or updates as opposed to the entire zone file. “.” (root

.com

Primary DNS server

.edu

sams

sams.com

Zone transfer

abd.com

dns1 Secondary DNS server sams

sales.sams.com dns2

techdc1

tech.sams.com zone

FIGURE 2.11 The zone transfer in the sams.com domain for the sams DNS zone.


53

Full Zone Transfer In a full zone transfer, the primary name server copies the entire zone database to the secondary server for that zone. For this transfer to occur, secondary servers must use the following process: 1. The secondary server polls the master server at the time interval set in the Refresh field of the State of Authority (SOA) resource record. 2. The master server responds with the SOA resource record. 3. The secondary server compares the serial numbers of the SOA records. If the master’s serial number for the zone is higher than the secondary server’s serial number, it sends an AXFR request for a full zone transfer.

If the master server fails to respond to polling by the secondary server, the secondary server continues to poll based on the interval specified in the Retry field of the SOA resource record. If the master fails to respond after the interval specified in the Expire field, the secondary server discards its zone and stops responding to queries for that zone.

NOTE There are two types of full zone transfers (AXFR): one requires a single record per packet and the other allows multiple records per packet. Windows 2000 DNS server supports both, but certain versions of BIND do not. For more information on interoperability, see Chapter 9.

Incremental Transfer Because full zone transfers impact network bandwidth, particularly in large companies with complex DNS configurations, RFC 1995 specifies a new zone transfer method called the incremental zone transfer. As the name implies, incremental zone transfers allow only the zone modifications to be copied. The transfer process is essentially the same as the full transfer. The secondary name server still relies on the SOA to determine polling frequency and other transfer parameters. The difference is that the secondary name server will send an incremental zone transfer (IXFR) query as opposed to a full transfer query (AXFR). The primary or master then forwards only the modified resource records, starting with the oldest updates first. The secondary updates its resource records in similar fashion, starting with the oldest records first. After the update is complete, the secondary discards the old zone version. The master server can perform a full or incremental zone transfer based on the requesting secondary name server. Although zone transfers can conserve bandwidth, they do require local


4. The master server transfers the full zone database to the secondary server.

2

54

storage (on the requesting name server) of zone version records. However, these records can be deleted if necessary.

DNS Notify DNS Notify is a feature of Windows 2000 that allows the master server to notify specific secondary servers of changes or updates to the zone file. In response, the secondary servers verify their need to update and initiate a zone transfer. With DNS Notify, the master server hosts a notify list, composed of secondary server IP addresses, which are the only servers contacted, even though other secondaries may exist in the zone. The DNS Notify process occurs as follows: 1. After the Serial Number field in the master name server’s SOA record is updated (because of the new version of the zone), it sends a notify message to the secondary servers in its notify list. 2. The “listed” secondary servers respond with an SOA-type query to verify whether its zone data needs to be updated. 3. If the serial number is higher in the master server’s SOA record (which is the norm), the secondary server requests an AXFR or IXFR zone transfer.

Summary This chapter focused on various DNS server operations: primary, secondary, forwarders and slaves, and caching only. Primary name servers host the writable zone files that are distributed to the secondary name servers, which host read-only copies of the files. Forwarders and slaves perform queries on the Internet, whereas caching-only servers reduce network traffic and replication. Forward lookups map hostnames to IP addresses and require SOA and NS resource records, whereas reverse lookups map IP addresses to hostnames using the PTR resource record. Recursive and iterative queries are the two types of queries in name resolution. Windows 2000 uses iterative queries by default. This chapter also focused on zone files and their data, known as resource records. In legacy and Windows 2000 DNS there are two types of zone transfers available: full and incremental. The incremental can reduce network bandwidth issues. Windows 2000 DNS also implements a process called DNS Notify, which allows primary name servers to inform specific secondaries that its zone data has been updated. The next chapter focuses in DNS and Active Directory integration.

Active Directory and DNS

IN THIS CHAPTER • Windows 2000 Active Directory • Windows 2000 DNS Features and Components 65 • How DNS integrates with Active Directory 78 • Summary

85

56

CHAPTER

3

56

In Microsoft’s words, Active Directory is an enterprise-class directory service based on Internet standards that provides information and the required services for that information to users. Active Directory is provided with all Windows 2000 Server products and is Microsoft’s implementation of an existing directory model (X.500), an existing communication protocol (LDAP), an existing location and name resolution technology (DNS). This chapter briefly focuses on the major technical features and components of Active Directory to make sure that you are onboard with the major features of this directory. After discussing the features of Active Directory, the chapter explores Microsoft’s implementation of DNS and why DNS is required for Active Directory to function properly.

Windows 2000 Active Directory Active Directory is a distributed database (like DNS) that can expand across multiple Windows 2000 Servers in the network. The schema of this database is expandable and object-oriented; it represents each user account and resource as an individual object. Because the database is structured in a hierarchical tree, it allows for easier organization and permissions assignment. Active Directory is very efficient and the data stored within Active Directory is both redundant and load-balanced. Updates to Active Directory are propagated through multimaster replication throughout the network. Active Directory replaces the limited domain functionality that existed in Windows NT4.

Active Directory Features There are many advanced technical features to Active Directory. According to Microsoft, most of the features can be categorized into the following three key areas: • Manageability • Security • Interoperability These issues evolved from experience and shortcomings with Windows NT 4 in the enterprise. Let’s take a closer look at these key areas.

Manageability Active Directory has many features that can be categorized into the area of manageability. These features are important because previous versions of Windows NT lacked this functionality, particularly at the enterprise level. The following sections present and describe some of the key manageability enhancements in Active Directory.

Active Directory and DNS CHAPTER 3

57

Centralized Management Active Directory centrally manages Windows users, clients, and servers through a single consistent management interface called the Microsoft Management Console (MMC). The MMC can reduce redundancy and maintenance costs by acting as a framework for hosting different administrative consoles. The MMC was introduced in Internet Information Server 4.0 (IIS), but not widely implemented, and is now an integral part of Windows 2000. The MMC is a tool acting as an interface to other tools (called snap-ins). Although the console itself offers no management behavior, the main MMC window provides commands and tools for authoring consoles. Additional MMC components (snap-ins) can be added to customized administration. In Figure 3.1, the MMC is hosting the DNS snap-in, which allows for administration of DNS for the domain. MMC snap-ins are developed by Microsoft and third-party companies, and are always hosted in the MMC console.

3 ACTIVE DIRECTORY AND DNS

FIGURE 3.1 The MMC with the DNS snap-in added.

We’ll take a closer look at administering DNS in the MMC in Chapter 6, “Administering DNS Servers Using MMC.” Active Directory also provides several administrative tools to ease and centralize management. These can only be implemented from a computer accessing a Windows 2000 domain. The three core Active Directory administrative tools available through the MMC on Windows 2000 domain controllers are:

58

• Active Directory Users and Computers • Active Directory Domains and Trusts • Active Directory Sites and Services The Active Directory Users and Computers MMC snap-in is one of the most useful tools for administering Active Directory. It replaces and improves on the Server Manager and User Manager tools from Windows NT 4.0. Custom tools to individual administrators can be configured with specific administrative responsibilities. The Active Directory Domain and Trusts MMC snap-in allows administrators to manage trusts in multidomain enterprises. Smaller organizations with single domains may not use this management tool except to manage Operation Masters (domain controllers that prevent update conflicts in Active Directory). For more information on Operation Masters, see Sams Microsoft Active Directory Administration (ISBN 0-672-31975-6), by Kevin Kocis. The Active Directory Sites and Services MMC snap-in allows administrators to manage sites in Active Directory, as well as establishing subnet allocation and replication between the sites. The Services feature consists of Public Key Infrastructure (PKI) and Remote Access Services (RAS). Group Policy Group Policy enables administrators to centrally identify and manage the policies governing users, groups, computers, and print resources in the enterprise. In Active Directory, Group policy can be set at the site, domain, or organizational unit (OU) level. Policies can be implemented to control settings for users and computers, such as logon/logoff scripts, security, and desktop and Registry settings. Policy-based management can simplify tasks such as operating system updates, installing applications, managing user profiles, and restricting system access. Group Policy can be regarded as a combination of NT 4.0 policies and zero administration. For many larger enterprises, NT 4.0 laptops with zero administration proved too restrictive if sites were configured differently (such as no DHCP), and the need arose to configure the machine locally. Although Group Policy is complex by default, most companies can benefit by implementing it in some form. Global Catalog The Global Catalog (GC) is another centralization effort of Windows 2000 Active Directory. The Global Catalog is a subset of Active Directory—an index containing all the objects in the Active Directory forest (all domains), as well as a subset of each object’s properties. The Global Catalog enables users to search by selected attributes to find an object easily anywhere in the forest.


59

NOTE The Global Catalog offers a faster search of AD objects because it contains all the objects in the forest. However, it holds only certain selected attributes of each object, allowing for faster searches.

Every domain controller in a forest stores three full, writable directory partitions: a domain directory partition, a schema directory partition, and a configuration directory partition. A Global Catalog server is a domain controller that stores these writable directory partitions, as well as a partial, read-only copy of all other domain directory partitions in the forest. Backward Compatibility An Active Directory domain can consist of heterogeneous clients, including Windows NT4, Windows 95 and Windows 98, Macintosh and UNIX workstations. Although clients have full access to shared resources within the domain (Mac and UNIX may require additional configuration), only Windows 2000, NT4, and Windows 9x clients (with the Active Directory client software installed) can use Active Directory to query information about these shared resources. Pre–Windows 2000 machines use NetBIOS name resolution for backward compatibility.

Security Security is one of the enhanced features in Active Directory. Windows 2000 and Active Directory security are completely integrated and more robust than previous versions of NT. Many new standards and components contribute to this effort including Kerberos Version 5 (V5) support, Public Key Infrastructure (PKI), and attribute-level security. Kerberos The Kerberos protocol allows negotiation of the encryption algorithm. Most Kerberos implementations default to the Data Encryption Standard (DES), which has a 56-bit key length. Although Windows 2000 Kerberos does support DES for interoperability purposes, its default encryption algorithm is RC4 (allowing for greater security—the greater the bit length, the better the security). In North America, 128-bit RC4 keys are used, whereas the international version supports only 56-bit keys. A proprietary Windows 2000 environment uses only the RC4 algorithm.

ACTIVE DIRECTORY AND DNS

Multi-Master Replication With multi-master replication, any update or modification made to any domain controller is copied to all the other domain controllers in the same domain. This process ensures that the directory is available even if a domain controller fails and assists with controlling bandwidth by providing multiple copies of the directory across multiple servers. Replication is discussed in greater detail in Chapter 8, “Windows 2000 DNS and WINS Replication.”

3

60

NOTE Although Windows 2000 supports Kerberos, the Microsoft version is different from versions that currently run on UNIX machines. Chapter 7, “Windows 2000 and DNS Security,” and Chapter 9, “BIND and Windows 2000 Interoperability,” explain in further detail the caveats and configuration of Kerberos for better interoperability.

Public Key Infrastructure and X.509 Certificates Active Directory supports x.509 certificates and public key infrastructure (PKI) to interoperate with extranet and e-commerce application deployment. The Windows 2000 PKI provides the framework of services, technology, protocols, and standards to allow the deployment and manageability of an information security system. The major components of the Windows 2000 public key infrastructure include the following: • Windows 2000 Certificate Services for issuing and managing digital certificates. • Microsoft CryptoAPI and cryptographic service providers (CSPs) for providing cryptographic operations and private key management. • Certificate stores for storing and managing certificates in the enterprise. Attribute-Level Security All objects in the Active Directory are protected by Access Control Lists (ACLs). ACLs determine who can see an object and what actions each user can perform on the object. An object’s existence is never revealed to a user without permissions to view it. The Global Catalog (GC) enforces object- and attribute-level security for detailed control of access to information stored in the directory. An ACL is a list of Access Control Entries (ACEs) stored with the object it protects. In Windows 2000, an ACL is stored as a binary value called a security descriptor. Each ACE contains a security identifier (SID), which identifies the principal (account) to whom the ACE applies and information on what type of access the ACE permits or denies. ACEs can apply to the whole object or the individual attributes of the object. With this granularity, administrators can control not only which users can see an object, but what properties those users can see. Other Security Features Active Directory supports a few other security features that provide more security and manageability that its NT predecessors. Some new features include: • LDAP over SSL and ACL support


61

• Required Authentication • Spanning Security Groups • Delegated Administration These features are explained in greater detail in Chapter 7.

Interoperability A key area of concern for administrators in heterogeneous environments is Active Directory’s capability to integrate with current and legacy business-critical systems. Although Active Directory does not provide a client solution allowing UNIX, Novell, and Macintosh to utilize Active Directory searches, these may be future possibilities through the use of a third-party utility. Despite it’s apparent lacking with Active Directory, Windows 2000 Server still delivers UNIX, Novell NetWare, Windows NT4, and Macintosh interoperability, allowing you to integrate Windows 2000 Server into an existing environment. Windows 2000 Server can be integrated into most current environments because it provides migration paths from different systems, devices, and applications.

Native LDAP Active Directory implements native LDAP so no translation is required to ensure interoperability in extranet environments and e-commerce applications. In addition, Active Directory also provides LDAP-based change history interfaces to make it a strong candidate (from Microsoft’s perspective) as a meta-directory and management focal point within organizations.

NOTE Although Active Directory attempts to maintain itself as a strong meta-directory candidate, many heterogeneous environments may refrain from integrating it as such because of its newness in the directory services arena. AD may need time to prove itself first, particularly in the areas of reliability and interoperability.


Domain Name System (DNS) Standards Windows 2000 uses DNS standards for hierarchical naming of Active Directory domains and computers. Domain and computer objects are part of both the DNS domain hierarchy and the Active Directory domain hierarchy. Even though the objects have identical names, these domain hierarchies represent separate namespaces. The section “Active Directory Components” focuses on the logical and physical components of Active Directory and better illustrates the similarity in the DNS and AD hierarchies.

62

Active Directory uses LDAP version 2 and version 3, and provides the LDAP service for object location. LDAP relies on TCP as the underlying transport-layer protocol; therefore, a client searching for an Active Directory server within the kevinkocis.com domain would look up the DNS record for ldap.tcp.kevinkocis.com.

NOTE Active Directory uses both DNS and LDAP services to locate objects in Active Directory.

Extensible Schema In Active Directory, the schema is a set of attributes used to describe a particular object class. The schema is stored within Active Directory just like other objects and can be automatically replicated throughout the enterprise. The directory schema can be expanded through the creation of new properties and objects, such as creating data structures for “home-grown” or internal applications. Active Directory Connectors (ADC) Active Directory Connector (ADC) consists of a replication and mapping tool that provides directory synchronization and import/export tools. ADC allows for replication of an Exchange 5.5 directory with Active Directory and offers connectivity to Novell Directory Services (NDS). Following replication, MMC snap-ins can be used to manage the information.

Active Directory Logical and Physical Components As you notice, there are many new technical components to Active Directory. This section focuses on the key components, including the following: • Namespace • Tree • Forest • Domain • Organizational Unit • Site

Namespace A namespace is the defined area where standardized names can be used to symbolically represent information (such as a directory object or an IP address) and can be resolved to the object itself. The domain hierarchy defines a namespace. Rules are applied to each namespace to determine how names can be created and used. In the cases of the DNS and Active Directory,


63

the namespace is hierarchically structured. Specific rules dictate how the namespace is partitioned. Other namespaces, such as the NetBIOS namespace, are flat (nonhierarchical) and cannot be partitioned.

Tree The Active Directory domain tree resembles the DNS tree (as illustrated in Chapter 1, “Domain Name System Fundamentals”) with the root at the top of an inverse tree. A tree is a hierarchy of objects and containers. A tree logically displays how objects are connected, or those connecting paths. A tree usually consists of containers that store directory objects. Both DNS and Active Directory domains are containers in a tree. An Active Directory tree is illustrated in Figure 3.2. Endpoints, or nodes, in a tree do not contain any other objects. Computer hosts are endpoints in a domain tree because they contain no other objects. .com

kevinkocis.com

3

il.na.kevinkocis.com

FIGURE 3.2 An example of an Active Directory tree.

A domain tree (a tree) is comprised of several domains that share a common schema and configuration, forming a contiguous namespace. Domains in a tree are also linked together by trust relationships. The Active Directory is a set of one or more trees. Trees can be viewed two ways. One view is the trust relationships between domains. The other view is the namespace of the domain tree.

Forest A forest is a collection of one or more domain trees that do not form a contiguous namespace (also referred to as noncontiguous or disjointed), despite the fact that they share a common


na.kevinkocis.com

64

schema, configuration, and Global Catalog. Although trees in a given forest trust each other through transitive hierarchical Kerberos trust relationships, the forest does not need a distinct name as in a domain tree. Domain trees are linked together in a forest through two-way, transitive trusts, allowing users with appropriate permissions to access resources in any domain of the forest. Figure 3.3 illustrates an Active Directory forest. .com

north-rim.com

kevinkocis.com

na.north-rim.com

az.na.north-rim.com

na.kevinkocis.com

il.na.kevinkocis.com

FIGURE 3.3 An example of an Active Directory forest.

Domain A domain is a logical security boundary and replication boundary of a Windows NT or Windows 2000 computer network. The Active Directory is made up of one or more domains. A domain can span more than one physical location, and hosts its own security policies and security associations with other domains. A domain becomes a domain tree when multiple domains are connected by trust relationships and those respective domains share a common schema, configuration, and global catalog. Windows 2000 can be configured for two domain modes—mixed and native. Mixed mode is the default and allows for a combination of Windows 2000 and NT 4.0 domain controllers to exist simultaneously. Native mode only consists of Windows 2000 domain controllers. The conversion to native mode is one-way only; there is no converting back to mixed mode.

Organizational Unit Any administrator familiar with Exchange 5.5 infrastructure (and later versions) will understand the concept of the Organizational Unit (OU). The OU in Active Directory provides another level of partitioning to the logical namespace. OUs act as containers that can contain


65

objects including other OUs, users, groups, and computers. These objects can be organized into logical containers depending on variables such as geographic or organizational structure. OUs also allow for the delegation of administration, and the application of Group Policy. Group policy (mentioned earlier in this chapter) is based at the OU level, making this a critical and important feature of Active Directory.

Site Unlike domains, sites are a physical component of Active Directory. A site is defined as one or more well-connected TCP/IP subnets. Microsoft defines “well-connected” as a network where connectivity is highly reliable and fast (for example, LAN speeds of 10 million bits per second or greater). A site is a location in a network that contains Active Directory servers, and is based on connectivity and proximity. Defining a site as a group(s) of subnets defines the configuration of the Active Directory replication topology based on the physical network. When a user logs on, the Active Directory client attempts to locate DCs in the user’s site. Because computers in the same site have high network proximity, communication is reliable and efficient. Because the workstation is aware of its TCP/IP configuration and subnet, when the user logs on to Active Directory the local site is defined conveniently and easily.

NOTE If you want further information on Active Directory features and administration, check out Sams Microsoft Active Directory Administration (ISBN 0-672-31975-6) and Sams Windows 2000 Server Unleashed (ISBN 0-672-31739-7).

Windows 2000 DNS Features and Components Windows 2000 DNS introduces some new features and components from its NT predecessor and legacy DNS implementations. In Windows NT 4.0, the primary name service remained WINS, although DNS was included. When a Windows NT 4.0 Workstation client booted in a Windows NT 4.0 domain, it typically contacted the WINS server to locate a domain controller for authentication. In a Windows 2000 domain, the location and name resolution process is performed by DNS. Windows 2000 DNS also includes support for Service Locator resource records (SRV records), which are actually required for Active Directory. Support for dynamic updates, secure dynamic updates, and incremental zone transfer functionality is available in Windows 2000 DNS. These features were not included in Windows NT 4.0 (nor are they supported with it), but they are


Now that you are familiar with major Active Directory features and terms, let’s turn our attention to how Active Directory and all its features rely on DNS.

66

included in certain releases of third-party DNS solutions (BIND and NDS). Windows 2000 DNS also offers support for Unicode characters. Let’s take a closer look at these new features.

New DNS Resource Record Support (SRV) Chapter 2, “DNS Server Operations,” addressed structural fundamentals of the Service Locator (SRV) record used by Active Directory. This section will focus more on the functionality and utilization of the SRV record in Active Directory. The SRV record maps the name of a service (such as LDAP or Kerberos) to a domain controller offering that service. Active Directory relies on the capability of clients and servers to locate services in their respective domains. In a Windows 2000 network, the SRV record is required when using Active Directory to locate domain controllers. This process is achieved through an LDAP SRV resource record.

NOTE SRV record support is required for Active Directory implementation; therefore, any DNS servers in the enterprise must support SRV records. BIND 4.9.6 supports SRV records, but version 8.2.2 or higher is recommended for other reasons.

When a domain controller starts up, the Net Logon service uses dynamic updates to register its SRV resource records in the DNS database. In Windows NT 4.0, hosts that sponsored certain services were located throughout NetBIOS advertisements. In Windows 2000, the experimental SRV record advertises services (such as LDAP and Kerberos) and points to domain controllers and their IP addresses. This allows several domain controllers in a single domain environment to move transparently to new locations where users will locate them based on services. See Figure 3.4 for the default installation of SRV records when Active Directory is installed. For example, when a workstation logs on to a Windows 2000 domain, it queries DNS for SRV records in the following general format: _Service._Protocol.DnsDomainName

The parameters in this example are as shown here: • The Service field applies to the service (HTTP, LDAP). • The Protocol field applies to the protocol (TCP, UDP). • The DnsDomainName applies to the name of the DNS domain.


FIGURE 3.4 The default TCP SRV records created in Windows 2000 DNS.

The Service and Protocol fields of the SRV resource record require an underscore (_) prefix to prevent possible collisions with existing names in the namespace.

For example, Active Directory servers offer the LDAP service over the TCP protocol; therefore, a resolver in the kevinkocis.com domain would issue the following query when searching for a LDAP server: _ldap._tcp.kevinkocis.com.

DNS Record Registration When a domain controller starts up, it registers its address with DNS, including its hostname (A record), and pseudonyms such as its SRV and CNAME records. If several domain controllers have the same conditions, multiple records with the same pseudonym would exist. For example, a simple DNS lookup of “_ldap._tcp.dc._msdcs.kevinkocis.com.” will return the names and addresses of all the domain controllers in the kevinkocis domain.


NOTE

67

68

SRV Records Registered by Net Logon A number of SRV records are registered by Net Logon on a Windows 2000 domain controller. Table 3.1 identifies these records and their respective references in the domain or forest (DnsDomainName, DnsForestName). TABLE 3.1 NetLogon SRV Records and their Domain/Forest References Records

Domain or Forest References

_ldap._tcp.DnsDomainName

This record enables a client to locate a server running the LDAP service in the domain named by DnsDomainName. The only requirement is that the server support the LDAP API—it does not have to be a Windows 2000 domain controller (although DCs register this record by default).

_ldap._tcp.SiteName._sites.DnsDomainName

This record enables a client to locate a server running the LDAP service in the domain named by DnsDomainName and located in the site specified by SiteName (the site container in Active Directory). The server does not have to be a Windows 2000 domain controller (although DCs register this record by default). This record enables a client to locate a domain controller in the domain named DnsDomainName. This record enables a client to locate a domain controller in the domain named DnsDomainName, and the in the site named SiteName. This record enables a client to locate the domain controller acting as the Primary Domain Controller (PDC) emulator for the mixed-mode domain named DnsDomainName. Only the PDC emulator registers this SRV record.

_ldap._tcp.dc._msdcs.DnsDomainName

_ldap._tcp.SiteName._sites.dc._ ➥ msdcs.DnsDomainName

_ldap._tcp.pdc._msdcs.DnsDomainName


69

TABLE 3.1 Continued Records


_ldap._tcp.gc._msdcs.DnsForestName

This record enables a client to locate a Global Catalog (GC) server in the forest named DnsForestName. This record enables a client to locate a Global Catalog (GC) server in the forest named DnsForestName, and in the site named SiteName. This record enables a client to locate a Global Catalog (GC) server in the forest named DnsForestName, which does not have to be a Windows 2000 domain controller. The server is required to support the LDAP API and act as a GC server for the forest named DnsForestName.

_ldap._tcp.SiteName._sites.gc._ ➥ msdcs.DnsForestName

_gc._tcp.DnsForestName

_gc._tcp.SiteName._sites.DnsForestName

_kerberos._tcp.DnsDomainName


_ldap._tcp.DomainGuid.domains._ ➥ msdcs.DnsForestName

This record enables a client to locate a Global Catalog (GC) server in the forest named DnsForestName, and in the site named SiteName. The server is not required to be a Windows 2000 domain controller. It needs only to support the LDAP API and act as a GC server for the forest named DnsForestName. This record enables a client to locate a domain controller based on its GUID (DomainGuid) in the forest named DnsForestName. All domain controllers register this SRV record. This record enables a client to locate a server running the Kerberos Key Distribution Center (KDC) server in the domain named DnsForestName. The KDC distributes security keys for Kerberos. The server is not required to be a Windows 2000 domain controller, but must support the RFC 1510compliant Kerberos KDC service.

70

TABLE 3.1 Continued Records


_kerberos._udp.DnsDomainName

This record is the same as kerberos._tcp.DnsDomainName, except that it uses UDP as opposed to TCP. This record enables a client to locate a server running the Kerberos server KDC in the domain named DnsForestName, and in the site named SiteName. The server is not required to be a Windows 2000 domain controller, but must support the RFC 1510-compliant Kerberos KDC service.

_kerberos._tcp.SiteName._ ➥ sites.DnsDomainName

_kerberos._tcp.dc._msdcs.DnsDomainName

_kerberos.tcp.SiteName._sites.dc._ ➥ msdcs.DnsDomainName

_kpasswd._tcp.DnsDomainName

_kpasswd._udp.DnsDomainName

This record enables a client to locate a Windows 2000 domain controller running the Kerberos KDC server in the domain named DnsForestName. This record enables a client to locate a Windows 2000 domain controller running the Kerberos KDC server in the domain named DnsForestName, and in the site named SiteName. This record enables a client to locate a Kerberos Password Change server in the domain named DnsForestName. The server is not required to be a Windows 2000 domain controller, but must conform to the “Kerberos Change Password Protocol,” and must support the RFC 1510-compliant Kerberos KDC service. This record is the same as _kpasswd._tcp.DnsDomainName, except that it uses UDP as opposed to TCP.


71

_msdcs Subdomain As you have seen, the _msdcs is a Microsoft-specific subdomain that allows location of specific Windows 2000 domain controllers in the domain or forest. This subdomain also permits locating the domain controllers by GUID when a domain has been renamed. Windows 2000–based domain controllers register SRV records to help clients locate domain controllers by server type or by GUID (dctype). The format is as follows: _Service._Protocol.DcType._msdcs.DnsDomainName

Microsoft’s logic for this proprietary implementation is that LDAP servers and directory servers can exist on non-Windows 2000–based domain controllers. As a result, the _msdcs subdomain is reserved for locating Windows 2000 domain controllers. DCs running the service mentioned in the resource record will be contacted, but non–Windows 2000 servers running LDAP (in this example) would not be. Microsoft implemented the _msdcs subdomain to avoid confusion in the DNS namespace.


FIGURE 3.5 The default _ldap Properties window.

As illustrated in the previous section, the Net Logon service registers SRV records identifying some of the common server types (such as DC, GC, and PDC) as prefixes in the _msdcs subdomain. As a result, two sets of DNS names can be used to find an LDAP server, one that only supports LDAP (for example), and one that supports LDAP and is also running Windows 2000.

Host Records for Non–SRV-Aware Clients For clients that do not support SRV records, Net Logon registers the following A records for LDAP clients, even though the Locator does not use these records:

72

•

DnsDomainName

•

gc._msdcs.DnsForestName

•

DsaGuid._msdcs.DnsForestName

The DnsDomainName allows the client to locate domain controllers through its A record. A client not supporting SRV records references the name using the A record, whereas a client supporting SRV references the appropriate SRV resource record for the domain controller. The same process applies to the gc._msdcs.DnsForestName record, which allows the client to locate Global Catalog servers through its A record. In the event that a domain controller’s name may have changed, the DsaGuid._ msdcs.DnsForestName record (which is actually an alias or CNAME record) references the domain controller by its GUID or directory system agent (DSA). This record is actually used to implement a name change on a domain controller as well.

Dynamic DNS Update Support Windows 2000 supports dynamic updates as specified in RFC 2136, which allow clients to dynamically register their resource records either directly with DNS or through a Windows 2000 DHCP server. In Windows 2000, clients can send dynamic updates for the following network adapters: • DHCP adapters • Static adapters (non-DHCP) • Remote access adapters (RAS) Notwithstanding the adapter, a Windows 2000 DHCP client service sends dynamic updates to the authoritative DNS server. This process runs on all Windows 2000 computers regardless of whether they are configured statically or as DHCP clients. By default, the client that supports dynamic updates dynamically registers its A resource records and maybe its PTR resource records every day (24 hours) or if any of the following situations occur: • A change in the TCP/IP configuration, including the addition of an IP address (new adapter) • A renewed or released DHCP address • Any Plug-and-Play event Whenever a DHCP lease expires, the dynamic update client unregisters its IP address mappings by default. Windows 2000 systems can be configured to register or not to register


73

their hostnames and IP addresses in DNS. However, the Windows 2000 DHCP server is configured by default to register only the PTR records for its Windows 2000 clients. It can be configured to update DNS regardless of the client setting. The Windows 2000 DHCP server must also be configured to not register host information if this is preferred.

Dynamic DNS Process Dynamic DNS allows for either a Windows 2000 client or Windows 2000 DHCP server to update records in DNS. In the case of the client, the host sends a DNS registration update message to the DNS server, which in turn updates the (A) record. If the client is running DHCP, every time an address event (as mentioned in the previous section) occurs, the DHCP client updates the DHCP server with its FQDN. The DHCP server registers the PTR record as well. Non-DHCP Windows 2000 clients register both the (A) RR and the PTR RR with the DNS server themselves. If a Windows 2000 DHCP client communicates with a Windows NT 4.0 DHCP server, the client registers a PTR RR directly with the Windows 2000 DNS server.

CAUTION I do not recommend use of the DHCP server to perform secure dynamic updates on behalf of DHCP clients that do not support the FQDN option. The DHCP server “owns” that name from a permission perspective, and only that DHCP server can update the name. However, the DHCP servers can be added to the DNSUpdateProxy Group, which allows them to overwrite each other’s records as necessary.

The Windows 2000 DHCP server can update A and PTR records to the Windows 2000 DNS server (or any DNS server supporting Dynamic updates). This scenario is favorable when non–Windows 2000 DHCP clients exist in the domain. Microsoft hopes most enterprises will configure Windows 2000 DHCP and Windows 2000 DNS to serve this dynamic process. Windows 2000 Client Dynamic Update As mentioned earlier, a Windows 2000 client can directly register its A and PTR records with a Windows 2000 DNS server. When a Windows 2000 client boots up, it receives its IP address from the DHCP server and then contacts the local name server to locate the primary name server and the zone. When the client receives the resolution information, it then attempts to update its record information on the primary name server.


DHCP clients that do not support the FQDN option are not capable of dynamic updates. In this situation, the Windows 2000 DHCP server must perform dynamic updates of both the A and the PTR records on their behalf.

74

The default update process as illustrated in Figure 3.6 is performed as detailed here: 1. The Windows 2000 client queries the local name server for the authoritative name server. 2. The local name server replies with the zone name and the primary name server. 3. The client attempts an update, using a list of prerequisites including the existence of the resource record and name in DNS. 4. The DNS server then processes the request.

Windows 2000 DHCP Server

1

2

Windows 2000 DNS Server

3

Windows 2000 client

FIGURE 3.6 Dynamic DNS updates from a Windows 2000 client.

Windows 2000 DHCP Server Dynamic Update If the DHCP client is not running Windows 2000, the Windows 2000 DHCP server can register its A and PTR records with a Windows 2000 DNS server. When the client boots up, it receives its IP address from the DHCP server, and does not contact any name server. Instead, the Windows 2000 DHCP server registers the records with the Windows 2000 DNS server. The default dynamic update for Windows 2000 DHCP clients as illustrated in Figure 3.7 is performed as explained here: 1. The Windows 2000 client obtains a valid IP address from the Windows 2000 DHCP server. 2. The client sends a host (A) DNS update to the DNS server. 3. The DHCP server sends a PTR update to the DNS server.


75

3

Windows 2000 DHCP Server

1

Windows 2000 DNS Server

2

Non-Windows 2000 client

FIGURE 3.7 Dynamic DNS updates for a Windows 2000 client from a Windows 2000 DHCP server.

NOTE

Secure Dynamic Update For enterprises implementing Active Directory–integrated zones, administrators can implement dynamic update security by restricting users, groups, and computers based on access control lists (ACLs). These ACLs specify which users and groups are authorized to modify zones and zone records. For more information on ACLs and security, see Chapter 7. Secure dynamic updates can protect zones and resource records from being modified by unauthorized users and computers, and offer the capability to specify the users and groups capable of modifying zones and resource records.

NOTE Secure dynamic update can only be implemented in Active Directory-integrated zones.


There is no security over dynamic update in Windows 2000 DNS unless the zone is Active Directory integrated.

3

76

With secure dynamic update, only the computers and users you specify in an ACL can create or modify the zone or objects within the zone (called dnsZone and dnsNode objects, respectively). By default, all members of the Windows 2000 Authenticated User group have Create permission for this object in the Active Directory forest. The computer must also have a domain account for this process. Secure Dynamic Update Process By default, Windows 2000 clients first try to register their dynamic DNS updates nonsecured. If required, they will then try secured updates. Windows 2000 clients can be configured to perform each of the following dynamic updates: • Nonsecured, then secured if necessary (default) • Nonsecured only • Secured only Secured updates occur as a result of the exchange of security keys (called a TKEY exchange) between the client and Windows 2000 DNS server. This exchange tries to use Kerberos as the security factor. If successful, a signature record, called TSIG, is used to issue results to the client. The DNS server then uses LDAP to attempt the update. TKEY and TSIG are covered later in the section, “DNS Standards for Secure Dynamic Update.” The default secure dynamic update, as illustrated in Figure 3.8, is performed as follows: 1. The Windows 2000 client queries the local name server for the authoritative name server. 2. The local name server replies with the zone name and the primary name server. 3. The client attempts a nonsecure update, and is refused if the server is configured for secure dynamic updates only. 4. The server refuses the request because it is configured for secure updates only.

NOTE If the server were configured for nonsecure updates, the request would have been granted and the DNS registration would have occurred.

5. The client and Windows 2000 DNS server begin TKEY negotiation, and request the security protocol to use. 6. The name server completes the TKEY negotiation by notifying the client to use Kerberos. 7. The client issues the dynamic update request to the server, signed with the TSIG key. 8. After the DNS server verifies the client using the TSIG key, it tries to update the resources records in Active Directory.


77

9. Depending on the client’s permissions, Active Directory responds with a successful or unsuccessful update. 10. The authoritative name server sends a reply that informs the client of a successful or unsuccessful update. The reply is signed with the TSIG key.

Local Name Server

1

2

8 9

3

Active Directory

4 5 6 7 Windows 2000 client

10

Authoritative Name Server

The Secure Dynamic update process.

DNS Standards for Secure Dynamic Update Windows 2000 supports secure dynamic updates through the Generic Security Service Application Program Interface (GSS-API, specified in RFC 2078), which provides security services and specifies a way to establish a security context by passing security tokens (as part of the TKEY negotiation mentioned in the previous section).

NOTE Secure dynamic updates are also covered in RFC 2137, but this RFC was based on BIND’s DNSSEC security. For more information, see Chapter 9.

The IETF Internet-Draft “GSS Algorithm for TSIG (GSS-TSIG)” describes the algorithm used in the Windows 2000 implementation of the GSS-API. The security for this algorithm is Microsoft’s version of Kerberos (version 5) authentication protocol. The algorithm uses resource records that are not mentioned in any current RFCs. The following resource records provide security services for the algorithm:


FIGURE 3.8

3

78

• TKEY—This record transfers the security tokens between the client and the server as documented in the IETF Internet-Draft “Secret Key Establishment for DNS (TKEY RR).” It also creates secret keys for use with the TSIG resource record. • TSIG—This resource record sends and verifies signature-protected messages as documented in the IETF Internet-Draft “Secret Key Transaction Signatures for DNS (TSIG).”

Legacy DNS Cohabitation/Integration Windows 2000 Server and BIND 8 implementations support dynamic updates. The following DNS servers support SRV resource records: • Windows 2000 Server • Windows NT Server 4.0 Service Pack 4 and later • BIND 4.9.6 and later Microsoft has tested Windows 2000 DNS to work with Windows NT 4.0, BIND 8.2, BIND 8.1.2, and BIND 4.9.7. Windows 2000 supports features not supported in other implementations as shown in Table 3.1. TABLE 3.1 Comparison of Features Feature Support for DNS SRV records Support for dynamic update Support for secure dynamic update (based on the GSS-TSIG algorithm) Support for WINS and WINS-R records Support for fast zone transfer Support for incremental zone transfer Support for UTF-8 character encoding

Windows 2000

BIND 8.2

BIND 8.1.2

BIND 4.9.7

Yes Yes

Yes Yes

Yes Yes

Yes No

Yes

No

No

No

Yes

No

No

No

Yes Yes

Yes Yes

Yes No

Yes No

Yes

No

No

No

How DNS integrates with Active Directory In Windows 2000, the DNS Server service is integrated into the design and implementation of Active Directory. When merging these two features of Windows 2000, two significant benefits occur:


79

• DNS is required for locating Windows 2000 domain controllers, because the Netlogon service uses DNS to register domain controllers in the DNS namespace. • Active Directory can be used to store and replicate the DNS zones, which includes enhanced security, replication, and scavenging functionality. When installing Active Directory on a server computer, you promote the server to a domain controller. At the end of the promotion process, a DNS domain name must be specified for the Active Directory domain. If this server is the first domain controller in the domain, or a DNS server authoritative for the specified domain cannot be located on the network or does not support the DNS dynamic update protocol, you are prompted to install a Windows 2000 DNS server. Remember that a DNS server is required for Active Directory, and for Windows 2000 clients to locate servers or domain controllers within the domain. After you have installed Active Directory, you can use the directory service to store and replicate DNS zones (called Active Directory–integrated zones). Zones stored in the directory appear in a dnsZone container object identified by the zone name set during its creation.

If you use Windows 2000 DNS to support Active Directory, directory-integrated primary zones allow for multi-master updates and enhanced security. In this scenario, any domain controller running the Windows 2000 DNS Server service is considered a primary zone source. And because the Active Directory database maintains the zone (replicated across all domain controllers), any domain controller running the DNS service can update the zone. With Active Directory–integrated zones, administrators can use access control lists (ACLs) to secure any dnsZone object, which provides granulated access to either the zone or a specified resource record in the zone. Whenever a new domain controller is added to an Active Directory domain, directory-integrated zones are replicated and synchronized to the new domain controller automatically. While the DNS service can be uninstalled from a domain controller, directory-integrated zones are already stored at each one. An advantage of combining Active Directory and Windows 2000 DNS is that Active Directory replication is faster and more efficient than standard DNS replication because it uses incremental transfers by default. This allows less data to be copied for directory-stored zone updates. Another advantage includes the option for the domain controller to load all DNS zones and configuration information stored in the directory for the Active Directory domain.


Benefits of Active Directory Integration

80

If you do not integrate the DNS and Active Directory namespaces, they are then stored and replicated separately. Increased administration is then required to design, implement, test, and maintain two different database replication topologies. It may also impact further expansion planning.

Windows 2000 DNS and WINS We have addressed how Windows 2000 DNS integrates with legacy DNS and Active Directory. Although the opportunity to remove Windows Internet Name Service (WINS) in a native environment exists, most enterprises will need to support WINS as they implement Active Directory and Windows 2000 DNS. Windows Internet Name Services (WINS) is a Windows NT Server 4.0 (or higher) service supporting dynamic registration of NetBIOS names to IP address mappings, and providing NetBIOS name resolution. Although Windows 2000 uses DNS as its primary name service, down-level clients (such as NT 4.0 and Windows 9x) still rely on NetBIOS. NetBIOS uses NetBIOS Name Server (NBNS), broadcast or flat LmHosts file. NetBIOS is a network-programming interface used in pre–Windows 2000 networking components. Windows 2000 DNS is WINS-aware, enabling interoperability in a mixed Windows NT and 9x environment. Windows NT 4.0 clients can register in Windows 2000 WINS and Windows 2000 clients can register in Windows NT 4.0 WINS. Windows 2000 provides some new enhancements in its new version of WINS. These enhancements include the following: • Persistent connections • Manual tombstoning • MMC Management and security • Enhanced filtering and searches • Dynamic record deletion and multi-select • Record verification and validation • Export functionality • Increased fault tolerance for clients Chapter 8 explores these WINS enhancements and their configurations. Microsoft supports WINS clients on the following platforms: • Windows 2000 • Windows NT Server


81

• Windows NT Workstation • Windows 98 • Windows 95 • Windows for Workgroups (running TCP/IP-32) • LAN Manager 2.x (not Lan Manager 2.x for OS/2) • Microsoft Network Client 3.0 for DOS if configured with the real-mode TCP/IP driver • Some non-Microsoft operating systems such as versions of UNIX running Samba/Rumba or Macintosh Clients use WINS server to register and release NetBIOS-named processes and client names in the WINS database. Clients also use the WINS database to perform name resolution. WINS is not required for Windows 2000 implementations except for clustering servers. Otherwise DNS and Active Directory handle name resolution and service location.

NOTE

NetBIOS and WINS can be removed from the network after a Windows 2000 upgrade only if no down-level clients using the protocol exist, and if all systems on the network use another name service, such as DNS.

CAUTION The process of removing NetBIOS and WINS should be tested thoroughly prior to cutting off these services.

WINS Query Process The Windows 2000 WINS query process has all WINS clients cache information locally and use the Caching Resolver to parse the cache before querying DNS. When the client boots up, the HOST file is cached, and host updates are instantaneous in the cache. During the WINS query process, the client begins by viewing its local cache for the name. If that process fails, the client then queries DNS. If DNS process fails, the client escalates the name resolution through WINS.


Upgrading your domain to Windows 2000 will not eliminate the need for NetBIOS support in your environment.

82

Suppose that a user attempts to map a network drive on a Windows NT 4.0 workstation machine by issuing the following command: net use \\test.kevinkocis.com.\shared

To connect, the FQDN test.kevinkocis.com must be resolved by DNS or WINS to an IP address. In this example, if no local cached information exists and the name server is configured to perform WINS queries, the following process occurs (as illustrated in Figure 3.9): 1. The client queries the local DNS server (dns1). 2. The server searches for an A record for the FQDN test.kevinkocis.com in its configured zone. 3. When no A resource record is found in the responsible zone, the DNS server separates the hostname (test) from the FQDN. 4. The server then sends a NetBIOS name request for “test” to the WINS server (wins1). 5. If the NetBIOS name is in the WINS database, the name is resolved and the WINS server returns the IP address to the DNS server. 6. The Windows DNS server sends the IP address back to the client, and the connection is established. NetBIOS query for “test” 4 locates “test”

2, 3

5

IP address for “test” Authoritative Name Server (dns1) 1 query for “test.kevinkocis.com”

6 IP address for “test.kevinkocis.com”

Windows 2000 Client

FIGURE 3.9 The WINS query process.

WINS Server (wins1)

WindowsNT Client (test)


83

NOTE WINS automatically handles IP changes for machines, so nothing needs to be altered in DNS.

A reverse lookup with WINS integration is handled differently because the WINS database is not indexed by IP addresses. Therefore the DNS server cannot direct a reverse name lookup to a WINS server to retrieve hostnames. Instead, the name server requests an update from the hosts network adapter. It queries the IP address of the reverse query and waits for the network adapter to respond with a status. When the name server receives the NetBIOS name from the status response, it appends the DNS domain name from the WINS-R record to the provided NetBIOS name. The name server then responds to the client with the new FQDN.

WINS Integration Windows 2000 supports WINS lookup (as implemented in Windows NT 4.0 DNS), which directs DNS to query WINS for name resolution and allows DNS clients to resolve names and IP addresses of WINS clients.

When the authoritative DNS server is queried and the name is not in the zone file, the DNS server would then query the WINS server (if the zone was configured for WINS resolution). If the WINS query is successful, the WINS server returns the associated record to the DNS server. With reverse lookups, if an authoritative DNS server is queried for a PTR record that does not exist in the zone file, and the WINS-R record is present, the DNS server uses a NetBIOS node adapter status lookup.

NOTE DNS clients do not need to know whether a client is registered with WINS or DNS, nor do they need to query the WINS server.


WINS lookup integration requires two Microsoft-proprietary resource records: WINS and WINS-R resource records. The WINS records are added to the forward lookup zone, whereas the WINS-R records are added to the reverse lookup zones.

3

84

Because WINS is a Microsoft-proprietary component, the WINS lookup feature only works if all authoritative name servers in the zone are running Windows 2000 or Windows NT 4.0. Name servers running third-party implementations of DNS do not support WINS and WINS-R records, and their presence in the resolution process can cause data errors or failed zone transfers. Chapter 9 addresses more about integration and WINS issues. The WINS resource record has the following syntax: <domain> WINS [] ➥ <WINS server IP address>

TABLE 3.2 WINS Syntax Parameters and Definitions WINS Parameter

Definition

Domain

Domain name hosting WINS record (always represented as “@”) Always represented as “IN” for WINS records Cache time before the WINS record is discarded Specifies whether the record must be included in zone replication Length of time that a name server using WINS lookup waits before it gives up(represented in seconds) Length of time that a name server using WINS lookup can cache the response from the WINS server (represented in seconds) List the WINS servers IP addresses

Class TTL Local LookupTimeout CacheTimeout WINSServers

The following is an example of a WINS resource record: @

IN

WINS

LOCAL 3

3600

192.168.1.30

The WINS-R resource record has the following syntax: <domain> WINSR [] ➥

The field definitions parallel those of the WINS record, except for the NameResultDomain, which is the domain name appended to the WINS-R record. The following is an example of a WINS-R resource record: @

IN

WINS-R

LOCAL 3

3600

north-rim.com.


85

Summary Active Directory is the directory service for Windows 2000 and is integrated tightly with DNS. Like DNS, Active Directory is a distributed database that features enhanced manageability, security, and interoperability. Like DNS, Active Directory is composed of a namespace and a hierarchical domain structure. Windows 2000 DNS uses the new SRV resource record to locate servers and services in the domain or forest. Windows 2000 also supports dynamic DNS, allowing a Windows 2000 client or Windows 2000 DHCP server (supporting non–Windows 2000 clients) to update DNS resource records. The updates can be secured using enhanced Windows 2000 security. Windows 2000 also supports the Windows Internet Name Services (WINS) for interoperability and upgrade support. Windows 2000 DNS also supports legacy Windows NT 4.0 DNS. For more information on integration and upgrading, see Chapter 9.


CHAPTER

Planning and Installing Windows 2000 DNS

4

IN THIS CHAPTER • Planning DNS Installation/Integration • Installing Windows 2000 DNS • Configuring Servers • Summary

116

109

105

88

88

This chapter focuses on various facets of DNS planning and installation. Windows 2000 DNS requires significant planning and testing, particularly if it is implemented in conjunction with Active Directory or in a mixed environment. This chapter also addresses some DNS strategies, including discussions of DNS implementation in small and large Windows 2000 infrastructures. For the purpose of this chapter, implementation of Windows 2000 DNS is assumed, whether Active Directory is integrated or not.

Planning DNS Installation/Integration Obviously, the DNS integration will directly correlate with the Active Directory structure of the organization, although Active Directory is not required to implement Windows 2000 DNS. On the other hand, Active Directory does require DNS to be implemented. Because DNS name resolution is vital to Windows 2000 operation, it must be designed properly so users can locate servers, printers, and other network resources. If the enterprise is looking to implement Active Directory, and DNS is not yet implemented, the DNS namespace needs to be designed around the Active Directory structure. If the company already has an Internet presence, this namespace cannot conflict with the internal namespace. So in this scenario, the AD infrastructure needs to be planned first and then supported with the DNS structure. In many situations in which DNS already exists in the enterprise, the AD infrastructure should be designed as a separate project. After designing and testing AD, it can then be implemented as a separate namespace or as a subdomain of the current namespace. The following questions must be addressed regarding a Windows 2000 DNS implementation: • Will DNS be internal, external (Internet), or both? • Will DNS be integrated with Active Directory? • Will DNS be implemented by an ISP or internally? • Is there a pre-existing BIND or third-party DNS? These questions basically focus on the scope of the DNS implementation, and their answers will depend on the size, infrastructure standards, and Internet presence of the company. When researching domain names or considering integration of the existing namespace, consider the following steps: • Identify and register the external DNS namespace (if necessary) • Implement and identify internal namespace (for AD and/or internal namespace resolution) • Delegate Active Directory domains subordinate to BIND DNS domains (if necessary)

Planning and Installing Windows 2000 DNS CHAPTER 4

89

Registering Domain Names If the company is smaller or newer to the Internet, it will need to register a second-level domain (SLD) name to connect to the Internet. The initial name development process usually involves the consent and approval of senior management in collaboration with IT/MIS recommendation. The SLD name should be unique and representative of the company (such as samspublishing.com). Many companies can use their company name or an abbreviation for ease of entry.

NOTE Remember that the name must comply with the Internet standard characters referenced in Table 1.1 (in Chapter 1), and should be unique to the business.

The next step involves verification and registration of the domain name with the appropriate agency. The following is a list of agencies that verify and register domain names: • Network Solutions, Inc. (NSI)—www.nsiregistry.com (formerly InterNIC) • Internet Assigned Numbers of Authority (IANA)—www.iana.org • Internet Corporation for Assigned Names and Numbers (ICANN)—www.icann.org Domain names can also be verified and registered through companies called registrars. These organizations reference the main agencies and act as a broker for the process. To verify ICANN-approved companies, go to www.icann.org/registrars/accredited-list.html.

NOTE

DNS Namespace Overlap Overlapping internal and external namespaces is not recommended; in other words, don’t use kevinkocis.com for both the Internet (external) and internal namespace. The usual result of this configuration is obviously incorrect name resolution. If Network Address Translation (NAT) is involved, the issue is more obvious because the external IP address is in an unreachable range for internal clients.

INSTALLING WINDOWS 2000 DNS

In the past, the process of registering DNS domain names was managed solely by NSI (formerly known as InterNIC), but this is now transitioning to a shared registration system.

4

90

NOTE Network Address Translation (NAT) conceals internal network addresses from the Internet, preventing their disclosure as public information. This process translates all internal IP addresses into a single IP address viewed by the Internet or other external source. NAT also helps overcome IP addressing limitations such as restricted IP address allocation and unregistered internal addressing schemes.

When considering internal and external (Internet) namespaces, different names should be implemented on separate servers. The internal namespace can also be a subdomain of the Internet namespace. For example, the external name (www.kevinkocis.com) would be visible on the Internet, whereas a subdomain of the namespace (ad.kevinkocis.com) could provide the internal namespace. Another option is to use kk.com for the internal namespace and further delegate the namespace to other domains and zones (such as sales.kk.com or research.kk.com). These subdomains should reflect your Active Directory domain structure. If the namespace were the same for the Internet and the internal Active Directory namespace, a proxy exclusion would need to be configured for kevinkocis.com. As a result, clients on the kevinkocis.com intranet could not resolve the Internet host called www.kevinkocis.com unless this site were mirrored on the intranet. Figure 4.1 illustrates name resolution with internal and external DNS overlap. External name servers should include only names that need to be visible to the Internet. Internal name servers should contain names required for internal use. Internal name servers can be configured to forward requests that they cannot resolve to external servers for resolution, or through the use of a Web proxy. When planning for DNS servers in your Windows 2000 network, research the following factors thoroughly: • Server types in the current environment • Client types • Security levels • Possible integration/upgrade/replacement of current DNS servers • WINS requirements for name resolution (discussed in Chapter 8, “Windows 2000 DNS and WINS Replication”)


91

.com

WWW Server www1.kevinkocis.com

DNS Server kevinkocis.com

External Network Mirrored Internal Network Firewall

WWW Server intweb1.kevinkocis.com

DNS Server kevinkocis.com

FIGURE 4.1 Name resolution with the same DNS overlap internally and externally.

Domain Naming Recommendations

• Do not use duplicate domain names, even if they are on unconnected networks. Don’t use north-rim.com for the Internet presence as well as the intranet. This can lead to confusion when SRV records point to the wrong name server. • Use distinct and easily remembered domain names. Consideration of geographic location or functionality as well as infrastructure need is important to naming domains. For example, a root domain of north-rim.com (an ICANN-registered SLD) can be delegated into obvious subdomains based on location: •

az.north-rim.com

(for an Arizona site)

•

il.north-rim.com

(for an Illinois site)

•

tx.north-rim.com

(for a Texas site)

4 INSTALLING WINDOWS 2000 DNS

Because Active Directory domain naming follows DNS standards, the Active Directory root domain must be unique throughout the DNS hierarchy, both internally and externally. There are several recommendations to follow when naming domains.

92

• Limit the number of domain trees in the organization. This will ease searches by nonMicrosoft LDAP clients who might not use the global catalog. It will also ease proxy client administration by limiting the number of exceptions in the exclusions list. By subdividing the domain namespace under a single root, Active Directory administration will also be alleviated. • Use NetBIOS names for the first part of the DNS name. This allows Non–Windows 2000 machines to locate network resources. For the domain name sales.az.north-rim.com, use sales for the NetBIOS name. The only situation(s) where unmatched NetBIOS and DNS names should coexist is if there is a plan to migrate to a different naming convention or if the current NetBIOS namespace includes nonstandard DNS characters.

NOTE In previous versions of Windows, the computer is recognized over the network by a NetBIOS name. In Windows 2000, the computer is recognized primarily by its fully qualified domain name (FQDN) in DNS.

• Distinguish domain names from computer names. Adopt a computer naming scheme that is unique to domain names. Avoid naming a server or client “sales” if there is a domain of the same name. Implement server and client names (if they are in the root domain) such as: •

salesdc1.north-rim.com

•

salesdns1.north-rim.com

•

sales<user id>.north-rim.com

Windows 2000 DNS and Active Directory Considerations Although Windows 2000 DNS integrates well with Active Directory, there are some considerations to be regarded in this implementation. First, when installing Active Directory, the first domain (root) plays a critical role because the name of the entire forest is based on its DNS name. Also, this root domain can never be removed from the forest unless it is completely reinstalled (which would impact the entire implementation up to that point). For this reason, it is recommended that you plan the Active Directory implementation thoroughly and design a thorough and aggressive testing and pilot phase. The design strategy for most large companies is to use the first Active Directory domain, storing only domain controller computer accounts. Later in the pilot, computer and user accounts could be migrated to the Active Directory architecture. This process could restrict different departments and groups from creating their own domains and forests.


93

Domain mode is another consideration of Active Directory implementation. A domain can be one of two modes: mixed mode or native mode. In mixed mode, the domain maintains Windows NT 4.0 restrictions such as object limitations (the domain is restricted to 40,000 objects). In mixed mode, the Windows 2000 domain controller functions as a Windows NT 4.0 primary domain controller and is viewed by Windows NT 4.0 backup domain controllers as the primary domain controller. In native mode, Active Directory scales up to millions of objects and overcomes the previous Security Accounts Manager (SAM) constraints. Native mode requires all the domain controllers to be Windows 2000. Although NT 4.0 servers can exist in native mode, they must be configured as member servers. Native mode supports Windows NT 4.0 clients, and allows for the use of Security Universal Groups, which are groups exclusive to native mode. Switching to native mode is irreversible and requires that all domain controllers be upgraded to Windows 2000. By default, Active Directory configures the domain in mixed mode to support migration. The domain should only be migrated to native mode after thorough testing of all applications and services in a test lab running this mode. A final consideration is that Active Directory and its associated domain hierarchy are difficult to restructure after they have been created. For this reason, avoid structuring domains based on a temporary organizational or geographical structure. Although these are the two common domain structure templates for Active Directory, the key is not to use an organizational name if considerable change is imminent (realignment or merger). The same applies to geographical structures where core organizational functionality can reside in multiple locations. For example, a sales group for north-rim.com could reside in Arizona and Illinois. Depending on the size and structure of this organization, it might make more sense to implement an organizational domain structure as opposed to a geographical structure (sales.north-rim.com with subdomains based on geography: il.sales.north-rim.com and az.sales.north-rim.com).

From Microsoft’s perspective, Active Directory should be implemented primarily with Windows 2000 DNS server. Chapter 3, “Active Directory and DNS,” addressed many of the advantages to this approach. However, most current implementations on the Internet and intranets are primarily BIND-based on UNIX-based systems. One consideration is to weigh the features (advantages and disadvantages) of the respected DNS platforms. This assessment will help determine whether a company should consider changing the DNS structure. If the company is looking to implement Active Directory, this decision leans heavily toward at least integrating Windows 2000 DNS in the architecture.


Non–Windows 2000 DNS and Active Directory Considerations

4

94

Because Active Directory requires certain minimum requirements, this process may require upgrading the BIND versions in the current DNS. Another consideration is the political impact of implementing another DNS into the current DNS architecture. Chapter 8 further addresses BIND and Windows 2000 DNS integration.

NOTE If you do not implement the Windows 2000 DNS service, secure dynamic update is not supported and zone database entries cannot have ACLs assigned to them.

Zone Planning Recommendations When planning the partitioning of the DNS namespace into zones, it is important to understand the current network topology and its respective traffic. This includes any existing DNS infrastructure and its replication patterns. Although one purpose of DNS is to reduce broadcast traffic between local subnets, traffic implications are inherent between servers and clients, especially where DNS is used on routed networks. Consider both server-to-server traffic caused by updates and client-to-server query resolution loads over slow links in the network. When planning zones, consider use of cachingonly DNS servers, which do not host DNS zones and provide minimal network impact. Although the limitations of Windows 2000 DNS may seem unreachable, Microsoft has recommended the following limits regarding zones: • No more than 65,553 resource records should exist within zone. • No more than 1,000 zones should exist on any DNS server.

NOTE Zone transfer speeds can be slow between the Windows 2000 DNS service and thirdparty DNS server implementations such as BIND. See Chapter 9, “BIND and Windows 2000 Interoperability” for more information.

Planning a DNS Structure With Active Directory This section focuses on planning the DNS structure with Active Directory using internal and external namespaces. Although the Active Directory architecture and planning is typically a


95

challenging project in itself, this section will help with planning DNS based on that architecture. Depending on the advantages and disadvantages of each option, your Active Directory plan or implementation may need to be reconsidered. These are three basic strategies for implementing Active Directory with DNS: • Implement the AD root domain using the Internet-registered namespace (kevinkocis.com). • Implement the AD root domain as a subdomain of the Internet registered namespace (ad.kevinkocis.com). • Implement the AD root domain using a private, unregistered namespace (kevinkocis.local). If the plan is to implement the AD root domain using the registered namespace, there are minimal DNS changes from a structural standpoint. Because the namespace is already registered for the Internet, no additional name registration is required, and the existing DNS structure, including zones, could remain intact. The drawbacks are that current DNS servers may need to be upgraded to meet the minimum requirements for Active Directory DNS. Windows NT 4.0 and BIND servers would require some upgrading. Windows NT 4.0 servers must be upgraded to at least Service Pack 4 or later (to support SRV records). BIND servers require an upgrade to version 8.1.2 or later. In this scenario, the organization may consider using the DNS name for both its Internet and intranet networks. The challenge to this option is that the namespaces must be separated with a firewall or proxy server, but must still provide internal and external name resolution. Also, the internal DNS server must be configured with a local root, whereas the external DNS server is used for the Internet resolution.

In this situation, the SRV records on the internal DNS server point to resources on the external network while resolution for internal resources is resolved internally. The disadvantage is that two separate sets of resource records must be administered for the external and internal networks.


Implementing this configuration requires separate DNS zones for the internal and external networks (with the same zone name), and the firewall must be configured to determine the accepted internal traffic through the firewall to the Internet. Figure 4.2 illustrates the configuration of this scenario using the kevinkocis.com namespace.

96

.com 3 4

5

ext1.kevinkocis.com

dns1.north-rim.com

External Network Internal Network

2

6 ftp.north-rim.com

dns1.kevinkocis.com

1

7

host1

FIGURE 4.2 Name resolution with the same DNS namespace for Active Directory.

The process for external name resolution is fairly standard. Refer to the example in Figure 4.2, in which a host on the kevinkocis.com internal network (host1.kevinkocis.com) attempts to connect to an FTP server in the north-rim.com domain (ftp.north-rim.com). The resolution process would be as follows: 1.

host1

2.

dns1

sends a query to the internal DNS server (dns1).

forwards the request to the external DNS server (ext1).

3. After reviewing its cache, the external DNS server forwards the query to the TLD requesting an IP address for a .com domain name server. 4. The .com name server replies with the north-rim.com address.


97

5. The external DNS server (ext1) queries north-rim.com for the FTP server information and receives an IP response for the ftp.north-rim.com server. 6. The external DNS server forwards the resolution information to the internal DNS server (dns1), which forwards the information to the client (host1). 7. The client then connects with the FTP server through the firewall. Using a proxy server for external resolution changes the process slightly. Before the request goes to an external DNS server, the proxy server verifies that the client making the request is on the exclusion list. The proxy server also acts as the broker for the query and response.

NOTE Many organizations will opt for (or currently implement) a DNS solution based on the implementation of both a firewall and proxy for security purposes.

If the plan is to implement the AD root as a subdomain of the Internet registered namespace, the organization can maintain its current external DNS namespace (most likely on BIND). This alleviates political issues with BIND proponents and allows for the implementation of Active Directory. This option also enhances security by eliminating the exposure of the Active Directory root domain to the external network. The authoritative DNS server on the Internet can be configured with a delegation record to the Windows 2000 DNS server running Active Directory in a subdomain.

The advantage of this configuration includes separating Active Directory from the Internet while maintaining existing registered DNS domains without updates or significant modification. The disadvantage is that the Active Directory root is not at the SLD level as intended by Microsoft, but this can be outweighed by the advantages of this implementation. If the plan is to implement the AD root domain using a private unregistered namespace, strong considerations regarding the future must be addressed. By implementing a private unregistered domain name, the company is committing itself to NOT having any sort of Internet presence.


For example, if the external root domain for my organization is kevinkocis.com and my Active Directory domain is ad.kevinkocis.com (a subdomain of the external root), the authoritative name server will reside in the kevinkocis.com domain and will be configured with a delegation to the ad.kevinkocis.com. This enables the authoritative name server to “buffer” the Active Directory root domain residing on the internal namespace, as illustrated in Figure 4.3.

98

kevinkocis.com

dns1.kevinkocis.com External Network

de leg ati on

Internal Network

ad.kevinkocis.com

intdns1.ad.kevinkocis.com

FIGURE 4.3 The Active Directory root domain as a subdomain of the external root domain.

For example, if the company is small, currently has no Internet presence, and requires DNS for local resolution only, it can implement the local, private domain name at its root level. In the case of my small company, we would use the kevinkocis.local for the root domain name (as shown in Figure 4.4). This option should only be considered if the company has no registered DNS name or any future plans for an Internet presence. Because Active Directory naming is permanent and requires a complete rebuild of the forest for any name change, this option requires serious consideration. This implementation is definitely not a consideration for any large companies or many small companies as a result of its restrictions, but might serve a purpose in a small research environment or family business.

Small Company DNS Structure A small company DNS architecture where Active Directory has been implemented should be a straightforward process. The DNS namespace should mirror the Active Directory namespace. For a smaller company, even with remote sites, efforts should be made to consolidate into a single domain for both namespaces.


99

External Network Internal Network kevin.kocis.local

dns1.kevinkocis.com

host1

host2

host3

web1.kevinkocis.local

host4

FIGURE 4.4 A private namespace configuration.

Let’s look at an example. North Rim, Inc., is a small ISP based in Phoenix, Arizona, providing local support but planning to set up some remote offices in Illinois and Florida based on demand. North Rim has a registered domain name (north-rim.com), so it elects to use this namespace for its root, and configured the Active Directory root domain as an internal subdomain (as illustrated in Figure 4.3). North Rim, Inc., has maintained a single domain model, so it will continue this initiative, despite expanding their operations.

NOTE A small company that does not want to manage its external DNS can request its ISP to provide this support.


North Rim, Inc., has managed their DNS using BIND 4.9.6, and although it requires minimal administration, they elect to migrate to Windows 2000 DNS for security and redundancy purposes (for more information on this process, see Chapter 9, “BIND and Windows 2000 Interoperability”). For their local configuration, they set up two domain controllers running Windows 2000 DNS, one outside the firewall for Internet access and one inside the firewall for internal resolution. The company also elected to incorporate a proxy server for security and convenience, and plans two DCs for each of their remote sites.

100

Remote Site Considerations For their remote locations, North Rim, Inc., plans for two domain controllers at their remote sites. They plan to configure the DNS services to be caching only, which may provide some outdated information (depending on the settings) but will prove most efficient for DNS purposes. The second domain controller in each of the remote locations allows for redundancy in the event of failure or outage. Because of the anticipated Active Directory network traffic, the company opts to link the remote sites through T1 lines and triangulate for redundancy purposes. Also, North Rim would like to replicate their DNS information on an aggressive schedule, and this bandwidth will allow for this replication load.

Large Company Structure Unfortunately for larger corporations or enterprises, there is no real standard or “cookie cutter” approach. Larger companies that deployed a domain architecture based on Window NT 4.0 domains experienced sub-optimal results due to factors relating to geographical, political, and departmental divisions. There is also a strong chance that BIND DNS is already implemented as the sole DNS within the corporation. As a result, the Windows 2000 DNS upgrade or migration process may confront some challenges. Companies with larger networks also face a greater challenge in planning and designing their zones and replication schedules, particularly if they are planning for Active Directory implementation. Larger companies can also opt for additional domains for various reasons (see the later section “Forest Planning and Integration”), which will incorporate more planning and administration.

NOTE Although some larger companies may inevitably require the configuration of additional root domains (forest), every effort to consolidate under one domain tree should be attempted.

Smaller companies will need to consider and implement certain levels of security, but larger companies are often the targets of malicious hackers because of their proprietary information. Larger companies must implement more stringent security while providing a remote access infrastructure for portable users and systems. Although many larger companies already have this infrastructure in place using BIND, Active Directory and Windows 2000 implementation requires significant cooperation and planning to integrate with these systems. For more information on this integration, see Chapter 9.


101

Remote Site Considerations A simple rule for larger companies with remote sites is to ensure a minimum of two Active Directory domain controllers per location. These domain controllers should be running the DNS service. If the links between the sites are redundant (such as multiple T1s configured for redundancy) and the sites are within the same domain, these remote DNS servers can be configured for caching only. See the Caching-Only Server section later in this chapter for more information on configuration.

Forest Planning and Integration Although efforts to consolidate domains should be strongly considered for long-term efficiency, in some situations a company needs to consider additional domains. Some reasons for creating additional domains are listed here: • To maintain current Windows NT domains—Depending on the number of domains in the organization, this may be a viable option. However, if the company has many remote sites, including remote IT staff that have created dozens or hundreds of Windows NT domains, this is not a valid reason to maintain current domain structure. In that situation, it is better to consolidate as much as possible. In either case, the option must be weighed by researching the additional costs of a multi-domain structure under Active Directory (see the next section “Additional Domain Costs”). • Special Administrative Requirements—Larger companies should make an effort to consolidate and standardize their policies and administration; however, this task is sometimes challenging. Because of politics or special security requirements, more domains may need to be created to meet these administrative and policy requirements (such as no Enterprise Admin access to all domains or different security policies like shorter password intervals for highly restrictive and confidential research groups).

• Additional administrative support (domain and network administrators). • Additional network and server hardware. • Additional trust links for authentication between domains in the forest. • Moving user accounts between domains is a possibility and can impact the user(s) (as opposed to moving these accounts between organizational units (OUs) which is easy and transparent).


Additional Domain Costs Because each domain in an Active Directory requires a significant amount of administrative overhead, the following resource costs and management must be considered before adding more domains:

102

• Group Policy and access control between domains is not currently supported in Active Directory, which reduces uniformity throughout the forest. If the company elects to add more domains, planning for an Active Directory forest requires certain considerations regarding the domain namespace such as these: • Determining the number of domains in each forest • Choosing a forest root domain • Understanding post-deployment domain changes and resulting impact There are some advantages to minimizing the number of trees in your forest. By limiting the number of trees, the number of DNS names by default is lowered. If the organization uses a proxy server, the number of excluded suffixes is also reduced. If the organization uses LDAP hosts that are non-Windows clients, global catalog searches will search the entire domain tree, so limiting the number of trees limits the number of these searches.

Planning the Number of DNS Servers and Their Location When planning DNS servers for an organization, several global assessments and requirements must be gathered to properly plan the number and location of the DNS services. These requirements include the following: • Performing capacity planning and server hardware requirements for new and existing DNS servers. These servers can be BIND, Windows NT 4.0 DNS, Windows 2000, or other DNS systems. The capacity planning applies to all DNS servers. • If a DNS server is multihomed, determining the load requirements and whether it is equipped to handle the associated subnets assigned to each NIC. • Identifying the number of DNS servers and their roles (primary, secondary, and so on). • Identifying the number of zones to be hosted and loaded, as well as the zone file sizes. This factor should only impact memory requirements because the zone files are loaded into memory upon startup. If dynamic updates are a factor, plan on increasing memory requirements. See the next section, “Memory Planning,” for more details. • Identifying the location of the DNS servers based on request and traffic loads, replication and fault tolerance. • Determining the type of DNS or integration (W2K, BIND, or mix/migration). Regardless of company size, if Windows 2000 DNS will be integrated to support Active Directory, plan to install DNS on each domain controller. For each subnet, provide two Windows 2000 Server computers configured as domain controllers that are also running as DNS servers that load and store only Active Directory–integrated zones.


103

Memory Planning With standard implementation, the Windows 2000 DNS server uses system memory as follows: • About 4MB of RAM is used for the DNS service without any zones. • Additional zones require additional memory depending on the size of the zones. • For each resource record in a zone, plan for an additional 100 bytes of memory to be used by the DNS service (although this number varies for the RR type and data content). • Dynamic updates even with scavenging can increase the number of resource records, so plan for a buffer in this situation. For example, if the DNS server hosts a single zone containing around 5,000 resource records, it would require approximately 500KB (kilobytes) of server memory, which is fairly minimal by current Windows 2000 Server memory requirements. Keep in mind that additional zones and dynamic updates will increase this requirement.

Placing DNS Servers For placement purposes, at least one DNS server should be positioned in each Windows 2000 Server site (not domain—refer to Chapter 2, “DNS Server Operations,” for the clarification between sites and domains). A practical guideline is to configure a DNS server for each subnet. Other factors previously mentioned (including network bandwidth and latency) can require the additional DNS servers for the organization. Security is another consideration for placement of DNS servers. Depending on whether the company maintains a firewall, a DNS server may need to be placed outside the firewall to prevent access to the internal name server from the Internet. When deciding where a DNS server is needed when implementing Active Directory in an organization, also consider the following:

• Is there redundancy or an alternative DNS server? • Is the DNS server on a remote subnet? Is there redundancy in the event of unavailability?

Small Company DNS Server Numbers and Placement Even though a small company may be able to implement a single DNS server for a large network area, two DNS servers per zone are recommended for backup and failover. Although DNS can reduce broadcast traffic between local subnets, it does create network traffic in complexly routed LAN or WAN environments. With slower WAN links, this traffic can be an issue. Other factors that can affect the number of DNS servers in a small company


• Will the DNS server computer also serve as a domain controller?

4

104

with remote sites are DHCP lease times and dynamic updates, which increase traffic. For these situations, consider caching-only DNS in the remote locations on a WAN. If the small company is limited to one site with one subnet (and redundancy is not critical), a single Windows 2000 DNS Server can be configured as both the primary and secondary servers for a zone.

Large Company DNS Server Numbers and Placement As mentioned earlier, larger companies with complex networks and remote sites face greater planning and design challenges, particularly if they are planning for Active Directory implementation. In a larger company using a single Active Directory domain, ensure a minimum of two Active Directory domain controllers per location. These domain controllers should be running the DNS service. If the links between the sites are redundant (such as multiple T1s configured for redundancy) and the sites are within the same domain, these remote DNS servers can be configured for caching only. Obviously, if the company implements more domains, more DNS servers may be required for replication purposes. Although only one DNS server per Active Directory forest is required, delegation of authority and reducing network traffic may require additional servers. Adding more DNS servers will also increase security management and delegation. Larger organizations can also be required to use standard primary and secondary zones for political or functional purposes (see the next section for more details).

Enterprise Planning Although the scope of Active Directory implementation is beyond the scope of this chapter, let alone this book, it is important to address some of the high-level issues with planning for Active Directory and Windows 2000 implementation in the enterprise. Some important variables for planning DNS in the enterprise are the following: • DNS servers • WINS servers • SAP/RIP broadcasts • DNS policies (perhaps only servers listed in DNS) • DCHP servers and integration with DNS (if any) • Subnets and supernets • Static and dynamic IP addressing and policies • Remote Access Services (RAS), Virtual Private Networks (VPNs), and other secure dialin methods


105

Although this is quite a list of enterprise considerations, it is by no means comprehensive. Many companies also incorporate service level agreements (SLAs) with their user community to ensure certain levels of response, support, and benefits of their current infrastructure. Implementing Windows 2000 DNS can impact these considerations, so be sure to review these variables with the current DNS team. Because many larger companies already have a BIND DNS infrastructure in place, Active Directory and Windows 2000 implementation requires significant cooperation and planning to integrate with these systems. For more information on this integration, refer to Chapter 9. If the company is smaller or newer to an Internet presence, the planning for Windows 2000 and Active Directory may not involve many of the political and forest issues faced by a larger company.

Domain Convergence and Forest Integration Larger companies with a history of corporate mergers, consolidations, and/or acquisitions may need to consider such factors as domain convergence or forest integration. This scenario is a frequent occurrence in modern times, and integration options including people and systems continue to add challenge to integration efforts. Although the subject of domain integration is beyond this book’s scope, the following list indicates some critical issues that require decisions and defined processes as they impact DNS and Active Directory: • Major operating system (Windows NT, 2000, UNIX BIND) for DNS • The root domain • Directory service and integration • Domain consolidation (what domains will be merged from NT 4.0)

Although this list is not comprehensive, it provides a starting point of topics to address when planning a merger or acquisition.

Installing Windows 2000 DNS Although the basic process of installing Windows 2000 DNS is quite easy, the challenge lies in the planning and documentation process—particularly if the implementation is in conjunction with or following Active Directory. This process should consume over 75% of the actual implementation. The three major ways to install Windows 2000 DNS are as follows: • Installing Active Directory on the first domain controller


• Associated policies and Group Policy Objects

4

106

• Promoting machine to DC (dcpromo) • Configuring DNS Server Wizard The DNS installation process starts the DNS services automatically. It also installs the DNS console (to manage local and remote DNS servers) and adds a shortcut to the DNS console in the Admin Tools menu. When DNS is installed, the registry is updated with the DNS server service subkey under HKLM\System\CurrentControlSet\Servicses\DNS. A folder is also created in the system32 directory structure that contains the following: (for example, kevinkocis.dns)

•

Domain_name.dns

•

z.y.x.w.in-addr.arpa

•

cache.dns

(reverse lookup file)

(contains root servers records from Internet)

• boot (file controlling DNS startup)—Optional because startup parameters are stored in registry

Administrative Requirements Configuring a DNS server that is not running on a domain controller requires that the installer/administrator be a member of the Administrators group for that computer. When configuring a domain controller to be a DNS server, the installer/administrator must be a member of at least one of the groups listed in the access control list (ACL) of the Microsoft DNS container in Active Directory. The following groups are listed with full control in the ACL by default: • DNS Administrators • Domain Administrators • Enterprise Administrators

NOTE If a group in addition to these defaults is configured for the purpose of DNS administration, it must have Full Control permissions to the Microsoft DNS container in Active Directory.

Pre-Installation Before configuring DNS, it is critical to verify that the TCP/IP and DNS client settings for the computer are correct. To verify DNS client settings, perform the following steps:


107

1. Right-click My Network Places, and then click Properties. 2. Right-click the network connection to be configured as the DNS server. Click Properties. 3. Select Internet Protocol (TCP/IP) and then click Properties. 4. On the Internet Protocol (TCP/IP) Properties page, verify a static IP address, a subnet mask, and a default gateway. If a current DNS server exists on the network, enter its IP address in the Preferred DNS server field. An alternate DNS server can also be added in the Alternate DNS server field. 5. If necessary, more alternative DNS servers can be specified by clicking the Advanced button and selecting the DNS tab. 6. In the Advanced properties, configure the hostname and the domain name suffix if necessary.

Setting Up DNS for Active Directory The remainder of this chapter focuses on setting up DNS for Active Directory. Other installations and third-party integration configurations are covered in Chapter 9.

Using the Active Directory Installation Wizard When Windows 2000 Server is first installed and Active Directory is to be installed, the Active Directory Installation Wizard configures the computer as a domain controller, installs Active Directory, and allows the option to install and configure DNS on the machine. The wizard process enables the administrator to create a new domain or to locate the authoritative DNS server for the domain. If another DNS server exists in the domain and is the authoritative DNS server, the new server verifies whether that server accepts dynamic updates. If the other server responds that it accepts dynamic updates, by default the wizard does not install and configure a local DNS server.

With automatic configuration, the new DNS server is configured with the forward lookup zone that will host the locator records and configure the DNS server to accept dynamic updates. In some cases, it also configures the root hints with the names of the root servers (see the section, “Root Hints” for more information).

Promoting to a Domain Controller Another option is to install Windows 2000 DNS when promoting a Windows NT PDC to a Windows 2000 domain controller, or promoting a Windows 2000 member server using the


If no authoritative DNS server is located, or if that DNS server does not support or accept dynamic updates, the administrator is prompted to automatically install and configure a local DNS server.

4

108

command. These processes allow the administrator the option of installing a DNS server and configuring new zones automatically as part of Active Directory installation mentioned in the previous section. DCPROMO

NOTE The zones created during this process are based on the DNS name specified during the process of promoting the server to a domain controller.

Using the Configure DNS Server Wizard In some situations Windows 2000 DNS may need to be manually configured. One such instance is if Active Directory is not going to be installed in the organization, but the preference is to use Windows 2000 DNS. Another instance is if the server is a member server (not a domain controller).

NOTE The Configure DNS Server Wizard allows for configurations other than the default set up by the Active Directory Installation Wizard.

When using the Configure DNS Server Wizard, make sure the DNS server is installed. If not, install it. Also, if this server will not be the root DNS server, configure its network connections to point to another DNS server(s) in your network. To install the DNS server, perform the following steps: 1. Configure the domain name suffix in the Advanced TCP/IP Settings for the computer. 2. In Control Panel, launch Add/Remove Programs, and then select Add/Remove Windows Components. 3. Select Components, and click Next. 4. Select Networking Services, and click Details. 5. Select the Domain Name System (DNS) check box, and click OK. Click Next. 6. After Windows 2000 installs DNS, click Finish. During or following the DNS installation wizard, a forward lookup zone must be configured that is authoritative for locator records that will eventually be added by Netlogon. To configure the Windows 2000 DNS server, perform the following steps:


109

1. Open DNS by clicking Start, Programs, Administrative Tools, DNS. 2. In the console tree, click the DNS server to expand it. 3. Right-click the server name, and select Configure the server from the menu. 4. Follow the directions in the Configure DNS Server Wizard, which guides the administrator through the DNS configuration process. If Active Directory is installed, strongly consider configuring Active Directory–integrated zones. After installing the DNS service, perform the following tasks (as applicable): • Enable dynamic updates on that zone. • Add a delegation to the new forward lookup zone in the parent zone (this does not apply if it is a root zone. • Ensure connectivity between the DNS server and a domain controller. If necessary, the Configure DNS Server Wizard fills in the root hints and creates a root zone in the exact fashion as the Active Directory Installation Wizard. However, it does not create a reverse lookup zone. This process must be performed later, and is covered in Chapter 6, “Administering DNS Servers Using MMC.” When creating an Active Directory domain, some additional configuration is required. To configure the DNS server to support Active Directory, perform the following steps: 1. Ensure that a forward lookup zone is authoritative for the resource records registered by Netlogon. 2. Configure the forward lookup zone to enable dynamic update. 3. Unless this DNS server is a root DNS server, from the parent server, delegate the forward lookup zone to this server.

These are the DNS server configurations for Windows 2000 DNS: • Root Name Server • Standard Primary Name Server • Standard Secondary Name Server • Caching-Only Name Server • Active Directory–Integrated Name Server Let’s take a look at each one in more depth.


Configuring Servers

4

110

Root Name Server Because the root name servers are authoritative for the top-level domains (TLDs), they host the resource records for all the TLD name servers in the domain namespace (such as the .com namespace). Each of the TLD name servers, in turn, hosts the resource records for the SLD name servers (such as kevinkocis.com). Root servers are the beginning of name resolution and the critical path to any resolution because communication on the Internet is impossible without them. Root name servers are listed in a cache file called cache.dns. In BIND this file is called db.cache. This file is also referred to as the root hints file. For a Windows 2000 DNS implementation, configuring a root name server should only be considered if your intranet will not be connected to the Internet, or will connect through a proxy server. As mentioned earlier, smaller companies can allow their ISPs to handle the root domain server and resolution. If a company is not connected to the Internet, there is no need for a cache.dns file on a root name server. To install a root name server, use the DNS Server Configuration Wizard (which automatically launches when you open the DNS console for the first time). This is shown in Figure 4.5.

FIGURE 4.5 Configuring the root name server using the Configure DNS Server Wizard.

These are the two options: • To implement this server as the first DNS server on the network • To configure this server as another DNS server(s) that already exists on the network The wizard then verifies the computer’s TCP/IP settings to see whether it is configured to use any DNS servers. If it locates other DNS servers, the wizard queries for the root servers and


111

sets up the root hints with the of the root DNS server names. This list of names is stored in the cache.dns file for the new server. If the wizard does not locate any root servers, it creates a root zone on the DNS server, making it a root server. After restarting, Netlogon tries to add locator resource records to the DNS server by sending a dynamic update request to the authoritative DNS server so that other computers can locate this new domain controller.

NOTE Smaller and medium-sized businesses may opt for an external ISP to handle the administrative overhead of a root name server, whereas larger companies with a strong Internet presence will maintain a root name server.

Updating Root Hints Be careful that root servers are not created unintentionally by dcpromo.exe or another configuration method. This can result in internal clients failing to reach parent domains or external clients. In the DNS console, check to see whether the “.” zone exists which is indicative of a root server existence. Removal of this root zone may be required to ensure proper name resolution. To configure and use root hints correctly, first verify whether you are using DNS on the Internet or on a private network, and whether the server is designated as a root server. As mentioned earlier, the DNS service implements root hints using a file, cache.dns, stored in the %SystemRoot%\System32\Dns folder. This file should contain the NS and A resource records for the root servers on the Internet.

If the DNS service is being implemented on a private network, this file can be edited or replaced with records pointing to the company’s internal root DNS servers.

Root hints are also required for certain DNS servers on the internal network, such as forwarders which require root hints for the Internet root servers to function and resolve external names. For internal root servers, make sure to delete the cache.dns file on all of your root servers. Should these be required for any reason in the future, they can be collected from external DNS servers, or from configuring a new DNS server on the network.


NOTE

4

112

Primary Name Server The primary name server is an authoritative name server for its domain because it maintains the master copy of the zone database. As mentioned in Chapter 1, in standard DNS, the master copy is the only read/write version of the database file. This file is stored in the %systemroot%\system32\dns folder on the Windows 2000 DNS server. To configure a standard primary zone, perform the following steps: 1. Open DNS by clicking Start, Programs, Administrative Tools, and then DNS. 2. In the console tree, click the DNS server and select New Zone from the Action menu. Click Next. 3. In the Zone Type window, select Standard Primary, and click Next. 4. In the next window, start by configuring a Forward Lookup Zone, and click Next. 5. Enter a zone name on the Zone Name window based on your zone planning documentation. Click Next. 6. On the Zone File page, the administrator can select either Create a New File with This File Name or Use This Existing File. Assuming this is the first zone file, select the Create option, and click Next. 7. On the Completing Installation page, click Finish.

Secondary Name Server The secondary server is also an authoritative name server for its domain because it contains a read-only replica of the zone database. No resource record entry can occur on the secondary name server because it can only “pull” the database file from the primary server (called a zone transfer). For load balancing and redundancy purposes, most organizations will opt to install multiple secondary name servers in addition to their primary name server. To configure a standard secondary zone, perform the following steps: 1. Open DNS by clicking Start, Programs, Administrative Tools, and then DNS. 2. In the console tree, click the DNS server and select New Zone from the Action menu. Click Next. 3. In the Zone Type window, select Standard Secondary, and click Next. 4. In the next window, select Forward Lookup Zone, and click Next. 5. Enter the primary zone name on the Zone Name window, and click Next. 6. On the Master DNS Servers page, the administrator can browse and select the primary name server by name or IP address. After selecting the DNS server hosting the zone file, click Next, and then Finish.


113

7. In the DNS console, verify that the SOA and NS records from the primary have propagated to the new zone file.

Caching-Only Server Caching-only servers are a good option at small remote sites that have a stable and minimal use for DNS name service but are located across a WAN where the transfer of a large zone over a slower link would be too much of an impact to the network. Caching-only servers perform two functions: • Handle and resolve queries • Cache returned queries for a specific time frame

NOTE A caching-only server is not responsible for a specific zone, and performs best when it is configured to use forwarders (using recursive queries).

The process of name resolution involving a caching-only server is as follows (and as illustrated in Figure 4.6): 1. The client queries the caching-only name server. 2. The server first looks through its cache for an entry. If located, it returns a prompt response to the client. If it is not present, the caching-only server queries an authoritative name server. 3. The authoritative name server responds to the caching-only server. 4. The caching-only name server stores the response in its cache for the specified time.

To install a caching-only name server on the network, install the DNS server without configuring any forward or reverse lookup zones. In the event that the administrators decide to use forwarders, perform the following steps for configuration: 1. Open DNS by clicking Start, Programs, Administrative Tools, and then DNS. 2. In the console tree, click the DNS server and select Properties from the Action menu. 3. In the Properties window, select the Forwarders tab. 4. Select the Enable Forwarders box and enter the IP addresses of all the DNS servers to be queried. If desired, enter the forward time-out value, which is the interval before querying the next server in the list. 5. Click OK, and close the Properties window.


5. The caching-only server responds to the client.

4

114

authoritative name server 2 3

caching-only DNS server

1

5

client

FIGURE 4.6 The caching-only server name resolution process.

Active Directory–Integrated Server AD must be installed, or DNS can be installed as part of the AD process, and can also move from standard zone to and AD zone. Depending on the scenario, Active Directory–integrated zones can be implemented in the following ways: • Implementing DNS server on a domain controller not currently running DNS • During a member server promotion to an Active Directory domain controller running DNS • During a conversion from a standard primary zone • During Active Directory implementation (which is unlikely unless this has been tested in a lab for implementation and integration considerations) To implement DNS on a current domain controller, or during Active Directory implementation, select Active Directory–integrated in the Zone Type window as opposed to standard primary or


115

secondary. Remember all domain controllers running Active Directory–integrated zones are considered primary name servers as the zone file is updated and propagated via multi-master replication. To convert from a standard primary zone, perform the following steps: 1. Open DNS by clicking Start, Programs, Administrative Tools, and then DNS. 2. In the console tree, click the DNS server and select Properties from the Action menu. Click Next. 3. In the General tab window, click Change after the type description. 4. In the Change Zone Type window, Select Active Directory–integrated, and click OK. 5. At the warning prompt, click OK.

CAUTION When the directory-integrated zone is created from an existing Standard Primary zone, the zone information is transferred into the AD database and the zone file is deleted from the %systemroot%\system32 directory on the primary name server. You may want to copy this zone file before making this change because it can aid in the integration with third-party DNS such as BIND. This topic is discussed further in Chapter 9.

Verifying the Windows 2000 DNS Installation After the Windows 2000 DNS installation is complete, ensure its success by following the next verification steps:

• Verify the DNS shortcut in Administrative Tools and launch the DNS console • Verify the new DNS registry subkey by launching regedit or rededt32 and looking for the following subkey: HKLM\System\CurrentControlSet\Services\DNS • Verify the DNS folder in the %systemroot%\system32 directory If all these verifications are positive, DNS has been properly installed (not configured) on the Windows 2000 Server.


• Verify the DNS service using the Services console by clicking Start, Programs, Administrative Tools, Services, DNS server

116

Summary This chapter focused on planning issues related to installing Windows 2000 DNS in the enterprise. First, the Internet domain namespace must be registered (if one is not currently in use). Next, you must decide whether you will overlap the internal and external namespace, and how Active Directory will be supported (as root domain or delegated subdomain). Strict naming conventions enforce DNS standards; however, Windows 2000 accepts a wider range of naming conventions and standards to ensure interoperability. There are many considerations when planning to deploy Windows 2000 DNS with Active Directory, especially in larger enterprises, including domain structuring, consolidation, and nomenclature. The number of DNS servers, their roles, and their locations are other planning issues for the enterprise.

CHAPTER

Configuring DHCP and DNS Client Configurations

5

IN THIS CHAPTER • DHCP Server and Client Fundamentals • New for DHCP in Windows 2000

123

• Windows 2000 DHCP Server Planning • BOOTP

118

128

143

• Dynamic DNS Update Configurations • DHCP Leases

145

146

• Configuring Windows 2000 DHCP Server Clients 148 • Predefined Options for DHCP Clients • Summary

151

150

118

In Windows 2000 DNS, DHCP, DNS, and Active Directory can be integrated for greater functionality and ease of administration. This chapter focuses on DHCP configuration and integration with DNS and Active Directory, as well as client configuration.

DHCP Server and Client Fundamentals Each host on a TCP/IP network requires a unique IP address. The Dynamic Host Configuration Protocol (DHCP) reduces the administrative overhead of assigning IP addresses and IP address–related information manually for each system. For example, additional IP address–related information, such as routers, DNS servers, and WINS servers, can also be assigned dynamically to DHCP clients. DHCP is standards-based, and is defined RFCs 2131 and 2132. DHCP is gaining wider acceptance in larger corporations, because it can automatically assign network information for each client logging in to the network. These options include some of the integral options such as these: • Host IP addresses • Subnet masks • Gateways • DNS server IP address Various other values can be assigned (see Table 5.2, later in this chapter, for the predefined list of DHCP options). DHCP stores all available IP addresses in a central database along with these options and other values. In addition to the automation features, the DHCP process also ensures that no IP addresses are duplicated on the network. DHCP provides many benefits, including these: • Standards-based implementation • Dynamic assignment of IP addresses • Automatic assignment of network configurations

DHCP Reservation Process When a DHCP client connects to a network with a DHCP server, and is configured to obtain an IP address automatically, it follows a process that consists of four basic steps. These are the four steps, also illustrated in Figure 5.1: • DHCP Discover • DHCP Offer • DHCP Request • DHCP Acknowledge

Configuring DHCP and DNS Client Configurations CHAPTER 5

119

DHCP Discover DHCP Offer DHCP Request DHCP Client

DHCP Acknowledgement DHCP server

FIGURE 5.1 The DHCP reservation process.

In the Discover phase, the DHCP client queries for an IP address. In the Offer phase, the DHCP server offers an address from its pool of IP addresses. In the Request phase, the client accepts the offer and requests the address. In the Acknowledge phase, the DHCP server officially assigns the client the IP address, and additional options may be assigned. These four steps are initiated automatically when the computer logs on to the network, and are almost instantaneous. After the client is configured, the DHCP server places a lease time on the address, which is based on the lease time setting in the DHCP options window. Halfway through the lease period, the DHCP client requests a lease renewal, and the DHCP server extends the lease. This means that when a machine stops using its assigned IP address on the network (such as a laptop user on vacation), the lease expires and the address is returned to the server’s pool, and it is available for reassignment to another DHCP client.

DHCP Clients In Windows 2000 DHCP, the following operating systems can be DHCP clients: • Windows 2000 Professional • Windows 2000 Server • Windows NT Workstation • Windows NT Server • Windows 98 • Windows 95 • Windows for Workgroups version 3.11 (with the Microsoft 32-bit TCP/IP VxD installed)

• LAN Manager version 2.2c • Macintosh computers

5 CONFIGURING DHCP AND DNS

• Microsoft Network Client version 3.0 for the Microsoft MS-DOS operating system (with the real-mode TCP/IP driver installed)

120

• UNIX workstations • Network printers and print servers

DHCP Server Terminology Using the DHCP Manager, administrators can configure and monitor DHCP servers, which have several components that can be configured based on the organization’s DHCP requirements. These components include the following: • Scopes • Exclusion lists or ranges • Address pools • Leases • Reservations • Options (global and scope-based) • Superscopes

DHCP Scopes A DHCP scope is required before DHCP clients can use the DHCP server for dynamic TCP/IP configuration. The scope is a range of possible IP addresses available for a particular subnet. The scope defines a logical subnet for DHCP services, and lets the server identify configuration parameters for all DHCP clients on that subnet. Scopes consist of exclusion ranges and address pools.

Exclusion Ranges An exclusion range is an IP address collection that is omitted from the available address pool. These IP addresses are not available to DHCP clients even though they are part of the DHCP scope. In many instances, these addresses are used for static assignment to servers, printers, or business-critical workstations.

Address Pools The set of IP addresses remaining after the scope is defined and exclusion ranges are applied is considered the address pool within the scope. These addresses are available for lease to DHCP clients on the network.

Leases A lease is the duration specified by a DHCP server that a client computer is able to use an assigned IP address. A lease is considered active after the client is officially assigned the address from the DHCP server. When the lease is halfway up (for example, 5 days on a 10-day


121

lease time), the client must renew its lease with the server. If the client doesn’t renew before the end of the lease, the lease is terminated and the IP address returns to the address pool.

Reservations Reservations are permanent lease assignments offered by the DHCP server which ensure that certain devices will always use the same IP address. Reservations are a form of static assignment in the context of DHCP, as the MAC address of the client is logged in the DHCP database. These IP addresses are not available to DHCP clients even though they are part of the DHCP scope. They are also omitted from the address pool. Let’s take a look at how these DHCP components come together to form the scope. First the scope and subnet mask are created. Next exclusion ranges are created for static IP nodes, and reservations are made for other nodes (such as printers). Finally the DHCP address pool is left for dynamic IP assignment. Table 5.1 illustrates a possible DHCP scope for a Class C subnet (192.168.1.x). TABLE 5.1 A Class C DHCP Scope with Exclusion Ranges, Address Pools, and Reservations IP Address Range

Configuration

192.168.1.1–192.168.1.20 192.168.1.21–192.168.1.40 192.168.1.41–192.168.1.220 192.168.1.221–192.168.1.240 192.168.1.241–192.168.1.254

Exclusion range for servers Reservations for printers DHCP address pool (180 IPs) Exclusion range for engineering workstations Exclusion range for network equipment

DHCP Options After the scope is completed, DHCP options apply various parameters that a DHCP server extends to the client in addition to IP addresses. For example, a client can receive router (default gateway) information, as well as WINS and DNS server information. These options can be managed at four assignment levels: • Server–Applies to all scopes on the DHCP server (also considered a global option). These values can be overridden by different values set at the scope, options class, or reserved client levels.

• Class–Applies to a specific class (operating systems, such as Windows 9x, NT, or 2000). These options override values assigned and set at the same context (either server, scope, or client options) or inherit values from other higher-class options.


• Scope–Applies only to a single subnet scope. These values can be overridden by different values set at the options class or reserved client levels.

122

• Client–applies to servers or a specified client (such as a high-processing workstation) that is issued IP address reservation (not lease) from the DHCP. These options can be overridden only by properties manually configured at the client computer.

NOTE Typically options are referred to as global- or scope-based. Class and client options are typically rare or non-existent.

DHCP options fall into three basic categories: • Standard options–contained in RFC 1497 • Extended options–contained in RFCs up to 2132 • Microsoft-based options–include options for WINS and other Microsoft proprietary features.

Superscopes An administrative feature included within the Microsoft DHCP Manager tool can be used to create various distinct scopes, which are grouped together into a single administrative entity called a superscope. A superscope is a collection of individual scopes managed as a single administrative unit, providing the following benefits: • Offer the capability to place DHCP clients from multiple networks on the same physical segment • Allow remote DCHP clients from multiple network IDs to obtain an IP address from the DHCP server • Allow multiple DHCP servers to reside on the same physical segment, while each manages its respective scope

NOTE Support for superscopes is available in Windows NT 4.0 Service Pack 2 and later.

For example, a DHCP server can be configured with multiple scopes if it resides in a multinet environment (a network with multiple subnets). Say that the network addresses are 192.168.1.x


123

and 192.168.2.x. The IP ranges could be 192.168.1.1-254 and 192.168.2.1-254. Because the DHCP server has a single interface (192.168.1.2), it will respond to DHCP requests on the local network (192.168.1.x) and any DHCPRequest messages from 192.168.2.x that are forwarded through a BOOTP Relay. For remote requests, the DHCP server verifies whether the request is from its local network. If it is not (such as in this example), the DHCP server checks whether it has a superscope that includes an address pool for the remote network.

CAUTION Multiple IP addesses assigned to the DHCP server’s interface will not provide this level of functionality. The DHCP server will use only its primary address for DHCP assessments even if multiple IP addresses are bound to the same adapter.

New for DHCP in Windows 2000 Microsoft Windows 2000 Server DHCP has been enhanced to make DHCP easier to deploy and manage. New features include the following: • Integration of DHCP with DNS • Enhanced monitoring and statistical reporting for DHCP servers • New DHCP vendor-specific and class ID option support • Multicast address allocation • Rogue DHCP Server detection • Windows Clustering • Improved DHCP Manager • Automatic client configuration Because of the scope of this chapter, not all of these features will be addressed. For more information on Windows 2000 DHCP, refer to the white papers at the Microsoft Web site.

NOTE


Microsoft recommends upgrading NT 4.0 primary and backup domain controllers to Windows 2000 and Active Directory before implementing Windows 2000 DHCP.

124

DHCP and DNS Integration DNS servers are closely related to DHCP services in Windows 2000. For Windows 2000, DHCP servers and DHCP clients may be configured to dynamically register with DNS. This is advantageous if the organization wants to maintain all systems in DNS. As mentioned earlier in the book, not all organizations may opt to include all systems in DNS. The standards for managing DHCP and DNS interactions are still in development by the IETF. The process of integrating dynamic DNS and DHCP services is still in draft proposal. Microsoft is reviewing how to implement DHCP/DNS integration for Windows 2000 Server based on the specifications of the proposed implementation of DHCP and DNS interaction as described in a draft document (draft-ietf-dhc-dhcp-dns-08.txt). This document describes how DHCP clients and servers should use the dynamic DNS updates (referenced in RFC 2136) to update pointer (PTR) and address (A) resource records on behalf of its DHCP-enabled clients. It also specifies how to assign an additional DHCP option code (option code 81) that enables the client to return its FQDN to the DHCP server, and eventually to the DNS server using dynamic DNS to modify the resource records.

NOTE This document is still a draft; the final supported implementation may vary from Microsoft’s current implementation.

The Windows 2000 DHCP server can differentiate between Windows 2000 clients and pre–Windows 2000 clients, and therefore is capable of acting as a proxy for the legacy clients for the purpose of dynamic DNS registration. This option permits the DHCP server to perform the following proxy interactions on behalf of DHCP clients: • Always register forward (A) and reverse lookups (PTR) records with DNS. • Never register forward (A) records with DNS. • Register both forward (A) and reverse lookups (PTR) records with DNS per the client’s request.

CAUTION DHCP and static DNS service are not well-suited for synchronizing and maintaining name-to-address mapping. Some problems may therefore result when DHCP and DNS are being used if the DNS servers are static and incapable of interacting dynamically when DHCP client configurations change.


125

If the organization has static DNS servers deployed, there are some options to avoid DNS errors: • Upgrading or replacing the static DNS servers with DNS servers supporting dynamic DNS service. This includes later versions of BIND (8.1.2 and later), as well as Windows 2000 DNS. • Enabling WINS lookup for DHCP clients that use NetBIOS. • Assigning IP address reservations with an unlimited lease duration for DHCP clients that use only DNS and do not support NetBIOS.

NOTE Windows 2000 DHCP service does not have a strong integration to Active Directory as does Windows 2000 DNS, but it still requires authorization in Active Directory.

DHCP Server Monitoring Enhancements Windows 2000 DHCP has some new enhanced monitoring and statistical reporting, including alert thresholds and new performance monitor values. The DHCP Manager, shown in Figure 5.2 (the MMC plug-in), supports Simple Network Management Protocol (SNMP) and Management Information Bases (MIBs) to help administrators graphically monitor system status. These graphical displays can then be displayed through an intranet web page for easier support.

User Class Support Most DHCP clients on a subnet receive identical IP configuration information from the DHCP server, regardless of their platform (laptop, desktop, or engineering workstation). Because the DHCP server cannot recognize the difference in these clients, the configuration sent out by the server is the same for all DHCP clients. The user class functionality allows DHCP clients to receive different IP-related information based on their client type or platform. For example, laptops could be assigned shorter lease times for their IP addresses, whereas engineering workstations could be assigned longer leases. Also, laptops could be configured to not update themselves in DNS.


Although these are just a few of the user class options available in Windows 2000 DHCP, this feature undoubtedly provides administrators with greater flexibility in client configuration.

126

FIGURE 5.2 The DHCP Manager.

Vendor Class Support Similar to user class options, vendor class options identify the client’s vendor type (as opposed to user type) when obtaining a lease. The vendor class identifier is a character string interpreted by the DHCP server. For example, the identifier might encode the client’s hardware configuration. Most vendor types for hardware and software (operating system–type) and their respective abbreviation codes are listed in RFC 1700. For most situations using vendor class, Windows 2000 DHCP provides a default vendor class for Microsoft DHCP clients or other DHCP clients lacking a specific vendor class ID. Additional vendor classes for other DHCP clients, such as printers or UNIX clients, may be required. When performing this process, make sure that the vendor class ID matches the identifier used by clients for the third-party vendor.

NOTE Windows 2000 DHCP default settings are assigned if no class options are used.


127

Multicast Address Allocation The Microsoft DHCP server also allows multicast address assignment, in addition to unicast addresses. The proposed IETF standard allows multicast addresses to be assigned in the same fashion as unicast addresses, allowing complete utilization of the existing infrastructure. Multicasts are typically implemented for video and/or audio conferencing, in which groups of computers (based on IP) receive a video or audio feed. This differs from IP broadcasts, in which all computers on the network receive the transmitted information.

Unauthorized DHCP Server Detection The Windows 2000 DHCP server can prevent unauthorized DHCP servers from creating conflicts with IP address assignment. When deployed with Active Directory, the directory database stores information on the authorized DHCP servers. A Windows 2000 DHCP server attempting to initialize on the network sends a DHCPInform packet to the other DHCP servers on the network requesting the domain name. Upon receiving the domain name, the DHCP server will contact the nearest domain controller to determine its own authorization status. If the DHCP server has been authorized, the DHCP server service will start and the DHCP server will respond to clients. If the DHCP server is not authorized in AD, the DHCP server service will fail to start and an error will be logged in the event viewer system log. If the DHCP server does not get a domain name returned to it, it will initialize properly and respond to clients. The DHCP server will continue to contact AD every five minutes to determine whether its authorization status has changed.

NOTE The list of authorized servers can be created in the Active Directory through the DHCP snap-in.

Automatic Client Configuration For organizations hosting a smaller private network, a feature of the Windows 2000 DHCP client is the automatic configuration of an IP address and subnet mask when no DHCP server exists to assign addresses. This feature is called Automatic Private IP Addressing (APIPA).

For Windows 2000–based platforms, if the first attempt to locate a DHCP server fails, the DHCP client configures itself with a selected IP address.


This process is performed in two basic steps. Because the Windows 2000 DHCP client service starts at boot-up, it immediately tries to find a DHCP server for an IP configuration.

128

If the DHCP client has previously obtained a lease from the DHCP server, the client tries to renew any unexpired lease with the DHCP server. If the client fails to locate any DHCP server, it attempts to ping the default gateway listed in the lease. If this succeeds, the client assumes that it has not been moved and uses that lease. The client then seeks to automatically renew the lease when half of the lease time has expired. If the attempt to ping the default gateway fails, the client assumes that it has been moved to a network that has no DHCP services currently available, such as a home network, and it configures itself. It then automatically keeps trying to find a DHCP server every five minutes.

Windows 2000 DHCP Server Planning Several factors are involved in planning a Windows 2000 DHCP implementation. These factors range from administration and permissions to configuration and fault tolerance. This section evaluates these variables in greater detail.

Permissions To connect to a DHCP server for administrative purposes, the user must be a member of one of the following groups: • DHCP Users • DHCP Administrators • Administrators (Enterprise Administrators, Domain Administrators, and so on) Members of the DHCP Users group are allowed to view DHCP server configurations (such as current leases and specifications) but cannot modify any values. The permissions for this group are read-only for the DHCP server, which may help in the event of troubleshooting (such as in a help-desk scenario). Members of the DHCP Administrators and Administrators groups can view and modify the DHCP server’s configuration. The DHCP Administrators group allows administrative access to the DHCP server only, while restricting full access to the server computer. Members of this group can administer and modify DHCP services without having access to perform other administrative tasks on the server. If Active Directory is implemented, a DHCP server requires authorization before it can respond to DHCP clients. If the DHCP server is also operating as a domain controller, the server is automatically authorized when the server is added to the DHCP console. To add a DHCP server as a member server, the user must be logged on as a member of the Enterprise Administrators group for the enterprise hosting the server.


129

For more information on the authorization and permissions administrative process, see the section “Authorization and Permissions,” later in this chapter.

Windows 2000 DHCP Server Deployment DHCP has become such an important element of efficient network design that network administrators want to ensure proper DHCP deployment. Basic considerations of DHCP deployment include the following: • Determining the number of DHCP servers needed • Installing the DHCP server • Determining and configuring scopes • Determining DHCP options • Reserving IP addresses (if necessary) • Configuring superscopes (if necessary)

Determining the Number of DHCP Servers Needed In a small LAN, such as one physical subnet without routers, a single DHCP server can handle the client load. However, routed networks may require several DHCP servers. In most local subnets, only two DHCP servers are required—a single DHCP server and a backup DHCP server. Depending on its hardware configuration (such as CPU speed and disk capacity), a single DHCP server can support a large number of clients. For diversified networks, the location of routers, the network throughput, and the need for a local DHCP server are factors to be considered. If the subnets are connected with a high-speed WAN link, these are not big factors. For slower WAN or dial-up links, a minimum of one DHCP server is recommended for each side of the slow links for local support.

NOTE Depending on the IP network class (A, B, or C), the network will have practical size constraints, such as the 254-node limit of Class C networks.

Before installing and configuring the DHCP server, you need to identify the following factors:

• Static and dynamic IP clients • The DHCP option types and their values (such as subnet mask, default gateway, WINS servers, and lease time frames) • DHCP relay agent (if necessary)


• Hardware and storage requirements

130

Fault-Tolerant Planning Planning for fault tolerance will depend on various factors. In most environments, it is relatively easy to install DHCP on another server. Depending on the factors mentioned in the preceding section, the organization may need to consider additional fault-tolerant planning. Microsoft supports the initiative of splitting a scope between two or three servers. From their standpoint the DHCP traffic flow is minimized, and it eliminates errors that may result if a DHCP server experiences an outage. However, simply increasing DHCP lease times or having a spare server is usually more than sufficient for most organizations.

Installing the DHCP Server After the planning stage is complete, and the organization is ready to install and configure the DHCP server, begin by performing the following steps: 1. Open the Windows Components Wizard by clicking Start, Settings, Control Panel, Add/Remove Software and selecting Add/Remove Windows Components. 2. Under Components, scroll to and click Networking Services, and click Details. 3. In the list of Subcomponents under Networking Services, click Dynamic Host Configuration Protocol (DHCP), and then click OK. 4. If necessary, enter the path to the Windows 2000 Server CD or distribution files, and click Continue. After the DHCP server has been installed, verify its success by launching DHCP (click Start, Programs, Administrative Tools, and then click DHCP). In the DHCP console, click DHCP, and then select Add Server from the Action menu. In the next window, select either this server or another authorized DHCP server to which to connect. If for any reason the DHCP server needs to be stopped, paused, or started, perform the following steps: 1. Open DHCP Manager and select the DHCP server. 2. In the Action menu, select All Tasks and then click the appropriate task from the expanding menu (Start, Stop, Pause, or Restart). If the service has been paused or stopped, the Resume option appears in the expanded menu and can be selected. You can also perform these tasks from a local command prompt by using the following syntax: •

net start dhcpserver

•

net stop dhcpserver

•

net pause dhcpserver

•

net continue dhcpserver


131

Authorization and Permissions To authorize a DHCP server that is not a domain controller in Active Directory, perform the following steps: 1. Open the DHCP Manager, and right-click on DHCP. 2. Select Manage Authorized Servers from the menu (also located under the Action menu). 3. In the Manage Authorized Servers dialog box, click Authorize. 4. Enter the name or IP address of the DHCP server, and then click OK. For remote or distributed sites, it may be advantageous to delegate the responsibility of authorizing DHCP servers to users who are not members of the DHCP Administrators or Administrators groups. To delegate the ability to authorize DHCP servers to a non-enterprise administrator, perform the following steps: 1. As Enterprise Administrator, open Active Directory Sites and Services. 2. On the View menu, click Show Services Node. 3. In the console tree, open Services, then NetServices. 4. On the Action menu, click Delegate Control (which launches the Delegation of Control Wizard). 5. At the wizard window, click Next; then for Users and Groups, click Add. 6. In Select Users, Computers, or Groups, locate and select the user or group account you want to permit access to the NetServices object for authorizing DHCP servers. Figure 5.3 shows the added user.

5

The selected user for delegation of control for DHCP.

CONFIGURING DHCP AND DNS

FIGURE 5.3

132

7. Click Add and then OK; then click Next. 8. For the Delegate Control Of option, select This Folder, Existing Objects in This Folder, and Creation of New Objects in This Folder (shown in Figure 5.4), and then click Next.

FIGURE 5.4 The delegation assignment window.

9. For Permissions, click Full Control (which automatically selects all the Permissions in the window), and then click Next. After this process, the user or group can add, modify, or delete DHCP objects, including scopes, reservations, and so on. To add a user or group to the DHCP Users group at a domain controller, perform the following steps: 1. On a domain controller, open Active Directory Users and Computers (Start, Programs, Administrative Tools). 2. In the console tree, select the domain and expand the Users container. 3. Right-click DHCP Users and select Properties. 4. Select the Members tab, and then click Add. 5. Click Look In to display the domain list, and select the appropriate domain containing the users and computers to be added. 6. Select the users and computers to be added, and then click Add. The process for adding these permissions on a member server is different, because the member server will use a local management console as opposed to Active Directory Users and Computers. To add a user or group to the DHCP Users group at a member server, perform the following steps:


133

1. Open Computer Management if the DHCP server is installed as a domain member server (or a standalone workgroup server). 2. In the console window, expand System Tools, then Local Users and Groups. 3. Right-click DHCP Users, and select Properties. 4. Click the Members tab, and then click Add. 5. Click Look In to display the domain list, and select the appropriate domain containing the users and computers to be added. 6. Click the users and computers to be added, and then click Add.

NOTE To add a user or group as a DHCP administrator at a member server or domain controller, select DHCP Administrators instead of DHCP Users in the preceding sets of instructions.

Determining and Configuring Scopes As mentioned earlier, the DHCP scope is required before clients can use the DHCP server for dynamic TCP/IP configuration. A scope is created for each physical subnet, and its parameters are determined by the subnet’s hosts. In determining the parameters for scopes, the administrator must consider the following: • The range of IP addresses available for lease, for reservations, and for static assignment. Some organizations implement standards for IP ranges. For example, on a class C subnet, they might assign static addresses for server hosts x.y.z.1 to x.y.z.20, then use printer reservations for x.y.z.21 to x.y.z.30, and then assign the DHCP address pool from 31 to 200, leaving several static addresses available for networking equipment. • A unique subnet mask to determine the subnet related to a given IP address. • A scope name. • Lease duration values, considering shorter leases for mobile computers. The default lease duration is three days. • Reservations for printers or other workstation hosts.

After a scope has been defined and fully configured, as outlined previously, it must be activated before dynamic service begins for DHCP-enabled clients. After a scope is active, the server can begin processing IP lease requests and offering IP leases to DHCP-enabled clients on the network.


• Options.

134

CAUTION Although the scope’s address range can be extended, it cannot be reduced. Administrators can still selectively exclude single IP addresses from the scope at any time.

To create a new scope, perform the following steps: 1. Open the DHCP Manager. 2. Right-click on the DHCP server, and select New Scope. 3. After the New Scope Wizard launches, click Next. 4. Enter the scope name and description, and click Next. 5. Enter the Start and End IP addresses, and then click Next. (The subnet mask will be entered automatically based on the class.) Double-check the mask to make sure that it is correct for your environment, because it cannot be changed after you click Finish. 6. Add any exclusions, and click Next. 7. Enter the lease duration (the default is 8 days), and click Next. 8. The wizard then allows the administrator to configure DHCP options either now or later. These options include the router (default gateway), the domain name and DNS servers, and WINS servers. Click No to configure later. Note that you cannot activate the scope until these options have been set. 9. After the scope is configured, select Yes, I Want to Activate This Scope Now to activate the scope. 10. Click Finish. After a new scope is created, it must be activated in order to set options or be available for lease distribution (this is achieved in step 9 of the preceding list). If the scope is not active, DHCP clients will not be able to obtain client leases. However, all DHCP options must be set before the scope is activated, because deactivating a scope is not a preferred option to resolve missed information (see the following information on deactivating the scope). To activate the scope, select the scope and then select Activate from the Action menu. After the scope is active, the Activate option in the Action menu defaults to Deactivate. To change or view scope properties, in the DHCP console select the Action menu, and click Properties.


135

CAUTION Be careful when deactivating a scope because this process initiates a recall of scope addresses and is typically used when retiring a scope or removing it from the DHCP server. Do not use Deactivate to pause the scope.

To deactivate a scope, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Right-click the scope, and click Deactivate. The subsequent process would not be to reactivate the scope, but to remove it from the server. To remove a scope, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Right-click the applicable scope, and click Delete. 3. When prompted, click Yes to delete the scope.

CAUTION Before removing a scope, make sure that all clients have moved to a different scope.

Configuring Scope Exclusion Ranges As mentioned earlier in the chapter, an exclusion range is a set of IP addresses that are omitted from the available address pool and are not available to DHCP clients. These addresses are typically used for static assignments to servers, printers, or business-critical workstations. After planning and configuring the scope, you next must configure the scope’s exclusion ranges. To exclude an address or an address range from a scope, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Expand the applicable scope, and click Address Pool. 3. Select New Exclusion Range from the Action menu.

5. Click Add.


4. In the Add Exclusion dialog box, type the IP address to be excluded from this scope in the Start IP field. To exclude a range of IP addresses, enter the End IP address as well.

136

NOTE A range that includes an active DHCP lease cannot be excluded from a range of addresses. The lease must be terminated before the exclusion.

In the event that certain scope properties need to be reconfigured (such as the exclusion ranges, client reservations, lease times, or option type values), these changes can be made through the Properties options after right-clicking on the scope in the DHCP Manager. Reconciling Scopes Reconciling scopes can fix inconsistencies, such as incorrect or missing information for client IP addresses that are stored in scope lease information. When inconsistencies are found, the DHCP server can use duplicate scope address lease information recorded in the Windows 2000 registry to detect any lease entries not currently reflected in the DHCP server database. To correct and repair these inconsistencies, you need to reconcile any scope inconsistencies found when performing this operation. After you select and reconcile scope inconsistencies, the DHCP console either restores those IP addresses to the original owner or creates a temporary reservation for those addresses. These reservations are valid for the lease time assigned to the scope. When the lease time expires, the addresses are recovered for future use. The Reconcile feature can also be used to restore DHCP scope data in the event of server recovery. Before using this feature to fully recover DHCP scopes, you should perform the following tasks on the server: 1. Back up and verify the DHCP database (see the section “Backing Up the DHCP Database”). 2. Stop the DHCP server (per the directions earlier in the chapter). 3. Delete all files in the currently set Database path, which can be viewed or set from the Advanced tab in Properties at the applicable DHCP server. 4. All DHCP server registry keys must either be restored or exist and remain intact from previous service operation on the server computer. If you are not sure how to make a copy of the DHCP server registry keys, refer to the procedures for using Registry Editor (Regedt32.exe) to do so in Moving a DHCP database to another server. 5. Regenerate a fresh version of the DHCP server database file in the current Database path, such as the SystemRoot\System32\Dhcp folder, on the server computer. A fresh copy of the DHCP server database can be generated by: • Stopping the DHCP server


137

• Deleting all the DHCP database files in the current Database path folder • Restarting the DHCP server

NOTE When deleting server database files, it is not necessary to delete the \backup subfolder as well unless you are deliberately choosing not to have the server restore from one of its previous backup copies archived there.

When the DHCP server registry information and DHCP database files have been either restored or regenerated at the server and the server restarted, you might notice that upon opening the DHCP console, scope information is present but no active leases or other information for scopes is displayed. To regain your active leases for each scope, you must use either the Reconcile feature to recover each scope or the Reconcile All Scopes feature at the DHCP server. If the reconcile scope option is used, the procedure needs to be repeated for each scope defined and used at the server. After reconciliation is completed, scope client lease and reservation information is added back into the Active Leases for each scope, based on DHCP scope registry information previously stored at the server computer. After the Reconcile feature has been used, client lease information may be displayed incorrectly in the DHCP Manager. However, as clients renew their leases, the information will be corrected and updated.

CAUTION The Reconcile feature can recover scope information in the event of DHCP server inconsistencies, but it is not intended as a replacement for long-established backup procedures.

To reconcile a scope, perform the following steps: 1. In DHCP Manager, select the DHCP server.

5

2. Right-click the applicable scope, and click Reconcile.


3. In the Reconcile dialog box, click Verify. Inconsistencies found are reported in the status window.

138

4. If the scope is found to be consistent, click OK. If the scope is not consistent, select the displayed addresses that need to be reconciled, and click Reconcile to repair inconsistencies.

Determining and Configuring DHCP Options Before configuring DHCP options, be sure to follow some of the best practices to ensure successful DHCP implementation. The following guidelines can assist with determining which options level to assign for DHCP clients: • Add or define new custom option types only if you have new software or applications that require a nonstandard DHCP option. • If your DHCP server manages many scopes for a large network, be selective when assigning Server Options. These options apply by default to all clients of a DHCP server computer, unless otherwise overridden. • Use Scope Options for assigning most options that clients use. In most networks, this level is typically preferred for assigning and enabling the use of DHCP options. • Use Class Options if you have a mixture of DHCP clients with diverse needs that are able to identify a specific class on the DHCP server when obtaining a lease. For example, if you have a limited number of client computers running Windows 2000 DHCP clients, these clients can be configured to receive vendor-specific options that other clients do not use. • Use Client Options for individual DHCP clients in your network that have special configuration requirements. For any hosts (that is, computers or other networked devices) that do not support DHCP or are not recommended to use it, you can also consider excluding IP addresses for those computers and devices and manually setting the IP address configuration directly at the applicable host. For example, you often need to statically configure the IP address for routers. Common DHCP Options After you set basic TCP/IP configuration settings (such as IP address, subnet mask, and default gateway) for clients, most clients also need the DHCP server to provide other information through DHCP options. The most common options (and the options configured in the wizard) include the following: • Router (such as a default gateway) • DNS servers • DNS domain—for resolving unqualified names during DNS domain name resolution • WINS server and WINS node type (Microsoft-proprietary)—for WINS and NetBIOS name resolution, if necessary


139

To assign a server-based option, perform the following steps: 1. In DHCP Manager, expand the DHCP server container. 2. Right-click on Server Options, and select Configure Options. 3. In the list of Available Options, select the check box for the first option to configure. 4. Under Data entry, enter any information required for this option. 5. Repeat the two preceding steps for any additional server options, and then click OK. 6. If necessary, select the Advanced tab to specify additional server options for specified members of select user or vendor classes (such as Windows 98 machines, as shown in Figure 5.5).

FIGURE 5.5 Selecting advanced options for Windows 98 machines.

To assign a scope-based option, select the scope as opposed to the server, and follow the preceding steps. The same process applies for configuring class-based options in the Advanced tab. To create a new user or vendor class, perform the following steps: 1. In DHCP Manager, right-click the DHCP server. 2. From the menu, select one of the following: • For a new vendor class, click Define Vendor Classes. 3. Click Add. 4. In New Class, enter the required information.


• For a new user class, click Define User Classes.

140

To define a new option, perform the following steps: 1. In DHCP Manager, right-click the DHCP server. 2. From the menu, select Set Predefined Options. 3. In Predefined Options and Values, click Add. 4. In Option Type, type the required information to define the new option, and then click OK (as shown in Figure 5.6).

FIGURE 5.6 Customizing new option information.

To modify an option, select the class or option in the Predefined Options and Values window, and click Edit. This process modifies only the Name and Description fields. To change other fields (such as Data type, Code, or the class), the existing option must be removed and re-created. To remove an option, follow the same steps but select Delete instead of Edit.

Reserving IP Address Options DHCP Manager allows the reservation of a specific IP address for a computer or other IP addressable device on the network. Reserving selected IP addresses for special-function devices on the network ensures that DHCP does not duplicate or reassign the address. Reservations can be useful for the following types of devices and computers: • Other Windows NT Server–based computers on the network that require static IP addresses, such as WINS servers. • Any print servers that use TCP/IP print services. • UNIX or other clients that use IP addresses assigned by another TCP/IP configuration method. • Any DNS servers on the network, whether running Windows NT or not. Each reservation requires a unique identifier to reserve an IP address. This unique identifier is the physical address of the network adapter, also known as the Media Access Control (MAC) or burned in address (BIA). The DHCP server will check for the address entered for the


141

reservation to ensure that the address is not in use on another client. For an Ethernet connection, the address is a unique hexadecimal address that identifies the network adapter. To obtain MAC addresses on Windows 2000 and NT–based clients, type ipconfig /all at the command prompt and view the Physical Address field. For Windows 9x–based clients, run Winipcfg.exe, and view the Adapter Address field. To add a client reservation, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Expand the scope, and right-click Reservations. 3. Select New Reservation. 4. In New Reservation, type the information required to complete the client reservation. 5. In Supported types, the default is Both. For DHCP- or BOOTP-specific options, select the applicable option. 6. To add the client reservation to the scope, click Add (as shown in Figure 5.7). 7. Repeat the two preceding steps for additional reservations, and then click Close.

FIGURE 5.7 Reserving an IP address for a color printer. Note that the reservation still requires a MAC address before it can be completed.

To change information for a reserved client, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Expand the scope and select Reservations.

5

3. Select the reserved client, and document any current reservation for future reference.


4. Right-click the reserved client, and click Delete. 5. Add a new reservation (based on the previous process), combining old information with the new information.

142

NOTE After reservations are made they cannot be modified. To change information (including the IP address) for an existing client reservation, you must delete and re-create it.

To assign an option to a reserved client, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Expand the scope and select Reservations. 3. In the details pane, right-click the reserved client, and click Configure Options. 4. In the list of Available Options, select the check box for the first option. 5. Under Data entry, enter the required information. 6. Repeat steps 4 and 5 for any other reserved client options you want to specify, and click OK.

NOTE You can configure advanced options for a reserved client by clicking the Advanced tab, selecting either Vendor or User Class, and configuring the new options following the previous example.

Configuring Superscopes Superscopes can resolve several different DHCP service issues by allowing Microsoft DHCP servers to support DHCP clients in multiple logical IP subnets on a single physical network segment. Superscopes also support remote DHCP clients located on the other side of BOOTP/DHCP relay agents. As of Windows NT 4.0 Service Pack 2, the DHCP server versions can dynamically assign IP addresses from more than one scope to a physical subnet. Situations for which superscopes are useful include the following: • Unplanned hosts are added to the network (such as a local merger of consolidation). • The IP addressing scheme is changed (such as a migration to a new scope). • Two local DHCP servers manage separate logical subnets on the same physical subnet. Before a superscope can be created, all the local scopes planned for the superscope need to be defined in DHCP Manager. The minimum requirement is at least one activated scope on the DHCP server. The scopes added to a superscope are identified as member or child scopes.


143

To create a superscope, perform the following steps: 1. In DHCP Manager, right-click the DHCP server, and click New Superscope. Remember that at least one scope is required for a superscope. Otherwise, this option is not available. 2. Click Next at the New Superscope Wizard. 3. Enter the superscope name, and click Next. 4. Select the scopes to be added to the superscope, click Next, and then click Finish.

NOTE Additional scopes can be added to a superscope either during or after its creation.

To remove a superscope, select Delete from the Action menu. This is similar to removing a standard scope, except that removing a superscope does not remove any of the scopes contained within it. To add a scope to an existing superscope, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Right-click on the applicable scope, and click Add To Superscope. 3. In the Available superscopes list, select the superscope to include this scope. Activating a superscope is needed only for new superscopes. When a superscope is activated, it activates by default its member scopes as well. As in regular scope activation, until a superscope is activated, it does not assign IP addresses to its DHCP clients. To activate a superscope, right-click the superscope in the DHCP Manager and select Activate from the menu. To deactivate the scope, follow the same procedure as the menu item changes to Deactivate from Activate for an active superscope.

NOTE Do not activate a superscope until you specify the options you want for each of its member scopes.

The BOOTP (or Bootstrap protocol), as defined in RFCs 951 and 1542, is typically used more out of necessity, because DHCP is preferred. BOOTP, a predecessor to DHCP, allows diskless


BOOTP

5

144

clients to obtain IP addresses and other boot information required for network startup. BOOTP is commonly used in UNIX environments for X-terminals that do not have local disks. Because most Windows NT–based installations do not need BOOTP, a BOOTP table does not need be configured.

NOTE A BOOTP table is similar to a DHCP scope for the purpose of providing IP addresses and configurations.

BOOTP uses UDP packets to request and retrieve an IP address and a small boot image file from a Trivial File Transfer Protocol (TFTP) server. The Windows 2000 DHCP server offers BOOTP support through the use of pointer records contained in the BOOTP table. After the BOOTP broadcast, if a BOOTP record exists in the BOOTP table, the DHCP server returns a BOOTP message to the requesting BOOTP client. If there are no configured BOOTP records, the DHCP server simply ignores BOOTP request messages. BOOTP table records contain three fields: • Boot Image • File Name • File Server The Boot Image identifies the generic filename of the boot file, which is based on the BOOTP client. The File Name identifies the full boot file path returned from the BOOTP/DHCP server to the client. The File Server identifies the TFTP server that sources the boot file. The DHCP Manager can add, remove, and edit records in the BOOTP table.

NOTE Unlike DHCP, BOOTP uses permanent address leases, similar to reserved DHCP clients.

Where BOOTP is used, the range of IP addresses that are reserved for BOOTP service on a network must be excluded from any DHCP scopes that are set up and configured. To view the BOOTP table, perform the following steps: 1. Open DHCP Manager, right-click the DHCP server, and click Properties.


145

2. Verify that the Show the BOOTP Table Folder check box is selected. If the check box is empty, select it and click OK. 3. Click BOOTP Table to display BOOTP entries in the details window.

NOTE The BOOTP table is empty by default.

To add an entry to the BOOTP table, perform the following steps: 1. Open DHCP Manager, and expand the DHCP server container. 2. Right-click BOOTP Table, and select New Boot Image. 3. In the Add BOOTP Entry dialog box, enter the required information, and click Add. 4. Repeat step 3 for each additional BOOTP entry you want to add, and then click Close. To add dynamic BOOTP client support to a scope, perform the following steps: 1. Open DHCP Manager, and expand the DHCP server container. 2. Right-click the scope, and select Properties. 3. Click the Advanced tab. 4. For Assign IP Addresses Dynamically to Clients of, click either Both or BOOTP only. 5. In Lease Duration, adjust the default lease length for BOOTP clients (optional).

NOTE Because BOOTP clients can obtain IP addresses only at boot, the BOOTP lease length should exceed the time between BOOTP clients’ reboots on the network.

Dynamic DNS Update Configurations 5 CONFIGURING DHCP AND DNS

As mentioned in Chapter 3, “Active Directory and DNS,” a Windows 2000 DHCP server can perform DNS updates for its non–Windows 2000 DHCP clients. In this process, the DHCP server registers and updates the address (A) and pointer (PTR) resource records in DNS. This process also requires the use of the Client FQDN option (option 81), which allows the client to provide its fully qualified domain name (FQDN). Option 81 also allows the client to provide instructions to the DHCP server on how to process the client’s updates.

146

For example, the server might be configured in one of the following ways to process client requests: • The DHCP server registers and updates client information with its configured DNS servers according to the client request. • The DHCP server always registers and updates client information with its configured DNS servers. • The DHCP server never registers and updates client information with its configured DNS servers. To configure these settings on the Windows 2000 DHCP server, perform the following steps: 1. Open DHCP Manager and select the DHCP server. 2. Right-click on the scope and select Properties. 3. Click the DNS tab. 4. Modify or update the applicable settings per the following: • To update per client request, click the Update DNS Only If DHCP Client Requests option. • To always update, click the Always Update DNS option. • To never update, clear the Always Update DNS option.

Advanced DHCP/DNS Configuration Options The Windows 2000 DHCP server can be configured to perform additional updates. For example, the server can be configured to maintain host (A) resource records after the client lease expires, even though pointer (PTR) resource records are removed from DNS when the lease expires. By default, the server also removes the host (A) resource records when a client’s lease expires, but this is a configurable option. To modify this at the DHCP server, clear the Discard Forward (Name-to-Address) Lookups When Lease Expires check box in Properties on the DNS tab. The server can also be configured to not send updates for clients that cannot use the Client FQDN option (option 81). By default, the DHCP server sends updates for clients that do not support option 81 (pre–Windows 2000 machines). To modify this at the applicable DHCP server, clear or select the Enable Updates for DNS Clients That Do Not Support Dynamic Updates check box in Properties on the DNS tab.

DHCP Leases To view client lease information, perform the following steps:


147

1. In DHCP Manager, select the DHCP server. 2. Expand the applicable scope, and click Address Leases. 3. In the details pane, locate the client lease for which you want to view information.

NOTE DHCP clients cannot be edited. Only reserved clients allow certain information to be edited.

To delete a client lease, perform the following steps: 1. In DHCP Manager, select the DHCP server. 2. Expand the scope, and click Address Leases. 3. In the details pane, right-click the client’s IP address and select Delete. 4. Make a reservation with the IP address, or exclude it from the range. 5. At the client machine, release the IP address (ipconfig /release or winipcfg for Windows 9x clients) and then renew (ipconfig /renew). You can cancel all current leases by selecting all the clients in Address Leases, right-clicking, and selecting Delete. However, this process does not prevent the server from offering that IP address in future client requests and/or leases (unless step 5 in the preceding list is followed). To change the lease time for remote access clients, perform the following steps: 1. Open DHCP Manager, and select the DHCP server. 2. Expand the applicable scope, and right-click Scope Options. 3. Select Configure Options, and click Advanced. 4. In User Class, select Default Remote Access Class. 5. In Available Options, click the check box for 051 Lease. 6. In Long, type the lease value in seconds (for example, one hour equals 3,600 seconds, so type 0x3600 for a one-hour lease duration).

Optimizing Lease Management


Because IP address lease renewals can impact the performance of DHCP clients and the network, varying lease durations may help depending on the implementation. For example, larger and more stable networks with large address pools can be configured for longer lease times. This process reduces the frequency at which clients query the server for renewals, thus reducing network traffic.

148

However, if address pools are limited and the environment is less stable (more portable users), it is advantageous to set shorter lease times to maintain the address pool. This process ensures that leases are promptly returned to the pool for reallocation. If the company has a combination of the two previous examples, a scope could be configured for each so that laptops would receive IP addresses for the short-term lease scope, and the stable desktops could use the long-term lease scope. To set this option, use the class ID DHCP option mentioned earlier in this chapter for the class minority. In other words, if desktops are more predominant, use the default DHCP scope. Then set a class option for the laptops and configure each laptop to use this class option. Type ipconfig/setclassid at the Windows 2000 DHCP client and use the parameters to set the ID locally.

Configuring Windows 2000 DHCP Server Clients This section focuses on the client configuration of various operating systems. Because most of the effort of implementing DHCP focuses on server configuration, the client configuration process is relatively simple and easy. These are the client configurations addressed in this section: • Windows 2000 • Windows NT 4.0 • Windows 9x • Macintosh • UNIX/Linux

Windows 2000 Clients To configure a Windows 2000 client for DHCP, perform the following steps: 1. Right-click on My Network Place, and select Properties. 2. Right-click on Local Area Connection and select Properties (if multiple connections exist, the system may have multiple network devices, such as a multihomed machine or laptop with NIC and docking device). 3. Click on Internet Protocol (TCP/IP) and then click Properties. 4. Click the radio buttons for obtaining the IP address and DNS address automatically. Note that DNS values must be part of the DHCP options in order for the client to receive this information. 5. Select OK.


149

To verify, release, or renew a client address lease, perform the following steps: 1. At a DHCP-enabled client computer running Windows, open a command prompt. 2. Use the Ipconfig command-line utility to verify, release, or renew the lease of the client with a DHCP server, as shown here: • To verify a DHCP client lease, type ipconfig or ipconfig /all to view lease-status information. • To release a DHCP client lease, type ipconfig • To renew a DHCP client lease, type ipconfig

/release. /renew.

Windows NT Clients To configure a Windows 2000 client for DHCP, perform the following steps: 1. Right-click on Network Neighborhood, and select Properties. 2. Click the Protocols tab. 3. Select the TCP/IP Protocol and then click Properties. 4. Under the IP Address tab, click the Obtain an IP Address from the Server radio button. 5. Select OK.

Windows 9x Clients To configure a Windows 9x client for DHCP, perform the following steps: 1. Right-click on Network Neighborhood, and select Properties. 2. In the Configuration tab, select TCP/IP for the Network Adapter, and click Properties. 3. Select the TCP/IP Protocol and then click Properties. 4. Under the IP Address tab, click the Obtain an IP Address Automatically radio button. 5. Select OK, and reboot.

Macintosh Clients To configure a Macintosh client for DHCP, perform the following steps: 1. Right-click on Network Neighborhood, and select Properties. 2. Click the Protocols tab.

5

3. Select the TCP/IP Protocol and then click Properties.


4. Under the IP Address tab, click the Obtain an IP Address from the Server radio button. 5. Select OK.

150

UNIX/Linux Clients Due to the numerous flavors of UNIX and Linux on the market today, no standard installation or configuration exists. It is important to note that popular versions of Linux can easily be configured for DHCP, whereas operation systems such as Sun Solaris require additional software (such as Join System’s DHCP/DDNS) to implement DHCP. Consult your vendor for DHCP/DDNS support if you need to dynamically assign IP addresses to these machines.

NOTE In most corporate environments, UNIX and Linux clients are typically assigned static IP addresses because of their business-critical role. It is uncommon to assign dynamic IP addresses to these workstations.

Predefined Options for DHCP Clients Table 5.2 describes the predefined options (defined in RFC 1533) available for configuring DHCP clients. The Microsoft DHCP options that clients receive by default are bolded in Table 5.2. TABLE 5.2 Predefined Options for Configuring DHCP Clients Code

Option Name

Meaning

0 255 1 2

Pad End Subnet Mask Time offset

3 4 5 6 7 8 9

Router Time server Name servers DNS servers Log servers Cookie servers LPR servers

Causes subsequent fields to align on word boundaries Indicates end of options in the DHCP packet Specifies the subnet mask for the client’s subnet Specifies the Universal Coordinated Time (UCT) offset in seconds Lists router (gateway) IP addresses for the client’s subnet Lists time server IP addresses available for the client Lists name servers of IP addresses available for the client Lists DNS name server IP addresses for the client Lists MIT_LCS UDP log server IP addresses for the client Lists cookie server IP addresses (RFC 865) for the client Lists line-printer server IP addresses (RFC 1179) for the client


151

TABLE 5.2 Continued Code

Option Name

Meaning

10 11

Impress servers Resource location

12 13

Host name Boot file size

14

Merit dump file

15

Domain name

16 17

Swap server Root path

Lists Imagen Impress server IP addresses for the client Lists resource location servers (RFC 887) for the client servers Specifies the client’s hostname (limited to 63 characters) Specifies the size of the default boot image file for the client Specifies the ASCII pathname of a file where the client’s core image is dumped if a crash occurs Specifies the client’s DNS domain name for DNS hostname resolution Specifies the IP address of the client’s swap server Specifies the ASCII path for the client’s root disk

18

Extensions path

Specifies a file retrievable through TFTP

Summary Windows 2000 DHCP server is more robust than previous versions of Windows DHCP server, and it can integrate with Windows 2000 DNS to provide easier administration. Windows 2000 DHCP server uses a new management interface and offers new support for user-defined and vendor-defined class options. When Windows 2000 DHCP server integrates with Active Directory, permissions and authorization add new levels of security to prohibit rogue DHCP servers on the network and allow delegation of administration to specific users and groups. Windows 2000 DHCP server can also act as a proxy to update DNS for non–Windows 2000 clients.


CHAPTER

Administering DNS Servers Using MMC

6

IN THIS CHAPTER • Adding and Customizing the DNS Snap-in

154

• Administering and Configuring DNS Servers 156 • Managing Zone Properties in the MMC Console 171 • Managing Standard Primary and Secondary Zones 177 • Managing Resource Records in MMC • Summary

190

178

154

The Microsoft Management Console (MMC) is the management display structure for hosting administration tools designed as MMC snap-ins. The MMC consoles are stored as files with an .msc extension, and the built-in consoles are saved with particular options selected. Administrators can create MMC consoles that have preconfigured tools and security, so they can delegate administration to approved users or groups for local support.

Adding and Customizing the DNS Snap-in Although the DNS administrative tool is added by default during the DNS server installation (as mentioned in Chapter 4, “Planning and Installing Windows 2000 DNS”), the DNS snap-in allows for standardization or customization of the console. The following process identifies how administrators can create a custom console: 1. At a command prompt or Run window, type mmc. 2. On the Console menu, click Add/Remove Snap-in. 3. Click Add to display a list of available snap-ins. 4. Select the DNS snap-in, and then click Add. Other installed administrative add-ins can also be selected. 5. After selecting the desired snap-ins, click Close. Administrators can further restrict display options by altering the administrative tool options using the Extensions tab, as outlined in the continued process that follows: 6. Click OK. 7. Before saving the snap-in, click Options on the Console menu. 8. Click the Console tab, and then select from the following Console Mode items (as shown in Figure 6.1): • Author Mode • User Mode - Full Access • User Mode - Limited Access, Multiple Window • User Mode - Limited Access, Single Window Author Mode gives the user full access to MMC configuration, including the ability to add and remove snap-ins, the ability to create new windows, and full navigation of the console tree. User Mode - Full Access gives the user access to MMC configuration, such as creating new windows and navigation of the console tree. However, it does restrict the user’s ability to add and remove snap-ins or save configurations.

Administering DNS Servers Using MMC CHAPTER 6

User Mode - Limited Access, Single Window applies all the restrictions of the preceding option but does not allow the user to open child windows.

FIGURE 6.1 The Options window of the DNS MMC console.

NOTE Additional security is required to ensure that the user cannot create additional MMC consoles, because none of the listed options can prevent this from happening. For information on securing the consoles, see Chapter 7, “Windows 2000 and DNS Security.”

9. Click Save As on the Console menu. Specify a filename and path for the MMC console. This .msc file can then be distributed to other systems where the same snap-ins are preconfigured. By saving the .msc file, an administrator or delegated user can later open the saved console file from the Console menu or by double-clicking the console icon from its saved location (such as the desktop).

6 ADMINISTERING DNS SERVERS USING MMC

User Mode - Limited Access, Multiple Window restricts the user from MMC configuration and restricts the user’s ability to add and remove snap-ins or save configurations. However, it does allow the user to open child windows, but not close or save them.

155

156

Administering and Configuring DNS Servers In Chapter 4, we addressed the reasons for adding various DNS servers to the network. This section expands on those concepts and explains the processes for adding and configuring the new name servers in the MMC consoles.

Adding DNS Servers In the MMC console, administrators and delegated users with privileges can add servers to monitor. This process can ease administration by centralizing resources in a common console. To add an existing DNS server to the console, perform the following steps: 1. Open the DNS Manager, and select Connect To Computer from the Action menu. 2. From Select Target Computer, select either • This computer, for local management, or • The following computer, for a remote server. Specify either the DNS name or the IP address. 3. Select the Connect to the Specified Computer Now check box, and click OK. To remove a server from the DNS console, perform the following steps: 1. Open DNS Manager, right-click the DNS server to be deleted, and click Delete. 2. Click OK in the confirmation window.

Configuring a New Primary Server New primary servers can be added when you’re configuring a new zone on the network or adding additional DNS servers to Active Directory. Before implementing a new server or zone, rely on the DNS Help checklists provided in Windows 2000 Server. Primary servers can be implemented on a Windows 2000 DNS server in one of two ways: as standard primary zones, or as primary zones integrated with Active Directory. In standard primary-type zones, only this server can host and load the master copy of the zone. If Active Directory is installed, additional primary servers can be added using directory-integrated zones, which utilize the storage and replication features of the directory service.

CAUTION Standard primary-type zones are restricted to only one primary DNS server. Other DNS servers for the zone should never be configured to act as primary servers for an existing zone, because this configuration may cause errors or corrupt data within the zone.


Modifying DNS Servers

• Hostname • IP address • Primary or parent DNS domain name • Primary server for a zone (applicable to standard primary zones only) • DNS server removal from the network Each of these changes is covered in the following sections.

Changing the DNS Server Hostname If you need to change the hostname of a standard primary or secondary DNS server (but not its parent or primary DNS domain name), make the following changes in the zone where the server is configured as an authoritative server for the zone: 1. To open System Properties, right-click My Computer, and select Properties. 2. In the Network Identification panel, change the server’s computer name. 3. Restart the computer to initiate the DNS dynamic updates to the host (A) and pointer (PTR) records altered by the naming update (the process adds A and PTR records while discarding the old versions). 4. Update the name server (NS) RR in zones where the server is authoritative with the new host (A) RR. 5. Revise the name in the owner field of the start of authority (SOA) RR for the zone. 6. Verify that all delegation records (NS or A RRs) are updated for the server’s new hostname.

CAUTION If the primary DNS server is also a domain controller, this process cannot be performed unless the DC is demoted, renamed, and then promoted again. The renaming feature in System Properties will be grayed out.

Changing the DNS Server IP Address To change the IP address for a DNS server, simply update the IP address in the server address (A) resource record. However, proceed with caution because this process may result in the


DNS servers can be modified, if necessary, for various reasons, including changes to the following:

157

158

same IP address being assigned to different computers. This can also cause zone delegation errors from a parent zone if multiple name servers share the same IP address.

CAUTION When changing the IP address of a DNS server, remember to change any DHCP scope or server options that assign the DNS server option. You must also manually update any clients with statically assigned DNS entries in the Advanced TCP/IP Properties.

Changing the Server Primary DNS Domain Name The ability to change the primary DNS domain name for a DNS server depends on its status. Because the DNS server can run on a non–domain controller server or a domain controller, the process of modifying the primary DNS domain name will differ. If the server is a domain controller, the domain name cannot be directly changed because it corresponds with the Active Directory domain name where it was promoted. To change the primary or parent DNS name, the server must be demoted from its role as a domain controller. When the server is promoted again to domain controller, enter the new DNS domain name (such as the parent or child domain). This promotion process modifies the A and PTR RRs automatically.

NOTE Manual updating of the name server (NS) RRs for the old and new DNS parent domains may be required.

To change the DNS domain name for a DNS server computer not using Active Directory (such as a member server), some additional and manual modifications may be required. For example, if the DNS server is being moved from an old zone (old.samspublishing.com) to a new zone (new.samspublishing.com), the following steps are required: 1. Change the Primary DNS suffix for this computer in System properties, and restart the computer. 2. In the old.samspublishing.com zone, remove the host (A) RR for the server. 3. In the old.samspublishing.com zone, add the A RR for the server. 4. Update all start of authority (SOA) and name server (NS) RRs in zones containing the name of the renamed DNS server.


In the event that the primary name server for a standard primary zone needs to be changed (for example, from dc1 to dc2), perform the following steps within the zone file: 1. Add the new host (A) resource record (RR) for dc2. 2. Update the name server (NS) RR in the zone to remove dc1 and include dc2 as a configured server of authority that points to dc2’s new A RR added in the preceding step. 3. Revise the name in the owner field of the start of authority (SOA) RR for the zone from dc1 to dc2. 4. Remove dc1’s old A resource record. 5. Verify that any delegation records (NS or A RRs) from the parent zone are updated to refer to dc2.

Removing a DNS Server from the Network In the event that a DNS server needs to be removed from the network, the following changes are required in zones where the server is authoritative: 1. Remove the server’s address (A) resource record. 2. Update the name server (NS) records in zones where the server is authoritative by removing it from the name server list. 3. If necessary, revise the owner field of the SOA resource record for the zone to point to the new primary DNS server for the zone (this step is not required for Active Directory–integrated zones). 4. Verify that all delegation records (NS or A RRs) no longer point to the removed server.

Managing DNS Server Properties in the MMC Console When the DNS server is selected in the DNS console, and Properties is selected from the Action menu (or via a right-click on the server), various server configurations can be performed or modified. The Properties window includes the following tabs: • Interfaces • Forwarders • Advanced • Root Hints • Logging • Monitoring • Security


Changing a Zone’s Primary Server (Standard Primary Zones Only)

159

160

This section focuses on the scope of each of these configuration options.

NOTE The DNS MMC Action menu provides the same options as right-clicking on the selected item.

Interfaces In the Interfaces tab, the administrator can configure which network interface the DNS server should “listen” to for requests. For example, if the DNS server has multiple NICs, the listening option can be configured to listen to all NICs (identified by all IP addresses) or to listen to a specific IP address or list of addresses. Figure 6.2 shows the Interfaces tab in the server properties window. Remember that multiple IP addresses can be assigned to a single adapter.

FIGURE 6.2 The Interfaces tab of the DNS server properties window.

To restrict a DNS server to listen only on selected addresses, click Only the Following IP Addresses, and enter an IP address. Click Add and Repeat as necessary until all the required addresses are entered. The default configuration is for the DNS service to listen on all configured IP addresses for the server computer (because most DNS servers will have only one interface with a single IP address). Following the interface update, the DNS service needs to be stopped and then restarted to initiate the new interface option.


To start or stop a DNS server, perform the following steps: 1. In DNS Manager, right-click the appropriate DNS server, and place the mouse cursor over All Tasks. 2. In the All Tasks submenu, select the appropriate command from the following: • To start the service, click Start. • To stop the service, click Stop. • To interrupt the service, click Pause. • To stop and then automatically restart the service, click Restart.

NOTE The preceding tasks can also be issued at a command prompt using the following commands:

•

net start dns

•

net stop dns

•

net pause dns

•

net continue dns

Forwarders In the Forwarders tab (shown in Figure 6.3), the administrator can manage a list of DNS servers to receive forwarding requests from the local server. As mentioned earlier in the book, forwarding is typically implemented with multiple DNS servers on a high-speed LAN that has a slow Internet connection. This process also utilizes the caching options of the forwarding DNS server’s cache to resolve certain queries. Forwarders are DNS servers that provide recursive service for other DNS servers. Forwarders help resolve queries not answered by the local server. To use forwarders on a DNS server, perform the following steps in the Forwarders tab: 1. Select the Enable Forwarders check box. 2. If the DNS server will use only forwarders, select the Do Not Use Recursion check box.


Stopping and Starting the DNS Service Under certain circumstances (such as the interface reconfiguration in the preceding section), it may be necessary to stop the DNS server. This pauses all name resolution provided by the server.

161

162

3. Add IP addresses for other DNS servers that act as forwarders for this server. 4. As an option, the Forward Time-out (Seconds) value can be changed. This option is available only if the Do Not Use Recursion check box is cleared.

FIGURE 6.3 The Forwarders tab of the DNS server properties window.

NOTE If the DNS server is a root server for the DNS namespace, the forwarding option will not be available.

Advanced In the Advanced tab (shown in Figure 6.4), the administrator will find DNS options not located under the other server properties tabs. Although most of the default options are acceptable for most DNS server implementations, certain integration functionality may need to be configured for use with legacy DNS servers. Server Options Server options that can be configured in the Server Options area include the following: • Disable Recursion (not selected by default) • BIND Secondaries (selected by default) • Fail on Load If Bad Zone Data (not selected by default)


• Enable Round Robin (selected by default) • Secure Cache Against Pollution (not selected by default)

FIGURE 6.4 The Advanced tab of the DNS server properties window.

NOTE To change the default settings for these Server options, simply click the appropriate check box, and click OK.

Recursion is enabled by default, so the DNS service will query other DNS servers when it can’t answer a client request. Otherwise, the DNS server would reply with a best guess or failure. Note that recursion does not occur if the DNS server’s cache can respond to the client. BIND Secondaries is enabled by default because many environments will continue to use BIND DNS servers in this capacity, or not at all. The BIND Secondaries option allows for fast secondary zone transfers, a process that puts multiple resource records in each TCP record sent to the secondary DNS server. This option is detailed further in Chapter 9, “BIND and Windows 2000 Interoperability.” The Fail on Load If Bad Zone Data option is disabled by default, which allows the DNS service to start even if data in one or more zones is invalid. In a Windows 2000 DNS homogenous environment, this option is not as applicable as when BIND servers and text editing of zone


• Enable Netmask Ordering (selected by default)

163

164

files is possible. In that situation, a bad manual text edit can result in erroneous information in the zone file. For monitoring purposes this option can be enabled later. The Enable Round Robin option is enabled by default to allow multihomed machines to rotate through the list of applicable IP addresses. Let’s say, for example, that multiple Web servers exist for www.kevinkocis.com. These servers have the following IP addresses: • 192.168.1.10 • 10.12.1.10 • 192.168.1.20 • 10.12.1.20 When DNS is queried for the IP address, Round Robin allows the query to “cycle through” the IP addresses in a looping pattern (with 192.168.1.10, then 10.12.1.10, and so on until it returns to the beginning). This process balances the load slightly on the servers, even though it is not a sophisticated load-balancing process. The Enable Netmask Ordering option is similar to Round Robin, except that it bases the rotation scheme on the requestor’s IP address and subnet mask. For example, if the client issuing the query has an IP address of 192.168.5.25, the query order for the previous Web servers would be as shown here: • 192.168.1.10 • 192.168.1.20 • 10.12.1.10 • 10.12.1.20

NOTE The Enable Netmask Ordering option takes priority over the Round Robin option when both options are selected, with the Round Robin occurring with respect to the subnet mask.

The Secure Cache Against Pollution option is used to reduce the contents of the cache in an attempt to clean up the cache. By default, a Windows 2000 DNS server uses a secure response option to eliminate adding unrelated resource records included in a referral answer to the cache. With this option, the server can determine that referred names are potentially polluting or unsecure and discard them. For example, if a query was made for www.kevinkocis.com and a referral answer provided a record for a name outside of the kevinkocis.com domain (such as north-rim.com), then that name would not be cached.


To change the name-checking method used by the DNS server, select from the following options in the Name Checking pull-down menu: • Strict RFC (ANSI)—Enforces RFC-compliant naming rules for all DNS names that the server processes. Names that are not RFC-compliant are treated as erroneous data by the server. • Non RFC (ANSI)—Allows names that are not RFC-compliant to be used with the DNS server, such as names that use ASCII characters but are not compliant with RFC host naming requirements. • Multibyte (UTF8)—Allows names that use the Unicode eight-bit translation encoding scheme, which is a proposed RFC draft, to be used with the DNS server. • All names—Allows for the use of all names. The Windows 2000 DNS server default is Non RFC (ANSI). This option allows for loose name checking and for standard ANSI or ASCII encoded characters in DNS names, which provides the highest possible interoperability with other DNS servers and host systems. Load Zone Data on Startup Options When the Windows 2000 DNS server boots, information regarding the zone data can be pulled from various locations. Zone information can be stored in three locations (or formats): • Windows 2000 Registry • File format • Active Directory

NOTE The load zone option is also known as the DNS boot option.

The boot method determines which source the DNS server uses to load DNS information. The default setting for Windows 2000 DNS is to load the data stored in the registry. To change the boot method used by the DNS server, select from the following options in the Load Zone Data on the Startup pull-down menu: From Registry, From File, or From Active Directory and Registry.


Name Checking The Name Checking field of the advanced properties window determines how domain names are verified. Because there is no system or international naming standard for hostnames, variation is required for interoperability among systems.

165

166

NOTE For the file boot method, the file must be a text file named Boot. This Boot file also needs to be located in the \Winnt\System32\Dns folder of the local computer.

Because the DNS server also loads the root hints, server and zone parameters from various locations depending on the this setting, Table 6.1 shows the source locations for DNS and where it writes zones, root hints, and server and zone parameters. TABLE 6.1 How the DNS Server Loads Zones, Root Hints, and Parameters Boot from File

Boot from Registry

Boot from AD and Registry

Read Root Hints From:

Root hints file

Write Root Hints To: Read Zones From:

Root hints file

If available, the root hints file. Otherwise, if the Directory is available and contains root hints, the Directory. Root hints file.

Boot file

Registry.

Write Zones To:

Boot file and the registry

Read Server and Zones Parameters From:


Write Server and Zones Parameters To:


Registry and, if the zone is Active Directory– integrated, the Directory. Registry and (for Active Directory– integrated zones) the Directory. Registry (for all zones) and for Active (Directory–integrated zones) the Directory.

If the Directory is available and contains root hints, the Directory. otherwise, the root hints file. If the Directory is available, the Directory. The Directory (for Active Directory– integrated zones) and the registry. The registry and, if the zone is Active Directory–integrated, the Directory. The Directory (for Active Directory– integrated zones) and the registry. The Directory (for Active Directory– integrated zones) and the registry.


If the setting is changed, the DNS server writes the root hints file, zones, and parameters to the locations specified in the original setting. Then the server reads them from the new setting.

When the From Active Directory and Registry option is selected, other DNS servers in Active Directory (which are also primary servers) can query the directory and automatically load all directory-integrated zones, because these zones are stored in the directory database. DNS servers update Active Directory by using the following procedure: 1. After a local update, the DNS server polls Active Directory for current zone information. If the file is not current (based on the recent update), the DNS server polls for any changes and incorporates those changes in the in-memory copy. 2. The server then verifies that all prerequisites are satisfied for updating records to the Active Directory copy. 3. Finally, it updates the primary zone data in Active Directory. Automatic Record Scavenging The Enable Automatic Scavenging of Stale Records option allows the DNS server to remove stale resource records that may accumulate in zone data. To enable automatic scavenging of stale resource records, select the Enable Automatic Scavenging of Stale Records check box. Next, adjust the Scavenging Period value by selecting from the pull-down menu and setting the interval option, which appears in either hours or days. To start immediate scavenging of stale resource records, select Scavenge Stale Resource Records from the Action menu. For more information on aging and scavenging options, see the section “Resource Record Aging and Scavenging,” later in this chapter. Finally, in the advanced properties window, an administrator can reset all the advanced values to their defaults by clicking the Reset to Default button, and then clicking OK.

Root Hints Root hints are critical for servers that are authoritative for non-root zones to locate authoritative servers that manage higher-level domains or domains located in other subtrees of the DNS domain namespace. These hints “point” to higher-level DNS servers to locate authoritative servers for other domains. The root hints are stored in a file (cache.dns) that is located in the %SystemRoot%\System32\ Dns folder on the server computer, and that typically contains the NS and A resource records


In the case of Active Directory–integrated zones, the server polls Active Directory at specified intervals for changes to those zones, and also verifies any new or deleted zones.

167

168

for the Internet root domain servers. If the DNS service is being implemented on a private network, this file needs to be edited or replaced with records pointing to the internal root DNS servers. The file can also be deleted for this instance. To update root hints on the DNS server, update the information in the Root Hints tab (shown in Figure 6.5) as described here: • To add a root server to the list, click Add, and then specify the name and IP address of the server to be added to the list. • To modify a root server in the list, click Edit, and then specify the name and IP address of the server to be modified in the list. • To remove a root server from the list, select it in the list and click Remove.

NOTE The root hints cannot be modified if the server is hosting a root zone.

FIGURE 6.5 The Root Hints tab of the DNS server properties window.

Logging The Logging tab (shown in Figure 6.6) is used to enable logging of server and client DNS activity. The default configuration for logging is for all logging options to be turned off,


because logging impacts DNS service and server performance. For this reason, logging should be used only for a limited time and under strict control of the DNS administrator.

169


FIGURE 6.6 The Logging tab of the DNS server properties window.

When logging is enabled, a log file called dns.log is created in the %systemroot%\system32\ dns directory. This verbose file can then be viewed using a text editor such as WordPad.

NOTE The log file cannot be deleted by turning logging off and then back on again. The file must be manually renamed or deleted when the debugging process is complete.

Monitoring The Monitoring tab (shown in Figure 6.7) allows administrators to perform minimal DNS diagnostics. Although other third-party tools may prove to be more robust, the monitoring option in Windows 2000 DNS monitors recursive queries for the DNS server, and it cannot be restricted to a specified zone. DNS server testing starts when the administrator either clicks the Test Now button or checks automatic testing and sets the interval in the Test Interval lists. The test results will be displayed in the Test Results list box and will continue to be processed even if the window is closed.

170

FIGURE 6.7 The Monitoring tab of the DNS server properties window.

Security The Security tab (shown in Figure 6.8) allows administrators to set security for the DNS server. DNS security uses the new Windows 2000 security model for assigning permissions and access. For more information on DNS security, see Chapter 7.

FIGURE 6.8 The Security tab of the DNS server properties window.


Manual DNS Updates

In standard primary zones, the DNS server immediately writes in-memory changes to the zone file on the hard drive. This process expedites the normal process in which changes are written at predefined update intervals or at shutdown. Manual updates to Active Directory–integrated zones do not apply because updates are written immediately to the directory zone database. Zones are automatically started after creation or server startup. Only manually paused zones need to be restarted. To pause or start a zone, perform the following steps: 1. In DNS Manager, right-click the forward or reverse lookup zone, and select Properties. 2. On the General tab, click Pause (or Start if the zone had been paused), and then click OK.

Managing Zone Properties in the MMC Console When the DNS zone is selected in the DNS console, and Properties is selected either from the Action menu or from right-clicking the zone, various zone configurations can be performed or modified. The Properties window includes the following tabs: • General • Start of Authority (SOA) • Name Servers • WINS • Zone Transfers • Security This section focuses on the scope of each of these configuration options.

General In the General tab of the zone properties (shown in Figure 6.9), the administrator can configure a range of options. The first option is the zone status (which should be “running” unless it has been paused). To pause the zone for troubleshooting purposes, click the Pause button. When the zone is paused, it does not respond to any DNS queries.


In addition to automatic DNS updates, administrators can perform manual updates to assist with troubleshooting or optimization. To manually update server data files, right-click the DNS server and click Update Server Data Files. To manually clear the server names cache, rightclick the DNS server and select Clear Cache.

171

172

FIGURE 6.9 The General tab of the DNS zone properties window.

The next option is to change the zone type. This option allows the administrator to convert the zone type between a standard primary DNS zone, a standard secondary DNS zone, and an Active Directory–integrated zone.

NOTE Although this modification can be performed on any DNS server, it should be performed at the originating primary server where the zone was initially created.

This is a relatively easy process in a single DNS server environment, but in a complex DNS environment, this process should be avoided, and should have been planned out before implementation. To change the zone type, click Change. In the Change Zone Type field, select a zone type other than the current one, and then click OK.

NOTE If the zone type is changed from Standard primary to Active Directory–integrated, you can then add the zone to other DNS servers by configuring them to use the Boot from DS option when they initialize DNS service.


NOTE Changing a zone from secondary to primary type can affect zone activities, such as dynamic updates, zone transfers, and notify lists (mentioned later in this chapter). Be sure to update all name servers regarding zone changes.

The Allow Dynamic Updates? field contains three options: • Only Secure Updates (for Active Directory–integrated zones only) • Yes • No Chapter 7 addresses this feature in greater detail in the section “Securing Dynamic Updates.” The final configuration option on the General tab is the aging/scavenging option. This option allows the administrator to “flush” stale resource records from the zone at predetermined intervals. The aging/scavenging option is discussed in greater detail in the section “Resource Record Aging and Scavenging,” later in this chapter.

Start of Authority (SOA) In the Start of Authority (SOA) tab (shown in Figure 6.10), the administrator can configure options for the SOA resource record for the zone. The resource record options set in this tab are inherited to other resource records for the zone (such as the TTL values). This tab displays the same window as when the administrator right-clicks the SOA resource record and selects Properties. For more detailed information on the SOA record and configuration, see “Managing Authority Records,” later in this chapter.

Name Servers Similar to the SOA tab, the Name Servers tab (shown in Figure 6.11) shows the authoritative name servers for the zone. This tab displays the same window as when the administrator right-clicks the NS resource record and selects Properties. In the case of a primary or Active Directory–integrated zone, the list will start with the local server’s name and IP address.


The Active Directory–integrated zone type is available only on DNS servers that are also domain controllers. The standard primary and standard secondary zone types are available on any DNS server. Remember, when configuring a secondary zone type, you must specify the IP address of another DNS server to ensure that zone transfers occur properly.

173

174

FIGURE 6.10 The Start of Authority (SOA) tab of the DNS zone properties window.

FIGURE 6.11 The Name Servers tab of the DNS zone properties window.

Name server (NS) resource records (like SOA records) are considered to be authority records. For more information on configuring NS records, see “Managing Authority Records,” later in this chapter.

WINS In the WINS tab (shown in Figure 6.12), administrators can configure WINS options for networks in which the WINS service is installed and used in conjunction with DNS. Windows


2000 native environments will not need WINS, but most environments initially will require this type of resolution for their mixed client environments.

175


FIGURE 6.12 The WINS tab and the Advanced option window of the DNS zone properties window.

WINS options, including interoperability and configuration, are discussed in greater detail in Chapter 8, “Windows 2000 DNS and WINS Replication.”

Zone Transfers In the Zone Transfers tab (shown in Figure 6.13), administrators can set specific zone transfer options. These options control access from secondary name servers in the zone. The default configuration allows for transfers to any DNS server requesting a transfer. Zone transfers can be set to any server, to any known name server (as listed in the Name Servers tab), or to specified servers. The administrator has the option to add specific servers by their IP address.

NOTE Unlike BIND, Windows 2000 DNS cannot restrict by subnet. It can restrict only by IP address.

The final modification on the Zone Transfers tab is the Notify option, which specifies name servers that should be contacted when updates occur on the primary name server. The following section explains the notify process.

176

FIGURE 6.13 The Zone Transfers tab of the DNS zone properties window.

Configuring Notify Lists The purpose of notify lists is to provide a means for a master server (either the primary server or another secondary server) to notify secondary servers when the zone changes. By default, the zone’s notify list is based on the authoritative servers listed on the Name Servers tab. To create and manage a notify list for a zone (which can be performed only on a primary server), perform the following steps on the Zone Transfers tab: 1. Click the Notify button to bring up the Notify list window (as shown in Figure 6.14). 2. Verify that the Automatically Notify check box is checked. 3. Select the method for creating a list, either Servers Listed on the Name Servers Tab (the default) or The Following Servers (a custom list). 4. If the option, The Following Servers was selected, add or remove server IP addresses to form the notify list.

Security The Security tab, which is identical in appearance to the DNS server Security tab shown in Figure 6.8, allows administrators to set security on the zones and related objects. DNS security uses the new Windows 2000 security model for assigning permissions and access. For more information on DNS security, see Chapter 7.


177


FIGURE 6.14 The Notify list window from the Zone Transfers tab of the DNS zone properties window.

Managing Standard Primary and Secondary Zones To initiate a zone transfer at a secondary server, perform the following steps: 1. In DNS Manager, right-click the applicable zone, and select Properties. 2. On the Action menu, click Transfer from Master. To update the master server for a secondary zone, perform the following steps: 1. In DNS Manager, right-click the applicable zone, and select Properties. 2. In the General tab, in IP Address enter the IP address for the new master server, and click Add. To change a zone filename, perform the following steps: 1. In DNS Manager, right-click the applicable zone, and select Properties. 2. On the General tab, enter the new filename in the Zone File Name field, and click OK.

178

CAUTION After the zone filename has been changed, other DNS servers authoritative for the zone must be updated with the new zone filename, or zone transfers will fail.

Remember, only the name of the zone file changes, not the name of the zone. The zone filename is not used for Active Directory–integrated zones because these zones store zone data in the Active Directory database and not a text file on the DNS server computer.

Managing Reverse Lookup Zones When reverse lookup zones are created, the process of adding pointer (PTR) resource records can be performed using the following methods: • Select the Update Associated PTR Record option during host (A) resource record creation in forward lookup zones. • If Windows 2000 DHCP servers are implemented, use DHCP-DNS integration options for updating reverse lookup zones for pre–Windows 2000 clients. • If all the network clients are Windows 2000 Professional, the clients can automatically register their respective PTR records with the DNS server. To add a new domain to a zone, perform the following steps: 1. In DNS Manager, right-click the forward lookup zone, and select Properties. 2. Select New Domain, enter the new domain name without periods, and then click OK.

Managing Resource Records in MMC In addition to these general zone properties and transfers, additional zone properties can be configured through certain resource records in the DNS console, including the following: • Authority record properties • SOA properties • NS properties • Other RR properties • A records • PTR records • CNAME records • MX records


• CRV records

Managing Authority Records When a DNS server loads a zone, the two types of resource records that determine the authoritative properties of the zone are the SOA and NS. First, the start of authority (SOA) initializes the zone, and indicates zone authority for the DNS domain name. The SOA also affects how the zone is to be refreshed and transferred to other authoritative servers for the zone. Next, the name server (NS) resource record notes which DNS servers are authoritative for the zone.

NOTE Both SOA and NS resources are required records for any zone and are typically the first resource records listed in files. When a new zone is created, these RRs are created by default.

Start of Authority (SOA) The start of the authority (SOA) resource record, which always loads first in any standard zone, indicates the originating DNS server or primary server for the zone. In the SOA record, an administrator can change properties regarding zone transfer information. To modify the start of authority (SOA) record for a zone, perform the following steps: 1. In DNS Manager, right-click the applicable zone, and select Properties. 2. Click the Start of Authority (SOA) tab, and modify the record as required; then click OK. 3. Set the following intervals as appropriate: • Refresh interval (the default is 1 hour) • Retry interval (the default is 10 minutes) • Expire interval (the default is 1 day) 4. Click OK to save the adjusted intervals.

Name Server (NS) Name server (NS) resource records can be used to assign authority to specified servers for a DNS domain name in the local zone’s list of authoritative servers, or to assign delegation to a subdomain.


• WINS records

179

180

NOTE When out-of-zone NS and A records are required for delegation, they are known as glue records.

To specify other DNS servers as authoritative for a zone, perform the following steps: 1. In DNS Manager, right-click the applicable zone, and select Properties. 2. Select the Name Servers tab, and click Add. 3. Enter the IP address(es) or FQDN(s) of the DNS servers, and then click Add. If entering an FQDN, click Resolve to verify the IP address before adding it to the list. This process is usually performed at the primary zone when authoritative secondary DNS servers are being added to the zone.

NOTE Windows 2000 DNS servers automatically add and perform initial configuration of the NS resource record for each new primary type zone added to the server.

Managing Other Resource Records Other non-authority resource records supported by Windows 2000 DNS servers can be added or modified within the DNS Management console. These are the most common resource records (RRs), which were addressed in Chapter 2, “DNS Server Operations”: • Host (A) • Pointer (PTR) • Alias (CNAME) • Service location (SRV) • Mail Exchanger (MX)

Host (A) Resource Records Host (A) resource records are created through the following processes: • Manually, by an administrator assigning a static IP address for the client. • Automatically, through dynamic registration from a Windows 2000 computer client.


• Automatically, from a Windows 2000 DHCP server supplying IP addresses to earlier versions of Windows clients. This option is provided only with Windows 2000 Server.

Not all resources on a network require DNS entries. Only hosts that share resources require a host (A) resource record, because their DNS names need to be registered for location ease. These include, but are not limited to, shared workstations, mail servers, and Web servers.

To manually add a host (A) resource record to a zone, perform the following steps: 1. In DNS Manager, right-click the forward lookup zone, and select Properties. 2. Select New Host. 3. Enter the name and IP address. 4. Select the Create Associated Pointer (PTR) Record check box to create a pointer record. 5. Click Add Host to add the new host record to the zone.

Pointer (PTR) Resource Records Pointer (PTR) records support reverse lookups, based on zones created in the in-addr.arpa domain. PTR records locate a host by resolving the IP address to the FQDN for the host. PTR records can be added to a zone using the same methods as A records (see the preceding section). To manually add a pointer (PTR) resource record to a reverse zone, perform the following steps: 1. In DNS Manager, select the appropriate reverse lookup zone. 2. Right-click in the details pane, and select New Pointer. 3. Enter the host IP address in the Host IP Number field. 4. Enter the hostname (FQDN) in the Host Name field, or click Browse to search the domain for host (A) records. 5. Click OK.

Alias (CNAME) Resource Records Alias (CNAME) resource records, also referred to as canonical names, allow multiple names to point to a single host, such as hosting an FTP server and a Web server on the same computer. CNAME records are typically used when hosts need to be renamed or when multiple names need to be associated with a single host.


NOTE

181

182

When renaming a host with a host (A) record, an administrator needs to perform the following steps: 1. Create a new A record in the zone for the new DNS name. 2. Create a CNAME record for the old DNS name that points to the new A record from step 1. 3. Delete the original A record for the old DNS name (and its PTR record, if necessary).

CAUTION When renaming a host, set a time limit for the CNAME record, because if an administrator forgets to delete the CNAME record, failed queries will result if the A record is deleted.

However, the more popular implementation of a CNAME record is to provide a permanent generic alias for a service-based name, such as www.kevinkocis.com, to more than one computer or if the Web server is multihomed (with multiple network cards and IP addresses). For example, a computer named web1.kevinkocis.com performs both Web and FTP services. As a Web server, it is named www.kevinkocis.com. As an FTP server, it is named ftp.kevinkocis.com. To implement this naming scheme for this computer, the following CNAME entries need to be added in the kevinkocis.com zone: web1

IN

A

192.168.1.1

ftp

IN

CNAME

web1

www

IN

CNAME

web1

In this example, if the FTP server migrated to another system, the CNAME record would need to be changed to the new A record for the FTP server, as shown in the following example: web1

IN

A

192.168.1.1

ftp1

IN

A

192.168.1.2

ftp

IN

CNAME

ftp1

www

IN

CNAME

web1

To add an alias (CNAME) resource record to a zone, perform the following steps: 1. In DNS Manager, right-click the forward lookup zone, and select New Alias. 2. Enter the alias name in the Alias Name field.


3. Enter the FQDN in the Fully Qualified Name for Target Host text box, or click Browse to locate the host (A) records in the domain.

Mail Exchanger (MX) Resource Records Email applications such as Microsoft Exchange use the mail exchanger (MX) record to locate a mail server. The record performs this function based on the e-mail recipient’s domain name. The MX record shows the DNS domain name for the computer or computers that process mail for a domain. If multiple MX records exist in the same zone, the DNS Client service contacts mail servers based on their preference values (from lowest to highest). For example, let’s say that mail1 and mail2 are Exchange servers in the kevinkocis.com zone. Because the mail1 server has a lower preference value (10), email addressed to [email protected] is delivered to [email protected] first if possible. If mail1 is unavailable, the client will use [email protected]. The following resource record text shows the MX records for these mail servers: @ @

IN IN

MX MX

10 20

mail1 mail2

NOTE The at sign (@) in the records indicates that the mailer DNS domain name is the same as the name of origin (kevinkocis.com) for the zone.

To add a mail exchanger (MX) resource record to a zone, perform the following steps: 1. In DNS Manager, select the forward lookup zone. 2. Right-click in the details pane and select New Mail Exchanger. 3. In the Host or Domain field, enter the domain name for mail delivery. 4. Enter the mail exchanger hostname in the Mail Server field, or click Browse to search the domain for host (A) records. 5. Set the mail server priority as needed for this zone, and click OK.

Service Location (SRV) Resource Records Service location (SRV) records are required to locate domain controllers in Active Directory. Typically, manual administration of SRV records is minimal during installation of Active Directory. SRV records are configured automatically during the migration to Active Directory


4. Click OK to add the new record to the zone.

183

184

because DNS can be installed as part of the process. If a DNS server that can accept updates for the DNS domain name used to name the Active Directory is not found, a Windows 2000 DNS server can be installed locally and automatically configured with a zone based on the Active Directory domain. This minimizes the location process of another DNS server, and locally configures the SRV records for future domain controllers. If another DNS server on the network can accept dynamic updates of the SRV record, the configuration process is complete.

Other Resource Records Other resource records also can be added to the zone depending on the necessary function. These additional records are listed in Appendix A, “ Resource Record Types.” To add a resource record to a zone, perform the following steps: 1. In DNS Manager, right-click the forward lookup zone, and select Other New Records. 2. In the Select a Resource Record Type list box, use the scrollbar to locate the record to be added, and select it. 3. Click Create Record. 4. In New Resource Record, enter the necessary information. 5. Click OK.

Modifying Resource Records To modify an existing resource record in a zone, right-click the resource record in the zone’s detail pane, and select Properties. The advanced properties can be selected via the Advanced option on the View menu. To delete the resource record, right-click the record and select Delete. To view unsupported resource records in a zone, select Properties and view the values specific to this record.

Unsupported Resource Records Although the DNS Management console lets administrators view unsupported resource records in secondary zones, these records cannot be managed through Windows 2000 DNS. These records, which are acquired from other DNS services, such as BIND, include the following: • Legacy records, such as mail forwarder (MF) and mail domain (MD). • Secure or encrypting DNS records, such as signature (SIG) or next (NXT). For detailed information on various resource records, see Appendix A.


Resource Record Aging and Scavenging

Resource records can also clutter the DNS database. For example, because mobile Windows 2000 clients can register their own A resource records, these records might not be deleted if the laptops are promptly disconnected from the network (such as removing the network cable or NIC). The scavenging process can be configured on a per-zone, per-server, or per-record basis. Administrators can control aging and scavenging by identifying the following: • DNS servers allowed to scavenge zones • Zones to be scavenged • Records to be scavenged from selected zones You can also enable aging for sets of records by using the command-line tool Dnscmd.exe. For more information on dnscmd.exe, see Chapter 12, “Remote and Command-Line Utilities for DNS Management.” An algorithm used by the DNS server prevents the scavenging process from accidentally removing critical resource records.

CAUTION A static resource record that is incidentally or accidentally configured for scavenging will be deleted if it is not refreshed periodically. Use caution when configuring parameters for aging and scavenging.

The scavenging mechanism is disabled by default, and it should not be enabled unless all parameters are understood and documented. Scavenging implements a “grandfather clause.” In other words, the server will not scavenge records created before scavenging was enabled, even if the zone was converted to an Active Directory–integrated zone first.

NOTE To enable scavenging of such records, use AgeAllRecords in Dnscmd.exe.


Scavenging resolves the issue of old or “stale” resource records in the DNS database. Stale records are usually the result of dynamic updates that have not been updated or removed. These resource records, if not regularly aged and scavenged, can affect the performance and validity of the DNS information. For example, a DNS server may respond to a client query with a stale resource record, causing name resolution problems for clients on the network.

185

186

The scavenging process can occur automatically or manually. With automatic scavenging, aging and scavenging time parameters are set by the administrator. The default scavenging period is one day, and the minimum allowed value is one hour. Manual scavenging specifies that aging and scavenging of stale records is to be performed as a nonrecurring operation for any eligible zones at the server. To manually scavenge resource records from a server, right-click the DNS server in the DNS console and select Scavenge Stale Resource Records. Other options such as clearing the cache and updating server data files are also available when you right-click on the DNS server.

Aging and Scavenging Parameters The Windows 2000 DNS server scavenging process designates a time stamp to each resource record, along with configured parameters, that determines when to scavenge records. By default, static resource records added to DNS zone information have a record time-stamp value of zero. This zero value prevents these records from aging or removal during scavenging. An administrator can manually reset record properties to configure these records for aging and scavenging. In this operation, the record will be deleted based on its modified time-stamp value.

CAUTION Enabling aging/scavenging for use with standard primary zones modifies the format of zone files. Although the change does not affect zone replication to secondary servers, it exclusively restricts file use to Windows 2000 DNS servers.

Table 6.2 lists the zone parameters that are affected when records are scavenged. You configure these properties on the zone. TABLE 6.2 Aging and Scavenging Parameters for Zones Zone Parameter

Description

Configuration Tool

Notes

No-refresh interval

Time when server refuses refreshes for the record. However,updates are still accepted.

DNS console and Dnscmd.exe.

The default for AD-integrated zones (which are replicated through AD) is Default norefresh interval.


TABLE 6.2 Continued

6 Description

Refresh interval

Follows the NoDNS console and refresh interval, Dnscmd.exe. and starts the refresh acceptance interval. Following this interval, the DNS server begins the scavenging process for nonrefreshed records. Indicates whether DNS console and aging and scavenging Dnscmd.exe. is enabled for zone records.

Scavenging Servers

Start scavenging

Determines which servers can scavenge records in this zone. Determines when a server starts scavenging.

Configuration Tool

Only Dnscmd.exe.

Not configurable

Notes The default for AD-integrated zones (which are replicated through AD) is Default no-refresh interval.

The default for AD-integrated zones (which are replicated through AD) is Default enable scavenging. Replicated by Active Directory. Not replicated by Active Directory.

Table 6.3 lists the server parameters that affect when records are scavenged. You set these parameters on the server. TABLE 6.3 Server Aging and Scavenging Parameters for Resource Records Server Parameter

Description

Configuration Tool

Notes

Default no-refresh interval

Default used by AD-integrated zones that specifies the Time when server refuses refreshes for the record. However, updates are still accepted.

DNS console (displayed as Norefresh interval) and Dnscmd.exe.

Default is 7 days.

ADMINISTERING DNS SERVERS USING MMC

Zone Parameter

Enable scavenging

187

188

TABLE 6.3 Continued Server Parameter

Description

Configuration Tool

Notes

Default refresh interval

Specifies the refresh interval used by default for the AD-integrated zone. Indicates whether aging and scavenging is enabled for the Active Directoryintegrated zone. Indicates whether aging and scavenging is enabled for zone records. Repeats scavenging process as specified in the Scavenging Period parameter. Specifies the frequency for a DNS server enabled for scavenging to remove stale records.

DNS console (displayed as Refresh interval) and Dnscmd.exe. DNS console (shown as Enable scavenging) and Dnscmd.exe.

Default is 7 days.

Default enable scavenging

Enable scavenging

Scavenging Period

By default, scavenging is disabled.

DNS console, By default, Advanced View scavenging is (shown as Enable disabled. automatic scavenging of stale records) and Dnscmd.exe.

DNS console, Advanced View (shown as Scavenging Period), and Dnscmd.exe.

Default is 7 days.

Resource records set for scavenging follow a timeline, as represented in Figure 6.15. The process consists of four basic steps: • Timestamp (when the record is created or refreshed) • No-refresh interval (when no refreshes are allowed) • Refresh interval (when refreshes are accepted) • Scavenging (when nonrefreshed records are removed) When a record is created or refreshed on an Active Directory–integrated zone or on a standard primary zone set for scavenging, a time stamp is written. As mentioned earlier, time stamps with a zero value are never changed or scavenged. During the No-refresh period, records cannot be “restamped” for the specified duration. After the record is created or refreshed, its time stamp cannot be updated during the No-refresh interval. This option prevents unnecessary Active Directory replication traffic.

Administering DNS Servers Using MMC CHAPTER 6 Timestamp

189

6

Refresh interval

Scavenging phase

Refresh process

FIGURE 6.15 The life span of a scavengeable resource record.

NOTE A resource record can still be updated during the No-refresh interval, such as in a dynamic update.

The No-refresh interval is followed by the Refresh interval, in which the server accepts refreshes. When this process occurs, the value of the time stamp changes to the current time. The final step is the actual scavenging. If the record was not refreshed before the expiration of the refresh interval, the server can scavenge the record. The exact time when scavenging occurs depends on various server parameters listed in the next section.

Configuring Scavenging Parameters An administrator should consider certain issues when configuring server parameters for scavenging. First, the refresh interval needs to be greater than the refresh period for each record within a zone. Second, some server services may refresh records at different intervals, as listed here: • Netlogon (refreshes every hour) • Windows 2000 computers (refresh every 24 hours) • DHCP servers (refresh based on IP lease renewals)

NOTE The DHCP service typically requires the longest refresh interval of all services, so if the Windows 2000 DHCP service runs on the network, the default scavenging and aging values are acceptable. Other third-party DHCP server implementations may require modification of the defaults.

ADMINISTERING DNS SERVERS USING MMC

No-refresh interval

190

To set aging/scavenging properties for an Active Directory DNS server, perform the following steps: 1. In DNS Manager, right-click the DNS server, and select Set Aging/Scavenging for All Zones. 2. Select the Scavenge Stale Resource Records check box. 3. Modify other aging and scavenging properties as needed. 4. After applying and confirming the scavenging settings, the administrator has the option of applying the settings to new Active Directory–integrated zones (existing zones can be updated manually).

NOTE For standard primary zones, the settings and properties must be set at the applicable zone, even if the Scavenge Stale Resource Records check box is selected.

To set aging/scavenging properties for a selected zone, set the properties at the zone level instead of the server. To view when a zone can start scavenging stale records, perform the following steps: 1. In DNS Manager, right-click the forward lookup zone, and select Properties. 2. On the General tab, click Aging. 3. In the Zone Aging/Scavenging Properties dialog box, note the time value. To reset scavenging and aging properties for a specified resource record, perform the following steps: 1. In DNS Manager, right-click the forward or reverse lookup zone. 2. In the details pane, double-click the applicable resource record for scavenging configuration. 3. Clear the Delete This Record When It Becomes Stale check box to prevent its aging or potential removal during the scavenging process.

Summary The DNS MMC Management Console is the primary management tool for administering Windows 2000 DNS. The DNS management console can be restricted depending on user permissions, and can be set for various levels of access. DNS servers, zones, and resource records can be added, deleted, and modified through the DNS console.


Every zone contains authority records—the start of authority (SOA) and name server (NS) resource records. Windows 2000 DNS server also has a priority feature for aging and scavenging dynamic resource record updates. This feature, however, renders zone file data incompatible with other DNS implementations.


Windows 2000 DNS server can load zones and root hints from a file (similar to legacy DNS), from the registry, and from Active Directory and Registry. For Active Directory–integrated zones, the zone data loads from Active Directory and Registry.

191

CHAPTER

Windows 2000 and DNS Security

7

IN THIS CHAPTER • Windows 2000 Security

194

• Active Directory Object Security • Group Policy

204

• Windows 2000 DNS Security • Summary

201

221

214

194

Windows 2000 Security The Windows 2000 environment offers various new security features. Security in Active Directory and Windows 2000 DNS involves the use of Access Control Lists (ACLs) and security identifiers (SIDs) to determine access to objects and the level of access. This chapter provides a closer look at the security features of Windows 2000, Active Directory, and DNS. These features include Kerberos and IPSec, as well as access control security. This chapter also addresses delegation and ownership of secured objects in DNS.

The Active Directory Security Model The security model in Active Directory is important to understand, because it is the basis for Active Directory–integrated zone access and permission. Active Directory uses organizational units (OUs) to organize the namespace into subsets. These OUs contain objects, and each object can be granted or denied access to other objects in the Active Directory. In Windows 2000, object access can now be set at the property level of an individual object. Active Directory also introduces new authentication, network, and access control securities. These technologies include Kerberos, Public Key Infrastructure (PKI), and IPSec. The following sections focus on Windows 2000 authentication featuring Kerberos.

Authentication The authentication process in Active Directory is perhaps the most significant security change from Window NT 4.0 authentication. The process has been overhauled in an effort to become more standardized. In Windows NT 4.0, Windows NT LAN Manager (NTLM) was the default authentication protocol for network authentication. Although NTLM is still supported in Windows 2000, it is no longer the default. For Active Directory, Kerberos V5 (version 5) is the default protocol. Let’s take a closer look at Kerberos.

Kerberos Authentication Kerberos, which was developed at MIT, has been implemented widely on UNIX-based systems. Kerberos also provides a more network-based security environment for UNIX-like systems. Kerberos is the Greek name for the legendary three-headed dog Cerberus who guards the gate to the underworld. This name was chosen to correspond to the three parts of this protocol: authentication, authorization and accounting. Kerberos is automatically installed when the Active Directory is installed on a Windows 2000 domain controller (DC). Kerberos is used for user logon authentication, as well as to support the transitive trusts in Windows 2000.

Windows 2000 and DNS Security CHAPTER 7

195

Kerberos Components As mentioned previously, the Kerberos name evolved from the functionality of its three-part protocol. These are the physical components of this protocol: • The client—which is the computer requesting a service from another network computer. • The server—which is the computer providing the service to the network. • The Key Distribution Center (KDC)—which is the computer issuing the session key necessary for the client and server to communicate in matters of security.

• Session key • Client key • Server key The Kerberos authentication process is quite complicated. To better understand Kerberos authentication, let’s look at the process as illustrated in Figure 7.1.

Steps 2 and 3

4 ep St

St

ep

1

Server

Step 6

Client

FIGURE 7.1 The Kerberos authentication process.

The Kerberos authentication process is as follows: 1. The client requests access to a server service.

Server

7 WINDOWS 2000 AND DNS SECURITY

The Kerberos authentication process is the result of an interaction among the client requesting a service, the server providing the service, and the KDC. In Kerberos, a special key server— the KDC—distributes keys. For security purposes, the system actually requires the following three keys in order to provide secure interaction among client, server, and KDC:

196

2. The KDC creates the session key. 3. The KDC creates a ticket and encrypts it with the server’s long-term key. 4. The KDC encloses the ticket in a response to the client that is encrypted with the client’s long-term key. 5. The client decrypts the response with its long-term key and extracts the ticket. 6. The client sends an application request to the server (along with authenticator information encrypted in the session key) and a ticket encrypted with the server’s long-term key. 7. The server decrypts the ticket with its long-term key and gets the session key. 8. The server uses the session key to decrypt the authenticator. In Active Directory, every domain controller is automatically configured as a KDC. Administrators can locate the Kerberos Key Distribution Center Service, which starts automatically, by choosing Start, Programs, Administrative Tools, Services.

NOTE NTLM is still supported in Windows 2000 for compatibility with down-level clients and servers, as well as to Windows 2000 standalone computer logons.

Object-Oriented Security Windows NT/2000 has always incorporated an object-oriented security approach in the form of NT file system (NTFS). Let’s briefly review the fundamentals of object-oriented security. When a user logs on, an access token is created. The access token contains security information for the user’s account.

NOTE A security principal (or account) can be a user, group, computer, or service. Security principals have accounts that can be assigned rights or privileges. Local accounts are managed on the local computers’ Security Accounts Manager (SAM). Active Directory manages domain accounts.

Accounts, or processes, use or manipulate resources known as objects, which can include files, shares, printers, computers, and so on. Security for objects includes access lists to determine what account or process can gain access to the object. More information on Access Control Lists, and other object-oriented security features is given next.


197

Access Control Lists As mentioned in Chapter 3, “Active Directory and DNS,” Access Control Lists (ACLs) determine whether an account can access an object. An ACL is a list of Access Control Entries (ACEs) stored with the object. The Access Control List for an object is generally located in the Security tab of the property sheet. This tab shows the list of accounts that have access to this object, as well as the associated permissions. The Advanced button displays the account permissions in detail.

Access Control Entries ACLs on directory objects contain Access Control Entries (ACEs) that apply to the object as a whole, and ACEs that apply to the individual attributes of the object. This allows an administrator to control not just which accounts can access the object, but what properties can be viewed by that account. For example, all users might be granted read access to the email and telephone-number attributes for all other users in the directory, but security properties of users might be denied to all but members of a special security administrators group. Individual users might be granted write access to personal attributes such as the telephone and mailing addresses on their own user objects. To view the ACEs for a particular ACL, click Advanced at the bottom of the Security tab of the Properties dialog box. The Access Control Settings Editor then appears, as shown in Figure 7.2. When an ACE is added, permissions can be granted and denied. As usual, denying a permission takes precedence over granting one, so if an account is granted write access to an object via one group and denied access through another group, the account has no access to the object.

NOTE Because there is a good chance that groups will require similar access to objects, applying ACEs to groups can reduce administrative effort in the future.


Windows 2000 stores the ACL as a binary value called a security descriptor. Each ACE contains a security identifier, which identifies the security principal (user, for example) to which the ACE applies and the set of access rights that are allowed, denied, or audited for that security principal (user).

198

FIGURE 7.2 The Access Control Settings for a DNS server.

Security Identifier A security identifier (SID) is a unique value of variable length used to identify a security principal or security group. The SID identifies a user, group, service, or computer account within an enterprise. Every account is issued a SID when it is created. Access control mechanisms in Windows 2000 identify security principals by SID rather than by name. Windows 2000 uses SIDs in the following access control components: • Access tokens—One SID in an access token identifies the account represented by the token. Additional SIDs identify the security groups to which the account belongs. • Security descriptors—One SID in an object’s security descriptor identifies the object’s owner. Another SID identifies the owner’s primary group. • Access Control Entries—Each ACE contains a SID that identifies the account for which access is allowed, denied, or audited. The Local Security Authority (LSA) creates the SID when the local account is created. The Domain Security Authority (DSA) generates the SID when a domain account is created, and the SID is then stored as an attribute of the object in Active Directory.

Rights and Permissions A right is the authorization to perform an operation. In Windows 2000, only the right to allow or deny access to resources owned by the user or group is inherent. All other rights must be granted. From an administrator’s perspective, there are two types of rights: permissions and user rights.


199

A permission is the authorization to perform an operation on a specific object, such as a file. Owners grant permissions. If an administrator owns an object, he or she can grant any user or group permission to perform any function on the object, including granting permission to take ownership. User rights grant or deny a user or group the ability to perform system tasks, such as shutting down a server. Administrators can grant user rights.

NOTE

When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if Connie (a member of the DNSAdmins group) allows the DNSAdmins group exclusive permission to read her DNS document file, users who are not members of the DNSAdmins group are implicitly denied access. Permissions can also be explicitly denied. For example, Jennifer might not want Chris to be able to read her DNS document, even though he is a member of the DNSAdmins group. She can exclude Chris by explicitly denying him permission to read the file. Explicit denials are best used when excluding a subset (such as Chris) from a larger group (such as DNSAdmins) that has been given permission to access an object. Each permission that an object’s owner grants to a particular user or group is stored as an ACE in a DACL that is part of the object’s security descriptor. In the user interface, ACEs appear as Permission Entries in the Access Control Settings dialog box (see Figure 7.2).

Security Descriptor An object’s security descriptor contains access control information and identifies the object’s owner by SID. If permissions are configured for an object, its security descriptor contains a Discretionary Access Control List (DACL) with SIDs for the account allowed or denied access. If auditing is configured for the object, its security descriptor also contains a System Access Control List (SACL) that controls how the security subsystem audits attempts to access the object. For example, if a user attempts to modify a resource record in DNS, the operating system examines the user’s security descriptor to determine whether he or she is allowed to perform the modification.


Although permissions can be provided to individual users, giving them to a security group is more efficient. Every user added to the group receives the permissions defined for that group.

200

Generally, security descriptors can include information about the following: • Owner—The only security principal with an inherent right to allow or deny permission to access an object. Ownership can be transferred. By default, the built-in Administrators group on a computer is assigned a user right that allows this group to take ownership. • Permission—Authority to perform an operation or a set of operations on an object, which is granted or denied by an object’s owner. Because access to an object is given at the owner’s discretion, the type of access control used in Windows 2000 is called discretionary access control. • User right—Authority to perform an operation that affects an entire computer rather than a particular object. User rights (also known as privileges) are assigned by administrators to individual users or groups as part of the security settings for the computer. Although user rights can be managed centrally through Group Policy, they are applied locally. • Access right—A permission from a subject’s point of view. When a user allows or denies permission through the Access Control Settings dialog box, the result is recorded as an ACE in the object’s DACL. Whereas in the user interface a permission is represented by a word or phrase, in an ACE it is represented by a set of bit flags in an access mask. Each bit flag corresponds to an access right.

Security Descriptor Components A security descriptor is a binary data structure of variable length, which contains the following components: • Header—The header contains a revision number and a set of control flags that describes characteristics of the security descriptor. • Owner—The Owner field contains the SID for the object’s owner. • Primary Group—The Primary Group field contains the SID for the owner’s primary group, which is used only for POSIX compliance. • Discretionary Access Control List—The DACL is a list of ACEs that is controlled by the object’s owner. • System Access Control List—The SACL resembles the DACL but is used to control object auditing. When an audited event occurs, it is recorded in the security log. Each ACE in an SACL has a header that indicates whether auditing is triggered by success or failure or both, a SID that specifies an account to monitor, and an access mask that lists the operations to audit. An access check compares information in the thread’s access token with information in the object’s security descriptor:


201

• The access token contains a SID that identifies the user associated with the thread and SIDs that identify the groups whose members include the user. • The security descriptor contains a DACL with ACEs that specify the access rights allowed or denied to specific accounts.

NOTE Denials for a SID are always listed first in the DACL, which explains why a Deny overrides any allowance for the same SID.

Subject Access token

User SID Group SIDs Privilege info

Object System verifies access control entries of object

Security Owner SID Descriptor Group SID SACL

Other access info DACL ACE ACE ACE

FIGURE 7.3 Validating a request for access.

Active Directory Object Security Active Directory stores objects and their respective information, and makes them available on the network. When Active Directory is queried, it provides information back to the respective user or program. Although the security systems in Windows 2000 resembles those in Windows NT, the 2000 security system includes the following: • User-based authorization


The security subsystem checks the object’s DACL, looking for ACEs that apply to the user and group SIDs from the thread’s access token. It steps through each ACE until it finds one that either allows or denies access to the user or one of the user’s groups, or until there are no more ACEs to check. If it comes to the end of the DACL and the thread’s desired access is still not explicitly allowed or denied, the security subsystem denies access to the object. Figure 7.3 illustrates this process.

202

• Discretionary access to securable objects • Permission inheritance • Administrative privileges • Auditing of system events

Active Directory Objects These are the common object types in Active Directory: • User • Group • Computer • Organizational Unit (OU) • Printer • Shared folder The objects in the Active Directory are protected by ACLs. If a user is not permitted to view an object, he or she will not be able to see that object in Active Directory. In Active Directory an object can have standard permissions or special permissions assigned to it. Although most objects will have both, standard permissions are more common and will suit most access requirements. These are the standard object permissions: • Full Control—which allows Change permission and the ability to take ownership. • Read—which allows the ability to view objects and their attributes, the owner, and Active Directory permissions. • Write—which allows the ability to modify the object attributes. • Create All Child Objects—which allows the ability to create any type of child object in the OU. • Delete All Child Objects—which allows the ability to delete any type of object in the OU.

Assigning Active Directory Permissions Object permissions for an Active Directory object can be set similarly to an object on an NT File System. Before administering object security, make sure that the Advanced Features option is selected. To do this, open Active Directory Users and Computers, and under the View menu, select Advanced Features. This makes the security options available to administer.


203

To set object permissions, perform the following steps: 1. Right-click the desired object and click Properties. 2. In the Properties dialog bog, click the Security tab. 3. Select the account for modification and check the appropriate permission (Allow or Deny).

NOTE

Although standard permissions will suffice for most administrative needs, you can access special permissions by clicking the Advanced button in the Security tab.

CAUTION Avoid assigning permissions for object properties, because this can significantly impact functionality. By assigning a wrong or misinterpreted permission, an administrator can hide the object or make it inaccessible in Active Directory.

Permission Inheritance With Windows 2000 security, permissions can be assigned to the object, as well as child objects and their type. Permission inheritance allows the administrator or owner of an Active Directory object to minimize the granular assignment of permissions for that object. With permission inheritance, an administrator can allow a permission to propagate to child objects that are created under the parent object. For example, Full Control permission can be assigned to the DNS Administrators group for the DNS documentation folder, and then permission inheritance can be assigned to the folder. Any subfolders and files will inherit the permissions, and any member of the DNS Administrators group will have full control. To assign permission inheritance, in the Permissions window, under the Object tab, select the desired inheritance in the Apply Onto pull-down menu. To prevent permission inheritance on a child object, clear the Allow Inheritable Permissions from Parent to Propagate to This Object check box. Permissions for objects can be managed at two levels: the object level and the property level. Permissions allowed or denied at the object level apply to the entire object. For example, the


Accounts can be added using the Add button, and then assigned the appropriate object permissions.

204

lead DNS administrator could assign an object-level permission on a DNS documentation folder that allows the DNSAdmins group to create child objects, but doesn’t allow the objects to be deleted. Permissions allowed or denied at the property level apply only to specific properties. For example, an administrator could set a property-level permission on the Domain Users object that allows a human resources representative to change various properties such as the address or work number of an employee. To assign per-property permissions, perform the following steps: 1. Right-click the desired object and click Properties. 2. In the Properties dialog box click the Security tab. 3. Click the Advanced button. 4. Click View/Edit to modify an existing account permission, or click Add to create new one. (If Add is selected, an account, such as the DNSAdmins group, must be selected to be assigned the permission.) 5. In the Permission Entry window, click the Properties tab to view the per-property permissions list. We’ll address DNS permission inheritance more in-depth later in this chapter.

Conflicts Between Privileges and Permissions For the most part, conflicts between privileges and permissions occur only in situations in which the rights required to administer a system overlap the rights of resource ownership. When rights conflict, a right overrides a permission. For example, the Backup Operators group has the right to back up all files and folders regardless of their permissions to those files and folders.

Group Policy Group Policy is a new feature to Windows 2000 and Active Directory. Group Policy evolved from the System Policy Editor introduced in Windows NT 4.0 and is essentially a grouping of multiple policies. The Group Policy MMC snap-in is new to Active Directory, and allows administrators to configure multiple user and computer settings that can be enforced or blocked at the site, domain, and organizational unit level.

Group Policy Fundamentals Group Policy is similar to NT 4.0’s System Policy Editor in that it manages computers and users in Active Directory, including software deployment and configuration management. Group Policy dictates configurations for users and computers in Active Directory.


205

Group Policy forces users to maintain customized and consistent environments as deemed by the group policy administrator. Group Policy, by default, affects all computers and users in a site, a domain, or an organizational unit (depending on where it is linked), but no other objects, such as printers or shares.

NOTE In particular, Group Policy does not affect security groups. The location of a security group in Active Directory is irrelevant to Group Policy.

Windows NT 4.0 and Windows 2000 Policy Comparison Windows NT 4.0 implemented the System Policy Editor (Poledit.exe) to specify user and computer configurations stored in the Registry. System Policy Editor allowed administrators to control the user work environment and enforce system configuration settings for all domain computers running Windows NT 4.0. In Windows 2000, the Group Policy snap-in manages desktop configurations for computers and users. Whereas System Policy Editor could apply only to domains, Group Policy can also apply to sites and organizational units, and can provide security.

NOTE Default policy settings in Group Policy do not remain in the registry permanently as they did in NT 4.0. Microsoft referred to this as registry “tattooing.” Windows 2000 Group Policy settings are removed when they no longer apply.

CAUTION Although Windows 9x and NT 4.0 clients and computers can be supported by use of Windows NT 4.0 templates and the System Policy Editor, it is not recommended to support this in addition to Windows 2000 Group Policy (which applies only to Windows 2000 computers). Also, due to possible registry “tattooing,” as mentioned earlier, problems may result when upgrading from earlier clients exposed to NT 4.0 policies.

WINDOWS 2000 AND DNS SECURITY

Security groups are used to filter Group Policy by changing the Apply Group Policy and the Read permissions on the Group Policy object for the relevant security groups.

7

206

Group Policy Administrative Requirements To set Group Policy for a selected Active Directory site, domain, or organizational unit, a user must have access to a Windows 2000 domain controller for that Active Directory, and must have Read/Write permissions to access the system volume of domain controllers (that is, the Sysvol folder). A user must also have Modify Rights to the selected directory site, domain, or OU.

NOTE Only Domain Administrators, Enterprise Administrators, Group Policy Creator Owners, and the operating system can create new Group Policy Objects by default.

A non-administrative user or group can be added to the Group Policy Creator Owners security group. When a member of that group creates a Group Policy Object (GPO), he or she becomes the Creator Owner of the GPO, and can edit the GPO. As a member of the Group Policy Creator Owners group, you have full control of only GPOs that you created or that were delegated to you.

Group Policy Objects Group Policy settings are stored in Group Policy Objects (GPOs). GPOs can control settings for users and computers in sites, domains, and OUs, and are linked with Active Directory containers. Group Policy settings are hierarchical, and they can be applied at the following levels: • Site—These GPOs apply to all domains and servers within a site. • Domain—These GPOs are the second level where GPOs can be assigned, and they apply to all the containers (OUs) within the domain. They are usually assigned by local domain administrators. • Organizational Units—This GPO setting is the most granular; here, policies can be set for business units inside the domain.

Creating Group Policy Objects To create a group policy using the MMC snap-in, perform the following steps: 1. Click Start, Run. Then type mmc and press Enter. 2. On the Console menu, click Add/Remove Snap-in. 3. Click the Add button, select Group Policy, and then confirm by clicking Add again.


207

4. In the Group Policy Object window, click Browse to choose a policy other than the local computer policy. You should see the Default Domain Policy (as well as OUs, domains, and sites that may contain additional policies). 5. If you want to create a brand-new group policy, right-click in the window and select New, or click the New Policy icon to the right of the drop-down list to create a new domain Group Policy Object (see Figure 7.4).


FIGURE 7.4 Creating a new domain Group Policy Object.

6. Name the new object and click OK to open it. 7. Check the Allow the Focus of the Group Policy Snap-In to Be Changed When Launching from the Command Line option. This way, you can change the context of the snap-in when you launch the MMC item. 8. Click Finish and then OK to add the new snap-in. These new objects are linked to the domain or organizational unit by default. To create a Group Policy Object with this method, the administrator must have permission to create the Group Policy Object, as well as permission to link it to the domain or organizational unit. Otherwise, the New button on the Properties page for the domain or organizational unit is grayed out.

Configuring Group Policy By default, Domain Administrators, Enterprise Administrators, the operating system, and the Group Policy Object Creator Owner have full control of Group Policy Objects without the Apply Group Policy attribute. GPO permissions can be delegated as well. The group policy itself is contained within a Group Policy Object in Active Directory. The object is created in the Group Policy Editor, which can be launched in three ways: • From the Active Directory Users and Computers console, from the Group Policy tab on container objects

208

• From the Active Directory Sites and Services console, from the Group Policy tab on container objects • As a separate management console using MMC and opening gpedit.msc Group policies can be applied to three containers: • Site Group Policy • Domain Group Policy • Organizational Unit This list also represents the order of policy application from top to bottom. When a computer boots into Active Directory, it inherits the settings in the Computer Configuration portion of its associated GPOs and applies them. When a user logs on, he or she inherits the settings in the User Configuration portion of the group policy, which are then applied to the user’s account. Only users and computers receive group policies. Local group policies (those policies set locally at the computer) also exist but are not part of GPO. They can also be overridden by GPO. The order of application is significant to the architecture of Active Directory because, by default, a policy applied later overwrites a policy applied earlier when a setting for the later-applied policy is either Enabled or Disabled.

NOTE Group policies override any local user profile settings, so if a default screen saver is set in Computer Configuration, any users who customize their screen saver will inherit the default set in the GPO.

You also can force or prevent GPOs from affecting groups of users or computers. The most powerful settings for avoiding the default behavior are the No Override and Block Policy Inheritance settings. It is best to minimize the use of these settings because they may affect logon performance.

MMC Snap-in Extension Model The main nodes of the Group Policy snap-in are MMC snap-in extensions that load when you start the Group Policy snap-in. These extensions include Administrative Templates, Scripts, Security Settings, Software Installation, Remote Installation Services, Internet Explorer Maintenance, and Folder Redirection.


209

The root node of the Group Policy snap-in appears as the name of the Group Policy Object and the domain in which it is stored, in the following format: [<server name>] Policy

The next level of the namespace has two nodes: Computer Configuration and User Configuration. They are the parent folders used to configure and enforce Group Policy on computers and users.

Computer Policy

The Computer Configuration settings specify operating-system behavior, including desktop and security settings, as well as startup and shutdown scripts. Because the Computer Configuration settings are applied to a computer, this policy is best applied to computers that require being locked down to protect local data or prevent misuse of applications. The Computer Configuration portion of group policies includes an abundance of security settings, as shown in Figure 7.5, that are applied to individual computers.

FIGURE 7.5 The Computer Configuration group policy for password security in the default domain policy.


The Computer Configuration policies can change Registry settings within HKEY_LOCAL_ The settings in the Computer Configuration policies are applied to a computer regardless of the logged-on user. Aside from assigning interface preferences, group policies can apply logon, logoff, startup, and shutdown scripts; distribute software; change security settings; and redirect system folder locations such as My Documents.

MACHINE.

210

NOTE Computer policy takes precedence over conflicting user policy.

User Policy The User Configuration settings are similar to the Computer Configuration settings. User Configuration policies can change Registry settings within HKEY_CURRENT_USER. The User Configuration policies are applied to any computer that a user logs on to and will follow a user around the enterprise. Many of these settings are similar in content to the Computer Configuration set, but this interface has many more settings in the User Configuration set, as shown in Figure 7.6.

FIGURE 7.6 The User Configuration group policy in the default domain policy.

User Configuration settings enable the same interface to appear wherever a user logs on, which is preferred for roving users (such as in a lab setting). Scripts (which have different settings for users than those for computers) show why a setting is placed under the Computer Configuration as opposed to the User Configuration. Computer settings include startup and shutdown scripts, which run automatically for a computer regardless of any logged-on users. User settings include logon and logoff scripts that occur only when a user logs on to the network and Group Policy is applied.


211

Settings and Templates The Computer Configuration and User Configuration parent nodes have several child nodes, including the following: • Software Settings • Windows Settings • Administrative Templates

FIGURE 7.7 The DNS Server group policy in the System Service folder under Windows Settings.

Linking GPOs A GPO can be applied at the site, domain, and OU levels. This is accomplished by linking the GPO to a container or to multiple container objects. To view a GPO link, open it in the Group Policy console, right-click the root node, click Properties, and then click the Links tab. Click Find Now after setting the domain on the drop-down list.


The DNS Server group policy is located in the System Services folder of the Computer Configuration’s Windows Settings container, as shown in Figure 7.7. If this policy is configured (by right-clicking and selecting Security), the default permission is for the Everyone group to have Full Control (as shown in Figure 7.8), so use caution when defining the group policy, and modify permissions as necessary.

212

FIGURE 7.8 The default permissions for the Everyone group in the DNS Server group policy.

When linking a GPO, anyone assigned the task of creating a GPO must have permission not only to create it but also to link it to the domain or organizational unit; otherwise, they will be restricted from creating a new GPO.

NOTE For performance reasons, avoid linking to a GPO in a different domain.

Group Policy Inheritance By default, Group Policy Object settings flow from parent to child containers, and this includes all settings for computer and user objects in each container. Inheritance can be combined with delegation to grant administrative rights to directory subtrees.

Blocking Policy Inheritance A group policy inherited from a higher level can be blocked so that it does not pass farther down the hierarchy. Blocking Inheritance is usually set at the OU level to prevent certain GPO settings from “trickling down” from a parent container GPO. To block a policy, perform the following steps:


213

1. Right-click the container linked to the GPO, and select Properties. 2. Click the Group Policy tab. 3. Check the Block Policy Inheritance box at the bottom of the dialog box.

NOTE The Block Policy Inheritance policy setting is not available for sites. Also, you cannot selectively block GPOs.

7 If conflicts occur between a policy setting in two different GPOs, the last GPO applied overrides the setting applied previously. An administrator can stop a policy from being blocked or overridden by lower policies. To enforce a policy, follow these steps: 1. Right-click the site, domain, or OU, and select Properties. 2. Click the Group Policy tab. 3. Select Options. 4. Check the No Override box.

CAUTION For performance reasons, both No Override and Block Policy should be used sparingly.

Group Policy Permissions The default permissions on Group Policy Objects are as shown in Table 7.1. TABLE 7.1 GPO Default Permissions Security Group

Default Settings

Authenticated users Local system Domain administrators Administrators

Read, Apply Group Policy (AGP) Full Control (includes AGP) Read, Write, Create Child, Delete Child Read, Write, Create Child


Enforcing Group Policy

214

By default, the Default Domain Policy Group Policy Object cannot be deleted by any administrator, which prevents the accidental deletion of this critical GPO. A user or an administrator who does not have Write access (but does have Read access) to a GPO cannot use the Group Policy snap-in to view its settings.

Windows 2000 DNS Security DNS uses Windows 2000 security to address access and permissions. This section focuses on four key security measures related to DNS: • DNS Service Security • DNS Zone and Record Security • Dynamic DNS Security • Client Security

DNS Service Security The following groups, by default, have Full Control access to the DNS service: • DNSAdmins • Domain Admins • Enterprise Admins (through inheritance)

NOTE Permissions granted through inheritance are grayed out in the Permissions area of the Security window, as shown in Figure 7.9.

By clicking on the Advanced button, administrators can edit the associated ACEs for DNS security (as shown earlier in Figure 7.2).

DNS Zone and Record Security Administrators with Create and Delete All Child Object permissions can create and delete DNS zones on the DNS server. For example, in Figure 7.9 members of the Enterprise Admins group have the inherited permission to create and delete child objects. Therefore, this group will have permission to create DNS zones.


215

7

Inherited permissions for the Enterprise Admins group.

NOTE These permissions apply to Active Directory–integrated, primary, and secondary zones. However, in the case of primary and secondary zones, access to the server is also required (AD-integrated zones are excluded from this requirement because permissions are managed by Active Directory). File permissions to the zone file are also necessary.

Active Directory–Integrated Zone Records AD-integrated DNS zones store their resource record within the directory schema. The schema uses two main object classes for the DNS information: dnsZone and dnsNode. The dnsZone object class in Active Directory is comparable to a standard zone file (stored as text), and represents a single Active Directory–integrated zone. The dnsZone object contains dnsNode objects for each unique hostname within the zone (this includes variations such as domain controller and global catalog server). The dnsZone objects possess an attribute called dnsProperty that defines critical information about the zone, such as dynamically update capability. The dnsNode object class is comparable to individual resource records in the zone (dnsZone). Each dnsNode object will have a dnsRecord multivalue attribute that contains the resource information.


FIGURE 7.9

216

Delegating Zones In DNS the namespace can be divided into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. Consider the following reasons when planning to implement additional zones: • An administrative need to delegate management of a portion of the DNS namespace (perhaps due to lack of local resources or in the case of a remote location) • The need to minimize traffic loads and improve DNS performance • The need to extend the namespace (such as adding subdomains for new locations or acquired businesses)

NOTE When delegating zones, remember that each new zone requires delegation records in other zones that point to the authoritative DNS servers for the new zone.

To add a new zone, right-click on either the Forward or the Reverse Lookup Zone container, and select New Zone (which launches the New Zone wizard). Deletion of a zone typically occurs when administrators need to delete a secondary copy of a zone, because deleting the primary zone is usually unnecessary unless the DNS namespace is being reconfigured. Select Delete to delete the zone, and click OK to confirm.

CAUTION Deleting an Active Directory–integrated zone removes the zone from use on all other Windows 2000 DNS servers using Active Directory to load and update the zone locally.

Zone delegation is the process of assigning responsibility for managing the zone to another user or group. This process is common when new child zones are added. For example, samspublishing.com needs to create subdomains called books and software. The zones for these domains will need to be delegated due to administrative overhead, so the zones books.samspublishing.com and software.samspublishing.com are created. Delegation can occur during or after the creation of a subdomain. To add a new zone delegation, perform the following steps: 1. In DNS Manager, right-click the parent zone (for example, samspublishing.com), and select New Delegation.


217

2. In the Delegation wizard, click Next. 3. Enter the name of the delegated domain (for example, books). 4. In the Name Servers window, add the name server by IP address or click Browse to locate the name server in the domain. Click OK. 5. Click Next, then Finish to complete the delegation.

Dynamic DNS Security

DNS Dynamic Update Process Dynamic updates can be sent by services such as a DHCP server or client, Netlogon, and others. However, the most common in Windows 2000 DNS are dynamic updates performed by the DHCP client and server. Although any primary zones can be configured for dynamic update, only Active Directory– integrated zones can be configured for secure dynamic update. The default setting for dynamic updates allows the client to attempt a dynamic update first. If that registration fails, the client then negotiates a secure dynamic update. The default setting can be changed in the General tab of the zone Properties window. The Allow Dynamic Updates field contains three options: • Only Secure Updates (for Active Directory–integrated zones only) • Yes • No This default can also be verified or configured in the registry by referring to or adding the UpdateSecurityLevel registry entry to the following subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

The value of UpdateSecurityLevel can be set to the decimal values 0, 16, or 256, which configure security as shown here: 256

Specifies the use of secure dynamic update only.

16

Specifies the use of insecure dynamic update only.

0

Specifies the use of secure dynamic update when an insecure dynamic update is refused. This is the default value.


An issue with dynamically modifying data in DNS is security. A DNS server that adds the zone data statically has implicit security, because an administrator has the only access to modify the zone data. Dynamic modifications of zone data by DNS clients pose a potential security problem in determining whether the DNS client is authorized to modify the data. Windows 2000 provides secured update capability for Active Directory–integrated zones.

218

CAUTION If secure dynamic update is disabled, the client is not able to perform updates on zones configured for secure dynamic update.

Windows 2000 supports secure dynamic updates through the Generic Security Service Application Programming Interface (GSS-API, specified in RFC 2078; www.ietf.org/rfc/ rfc2078.txt), which provides security services independently of the underlying security mechanism. Windows 2000 implements the GSS-API using an algorithm (through the Kerberos V5 authentication protocol) as specified in the GSS Algorithm for TSIG (GSS-TSIG) Internet Draft. The algorithm also uses the TKEY and TSIG resource records for security. For more information on these resource records, refer to the IETF Internet site, mentioned earlier.

Secured Dynamic Update for Legacy Clients When a Windows 2000 DHCP server performs secure dynamic updates for its clients (such as Windows 9x and Windows NT), the DHCP server becomes the owner of that name, and only that DHCP server can update the name. This can cause problems in some scenarios, such as multiple DHCP servers sharing the same subnet, or in the case of Windows 2000 upgrades. If secure dynamic update is configured to be performed by DHCP servers, it is recommended to place these DHCP servers in a special Windows 2000 global group called DNSUpdateProxy. Any updates performed by the DNSUpdateProxy group have no security, so any authenticated user can take ownership. To add a DHCP Server to the DNSUpdateProxy group, perform the following steps: 1. Open Active Directory Users and Computers. 2. Expand the domain node, and the Users folder. 3. In the details pane, right-click the group and click Properties. 4. Click the Members tab, and then click Add. 5. Click Look In to display a list of domains for adding users and computers from other domains. 6. Click the server to be added and then click Add.


219

CAUTION Running a DHCP server on a domain controller when the DHCP server updates client DNS records can compromise secure dynamic updates. Also, the DHCP server would have full control of DNS objects stored in the directory. For these reasons, DHCP servers should not be deployed on domain controllers if the secure dynamic updates option is preferred.

The Windows 2000 DNS client accepts responses from unqueried DNS servers. Although this process enhances performance, it exposes a security risk when unauthorized DNS servers confuse the clients with incorrect resolutions. This default setting can be disabled by the addition of a registry entry to the Windows 2000 machine. To perform this, change the following key: QueryIpMatching

with the value 1 (REG_DWORD) to the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters

Resolving Name Conflicts When a client attempts to dynamically register its DNS information, it may discover that the hostname is already registered in the DNS with a different host’s IP address. In this scenario, the client tries to replace the current registration with its own IP address. If the zone is not configured for secure dynamic update, any user on the network can modify the IP address registration of any client computer. If the zone was configured for secure dynamic update, only authorized users could possibly modify the resource record. The default setting can be configured so that instead of trying to replace the IP address, the client avoids the registration process and logs the error in Event Viewer. In the Registry, add the DisableReplaceAddressesInConflicts entry with a value of 1 (DWORD) to the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

The entry can be 1 or 0, which specifies one of the following: 1

No client overwrite. Error in log.

0

Default client overwrite.


DNS Client Security

220

So it is very important to note that, by default, if the secure DNS update is not being used, the last client update wins. This is necessary to take care of the common scenario in which a client can acquire a new IP address and would like to register the same. This can be a potential security issue because it leads to spoofing and other hacking attacks.

Controlling Update Access to Zones With secure dynamic update, only the computers and users listed in an ACL can create or modify objects within the zone (DnsNode objects). By default, the ACL gives Create permission to all members of the Authenticated Users group, which allows any authenticated user or computer to create a new zone object. Any new DnsNode objects are owned by the creator, who also has Full Control permissions. DNS object permissions can be verified and changed in the following three manners: • On the Security tab for the object • Using the Active Directory Users and Computers MMC • Using the DNS console for zone or record properties To modify the security for a zone or resource record using the DNS console, perform the following steps: 1. In DNS Manager, right-click the applicable zone or resource record, and select Properties. 2. On the Security tab, modify the list of users or groups that are allowed to securely update the applicable record. 3. Reset any user or group permissions, and click OK.

Securing Zone Transfer Traffic Between DNS Dynamic Update Servers For Active Directory–integrated zones, DNS data is automatically replicated to all other DCs in the domain using Remote Procedure Call (RPC) protocol. The data is also encrypted with a 56bit (international) or 128-bit (within North America) key.

NOTE Zone transfers from Windows 2000 DNS servers to BIND DNS servers, or between Windows 2000 DNS servers without Active Directory–integrated zones, are not secure.


221

The dynamic update client automatically unregisters name–to–IP address mappings whenever the DHCP lease expires. This is a default setting in Windows 2000. However, the client can be configured not to register its name and IP address in DNS. To prevent the client from registering name–to–IP address mappings, perform the following steps: 1. Right-click My Network Places in Control Panel. 2. Right-click the connection where registration needs to be disabled, and select Properties. 3. Click Internet Protocol (TCP/IP), and then click Properties. 5. Clear the check box Register This Connection’s Address in DNS. Re-registration can be configured using the command-line tool Ipconfig. For Windows 2000–based clients, type the following at the command prompt: ipconfig /registerdns

For Windows NT 4.0–based clients, type the following: ipconfig /release ipconfig /renew

For Windows 9x–based clients, type the following: winipcfg /renew

Summary This chapter addressed the new security features in Windows 2000, Active Directory, and DNS, including Kerberos authentication. Although NTFS permissions still apply to Windows 2000 objects, authority can be delegated to approved users who are not members of an administrative group. This eases administrator responsibility and allows for local “control” of resources. It is also important to note that while Microsoft attempts to implement more security in DNS, there are some scenarios that exploit these options. Consider DNS security and the need for dynamic updates carefully.


4. Click Advanced, and select the DNS tab.

Windows 2000 DNS and WINS Replication

IN THIS CHAPTER • DNS Replication

224

• Replication Topology

228

• Managing Zone Transfers

230

• WINS Configuration, Replication, and DNS Integration 230 • WINS and DNS Integration • Summary

244

238

CHAPTER

8

224

Windows 2000 introduces a new replication model that encompasses directory synchronization among domain controllers in Active Directory. This replication model transcends to Active Directory–integrated zones, but not standard primary and secondary DNS zones. DNS integration with WINS is another feature of Windows 2000, as it migrates from the NetBIOS namespace. Because most Windows NT 4.0 environments continue a reliance on NetBIOS names for applications or services, WINS may remain for a short time before being phased out. This chapter focuses on replication (both with DNS and WINS), as well as WINS integration.

DNS Replication Replication of DNS in Windows 2000 is performed using one of two methods, depending on the DNS implementation: • Active Directory replication • Zone transfers to secondary name servers As implied, Active Directory replication is used for Active Directory–integrated zones. This model uses AD domain controllers for multimaster replication throughout the domain. The zone transfer is based on standard DNS zones and allows for replication with third-party DNS implementations such as BIND. Let’s take a closer look at these two replication models and their requirements.

Active Directory Replication The Active Directory replication model is multimaster among domain controllers. Each domain controller in a forest stores a copy of directory components called directory partitions. Site topology determines when and where replication of these directory partitions occur. These are some of the advantages of Active Directory replication: • Multimaster updating • Quick and efficient replication • Secure dynamic updates using Kerberos

NOTE Active Directory–integrated zones are currently supported only on Windows 2000 DNS servers that are also domain controllers.

Windows 2000 DNS and WINS Replication CHAPTER 8

225

Active Directory Partition Replicas A directory partition replica can be a full (master) replica or a partial replica. A full replica contains all attributes of all directory partition objects and is both readable and writable. Each domain controller stores at least three full, writable directory partition replicas. These are the partitions: • Schema (one per forest) • Configuration (one per forest) • Domain (one per domain) The schema partition contains all class and attribute definitions for the forest. The configuration partition contains replication configuration information (and other information) for the forest. The domain partition contains all objects that are stored by one domain (such as Active Directory DNS data).

NOTE Because the Active Directory database remains within the AD domain, the Active Directory–integrated zone is limited to the AD domain.

As illustrated in Figure 8.1, global catalog servers for the forest host partial replicas of domain objects from the different domains. In this example, the forest consists of nonhierarchical domains (assuming a merger or the like). A subset of domain data from kevinkocis.com is copied to the north-rim.com domain, and vice versa. This process enhances search capability while minimizing referrals from one domain controller to another.

NOTE Remember, a global catalog can be hosted only on a domain controller.

WINDOWS 2000 DNS AND WINS REPLICATION

A full replica of a domain’s partition is stored on every domain controller in the domain. A full replica of a forest’s configuration and schema partitions is stored on every domain controller. A partial replica (which is stored only on global catalog servers) contains a subset of the attributes of all directory partition objects and is read-only. Each domain controller hosts a single database that stores copies of those objects specific to that domain, in addition to copies of the forest’s schema and configuration objects, as illustrated in Figure 8.1.

8

226

north-rim.com partitions

kevinkocis.com partitions

Schema

Schema

Configuration

Configuration

north-rim.com domain

kevinkocis.com domain

kevinkocis.com domain

north-rim.com domain

FIGURE 8.1 Global catalog servers from two domains and their respective replicas.

At least one global catalog is located in every forest. However, it is recommended to place a GC server in each site for logon and replication purposes. The initial global catalog is automatically created when the first domain controller is installed in the enterprise. A global catalog stores and replicates the following: • Schema information • Configuration information • Local domain directory objects and all their properties • A subset of the domain properties for all directory objects in the forest (replicated between global catalogs only)

CAUTION In a large enterprise with multiple domains, global catalog replication and synchronization can cause significant network traffic.

Enterprise Replication Replication becomes more complex as domain controllers and domains are added to the enterprise. We will illustrate the developing complexity in the following sample scenario. After Sams Publishing registers its domain (samspublishing.com), it sets up an initial domain controller, called dc1. The FQDN is dc1.samspublishing.com. This domain controller obviously resides in the samspublishing.com domain, and it acts as the global catalog server. At this point, no replication is necessary.


227

When a second domain controller (dc2) is added to the domain, replication begins. Although dc2 is not a GC server, the domain controllers still replicate all directory objects and properties for the domain, as well as the schema and configuration information. This same process occurs as more domain controllers are added to the same samspublishing.com domain. When a child domain (books) is added to samspublishing.com, the replication process becomes more complex. The books.samspublishing.com domain contains two domain controllers like its parent domain. One of the domain controllers (dc1) is also configured as a GC server. The data replicated between the two domain controller/GC servers are shown here (and illustrated in Figure 8.2): •

samspublishing.com

schema

•

samspublishing.com

configuration

• subsets of the samspublishing.com and books.samspublishing.com domain information

8 Directory

Global Catalog Server

Global Catalog Server

samspublishing.com domain

books.samspublishing.com domain

domain controller

domain controller

domain controller

domain controller

Schema and configuration data Domain data Domain subset data (transferred between domains)

FIGURE 8.2 Active Directory replication between two domains, each with a global catalog server.

NOTE If only one global catalog for the forest existed in samspublishing.com, a subset of the directory objects and properties from books.samspublishing.com would be copied to it. However, no domain information would be necessary to replicate to the books domain. Also, only global catalog servers in the same forest will replicate with each other.


Directory

228

Replication Topology The replication topology in Windows 2000 Active Directory is quite complex, and could constitute a chapter in itself. Various components and factors create a positive replication topology. Let’s begin with the protocols.

Transports and Protocols Windows 2000 directory replication requires the use of specific network protocols. These protocols are the Internet Protocol (using remote procedure calls) and Simple Mail Transfer Protocol (SMTP). RPC over IP replication is compressed and used typically within a site. SMTP replication is compressed and used only when replicating between Active Directory sites. IP replication uses Remote Procedure Calls (RPC) for replication within a site (intra-site), as well as over reliable, high-speed site links (inter-site). RPC over IP replication does not require a certification authority (CA). SMTP replication is used only for replication between sites and is not supported for replication between domain controllers in the same domain. SMTP replication can be used only for schema, configuration, and global catalog partial replica replication. When SMTP replication is configured over site links, an enterprise certification authority must be installed and configured. The certification authority provides certificates to domain controllers, which are used to sign and encrypt mail messages containing directory information. The CA ensures the authenticity of directory updates using 56-bit encryption.

Update Tracking Replication of updates is triggered when a user, an application, or a service updates an object. Following the update, other updates are recorded for a set period. The replication engine then notifies other domain controllers within the site or domain. Some directory services use timestamps to detect and propagate changes. In these situations, it is critical and challenging to maintain time synchronization across Active Directory domain controllers. The Active Directory replication system uses Update Sequence Numbers (USNs) as opposed to time synchronization. A USN is a 64-bit number maintained by each Active Directory domain controller to track updates. When the server writes to any attribute, or property, on an Active Directory object, the USN is increased and stored with the updated property. Each Active Directory domain controller also maintains a table of USNs received from replication partners. The highest USN received from each partner is stored in this table.


229

Secondary Zone Replication Secondary zone replication, despite its lack of security controls and support of secure dynamic updates, offers more interoperability with existing and third-party DNS implementations. The drawback to secondary zone replication is that it requires more planning and configuration than Active Directory–integrated zones.

Planning Secondary Zone Replication Secondary zone replication can occur from any zone on any DNS server (including an Active Directory–integrated zone). Secondary DNS servers can “pull” zone information from other secondaries, as illustrated in Figure 8.3.

Primary DNS server (dns1)

Secondary DNS (dns2)

Secondary DNS (dns3)

FIGURE 8.3 Secondary zone replication.

In this figure, two secondary DNS servers (dns2 and dns3) pull zone data from the primary DNS server (dns1). One secondary (dns3) pulls from the other (dns2) in the case of an outage on dns1. Although this is not an optimal replication configuration, it illustrates how standard DNS servers can obtain zone data. Only one primary name server should be configured for a zone. Although it is possible to configure multiple servers for the same primary zone, this will result in failures in the case of dynamic updates (when multiple updates are sent to different primary servers). Although implementing multiple primary servers for the same zone is never recommended, it can be achieved if the zone is relatively static and easily manageable. However, this configuration offers minimal gain over implementing more secondaries, and also exposes opportunities for errors.


samspublishing.com zone

8

230

Managing Zone Transfers Zone transfers are controlled on a per-zone basis and occur automatically (as defined in the SOA resource record interval field), but they can also occur manually by an administrator using the DNS management console. In Windows 2000 DNS, after a standard secondary zone is created, the DNS server for the standard primary zone will update the new standard secondary with its zone data. Following replication, the secondary server will verify with the primary zone server at regular intervals (also defined in the SOA record) to determine whether there are any changes to the primary zone. During this process, the secondary checks the primary’s zone version number. If the version number is greater than its own, a zone transfer is required. The secondary then requests a zone transfer.

Incremental Zone Transfers As mentioned earlier in the book, incremental zone transfers are new to Windows 2000 DNS. This process involves transferring only the zone changes as opposed to the entire zone, which reduces network traffic. With incremental zone transfers, the differences between the source and replicated versions of the zone are first determined. If the zones are identified as the same version, as indicated by the serial-number field in the SOA record of each zone, then no transfer is made. Windows 2000 holds the incremental zone transfer information for each zone in a text file \Winnt\system32\dns folder whose name is based on the name of the file holding the zone data (which was specified when the zone was defined). For example, if the zone information for the kevinkocis.com zone is held in the file kevinkocis.com.dns, the incremental update log is held in kevinkocis.com.dns.log.

WINS Configuration, Replication, and DNS Integration Although Windows 2000 primarily uses DNS for name resolution, it also supports Windows Internet Name Service (WINS). WINS is used for name resolution in pre–Windows 2000 Microsoft systems that utilize flat NetBIOS naming conventions. WINS provides a dynamic replicated database service that registers and resolves NetBIOS names to IP addresses.

WINS Server Installation Like any server or business-critical workstation, the WINS server should be assigned a static IP address.


231

To install a WINS server, perform the following steps: 1. In Control Panel, click Add/Remove Software, and select Add/Remove Windows Components. 2. Under Components, select Networking Services, and click Details. 3. Under Subcomponents of Networking Services, click Windows Internet Name Service (WINS), and then click OK. 4. If necessary, enter the path to the required Windows 2000 files (such as the Windows 2000 Server CD) and click Continue.

NOTE The Windows 2000 WINS console supports and manages Windows NT 4.0 WINS servers as well, unlike Windows NT 4.0 DNS servers, which are not supported through the DNS console.

1. Open the WINS console, and right-click the WINS container. 2. Select Add Server. 3. Enter the WINS Server information or click Browse to locate the server on the network (as shown in Figure 8.4). Click OK. 4. Repeat adding servers as necessary, and then save the console.

FIGURE 8.4 Adding a Windows NT 4.0 WINS server to the WINS 2000 MMC.

WINS Configuration This book and this chapter in particular are not intended to serve as a comprehensive guide to WINS. As with other databases, you must periodically maintain the WINS database to remove outdated information, including performing proper and regular backups.

8 WINDOWS 2000 DNS AND WINS REPLICATION

To configure a WINS server, the user must be a member of the server’s Administrators group. By default, the local WINS server is added to the console automatically. To add additional WINS servers to the console, perform the following steps:

232

However, some critical configurations are required to ensure data consistency and redundancy, including the following: • Database consistency • Backups • Recovery • Replication • Integration with DNS

Database Consistency and Verification WINS database consistency checking helps maintain database integrity among WINS servers. WINS consistency checking pulls the records from each owner listed in the current server database, including indirect WINS replication partners. The collected records are then compared to records in the local database, using version IDs and timestamps. WINS then completes the name verification check by querying all the WINS servers and ensuring that all the database name mappings are consistent. This process is repeated until all listed names have been checked at all listed servers. The results of all queries are then displayed in Checking Name Registrations. Consistency checks in Windows 2000 are enabled and scheduled through the WINS console. In Windows NT 4.0, consistency checking had to be enabled either through registry modifications or through use of the WINSCL utility, included in the Windows NT 4.0 Server Resource Kit. Consistency checking is not enabled by default because this feature may significantly impact WINS server performance. For example, if the enterprise hosts a large WINS database, this process will prove very resource intensive on network, disk, and processor usage. For this reason, consider performing consistency checks during off-peak hours.

NOTE The default settings for this enabled feature provide for up to 30,000 records in the WINS server database to be checked daily, starting at 2 a.m.

To enable periodic consistency checking of the WINS database, perform the following steps: 1. In the WINS console, right-click the WINS server, and select Properties. 2. Click the Database Verification tab.


233

3. In Database Verification settings, select the Verify Database Consistency Every X Hours check box (as shown in Figure 8.5). 4. If necessary, modify the default settings to be used when consistency checks are performed.

8 Configuring the Database Verification settings.

To manually check database consistency, perform the following steps: 1. In the WINS console, right-click the WINS server, and select Check Database Consistency. 2. When asked whether to continue, click Yes to start consistency checking. Version-number consistency checks the consistency of the WINS databases at all WINS servers by ensuring that each server always has the highest version ID for any records it owns. To check version-number consistency between servers, perform the following steps: 1. In the WINS console, right-click the WINS, and select Check Version Number Consistency. 2. When asked whether to continue, click Yes to start this operation. Scavenging and Tombstones Scavenging is the process of deleting and removing obsolete information from the WINS server database. After changes occur, the local WINS server database may hold onto old entries registered at another WINS server and replicate this old data to the local WINS server. Scavenging removes these old and released entries.


FIGURE 8.5

234

NOTE WINS automatically begins the scavenging process at the interval specified in the server properties dialog box. To manually scavenge the WINS database, right-click the WINS server in the WINS console, and select Scavenge Database.

WINS now provides improved database management through support for the following deletion operations: • Simple deletion • Tombstoned deletion • Multiple-group selection for either simple or tombstoned deletion Simple deletion is used for deleting WINS database records stored on a single server database, whereas tombstoned deletion is used for deleting WINS database records replicated to databases on other WINS servers. When records are deleted on a local server, but those records are replicated to other WINS servers, the deleted records remain on the servers as tombstones. The multiple-group selection, as the name implies, allows for the deletion of multiple database records whether simple or tombstoned deletion. Tombstoning marks the deleted records as tombstoned, and keeps these records in the server database to notify the other servers through replication. During replication, the tombstone records are updated and applied on the other WINS servers. After all WINS servers complete the tombstone replication and the Verification Interval expires, WINS automatically removes the records.

CAUTION WINS records should be tombstoned at the local WINS server owning them. This prevents deleted records from reappearing through subsequent replication.

To delete or tombstone an entry in the WINS database, perform the following steps: 1. In the WINS console, expand the WINS server, and right-click Active Registrations. 2. Select either Find by Name or Find by Owner to display the names you want to delete from the database. 3. Select the entry or entries in the details pane (hold down the Ctrl or Shift key to select multiple entries). 4. On the Action menu, click Delete.


235

5. In the Delete Record dialog box, click one of the following options for deleting the selected records: • Delete the Record Only from This Server. Note: This may result in the record’s reappearance after a subsequent replication. • Replicate Deletion of the Record to Other Servers (tombstone).

WINS Backups As with any business-critical service or data, backups are required to ensure prompt restoration. The WINS console provides convenient WINS backup and restoration tools for this purpose. After the specifications have been configured for the backup process, complete database backups, by default, will occur every three hours (with the default save location as the root folder, that is, C:\). The WINS server can also be configured to perform backups when the service is stopped or the server is shut down. It is also recommended as part of the disaster recovery process to periodically back up the registry entries for the WINS server. Changing the default backup path for WINS affects backup and recovery options. Perform the following steps to ensure that backups and restorations are successful. To change the WINS database path, perform the following steps:

2. Click the Advanced tab (which is displayed in Figure 8.6). 3. In Database Path modify the database path, and click OK. 4. Perform a new backup, because previous archived database copies are obsolete after the path is changed.

FIGURE 8.6 The Advanced tab in the WINS server properties dialog box.


1. In the WINS console, right-click the WINS server, and select Properties.

8

236

CAUTION WINS cannot restore previously archived copies of the database under a different specified path. This applies to either the WINS database path or the WINS database backup path.

To modify backup settings, perform the following steps: 1. In the WINS console, right-click the WINS server, and select Properties. 2. On the General tab, under Database Backup, modify the default backup settings as needed. To manually back up the WINS database, right-click the WINS server in the WINS console, and select Backup Database. Click OK when the backup is complete.

CAUTION WINS cannot back up to or restore from a network drive. Also, if the WINS backup or database path is changed in the server properties dialog box, perform new backups to ensure successful future restores of the WINS database.

Recovery Recovery, or restoration, of the WINS database can be achieved only when the WINS service is stopped. This process may require a refresh to activate the restore option after WINS has been stopped. If necessary, click Refresh from the Action menu, and then proceed with the restoration. To restore the WINS database, perform the following steps: 1. Stop WINS by right-clicking the WINS server and selecting All Tasks, Stop. Make sure that the service is stopped before proceeding. 2. Delete all files in the folder path on the WINS server computer where you are restoring the database. This path is determined by the current setting of Database Path, which is located on the Advanced tab in the server properties dialog box. 3. In the WINS console, right-click the WINS server, and select Restore Database. 4. In the Browse for Folder dialog box, click the same folder used to back up the local WINS database, and then click OK.


237

NOTE Before restoring a corrupt database, try repairing by incrementing the starting version count for the WINS server and then restarting the server.

WINS Replication WINS replication is configured in the WINS console. WINS replication partners are configured to be push/pull-type partners by default. After a replication partner is added, the replication type can be altered to be only push or only pull. To add a replication partner, perform the following steps: 1. In the WINS console, expand the WINS server, and right-click Replication Partners. 2. Select New Replication Partner, and enter the name or IP address of the WINS server to add as a replication partner. To delete a replication partner, perform the following steps: 1. In the WINS console, expand the WINS server, and right-click Replication Partners. 3. On the Action menu, click Delete. 4. When prompted, click Yes to confirm that you want to delete the partner. To change a replication partner type, perform the following steps: 1. In the WINS console, expand the WINS server, and right-click Replication Partners. 2. In the details pane, right-click the partner and select Properties. 3. Click the Advanced tab. 4. For Replication partner type, select a new type such as Push, Pull, or Push/Pull. To modify push or pull partner properties, perform the following steps: 1. In the WINS console, expand the WINS server, and right-click Replication Partners. 2. Select Properties. 3. Click the Push Replication tab or the Pull Replication tab. 4. Change the push or pull partner defaults as necessary, and click OK. If immediate replication is necessary, perform the following steps: 1. In the WINS console, expand the WINS server, and right-click Replication Partners. 2. Select Replicate Now. 3. When prompted, click Yes to start replication immediately.


2. In the details pane, click the replication partner you want to remove.

8

238

WINS and DNS Integration Windows 2000 DNS allows you to use Windows Internet Name Service servers to research names not found in the DNS domain namespace by checking the WINS database. WINS supports registration of dynamic mappings of NetBIOS names to IP addresses, and provides NetBIOS name resolution. WINS provides dynamic name resolution for the NetBIOS namespace, and it was required on all clients and servers before Windows 2000.

NOTE WINS is not required in a purely Windows 2000 environment, except in the case of cluster servers.

Following an upgrade to Windows 2000, WINS can be removed if the following conditions are met: • No clients or servers are using NetBIOS, including operating systems, services, and applications dependent on NetBIOS. • All Windows clients and servers are running Windows 2000 and using DNS as its locator service. DNS and WINS integration can be achieved with minimal complication because NetBIOS hosts can query a DNS server for a DNS hostname (such as UNIX). Subsequently, NetBIOS hosts can be assigned static IP addresses in DNS for resolution of UNIX queries. Also, WINS clients can continue to use WINS servers to resolve NetBIOS names (because WINS is still available, and enhanced, in Windows 2000 Server).

WINS Lookup Integration To use WINS lookup integration, the WINS and WINS-R resource records need to be added to the zone. When the WINS records are used, DNS queries that fail to find a matched host record in the zone are forwarded to WINS servers configured in the WINS record. For reverse lookup zones, the WINS-R record provides a similar benefit for resolving a query that does not receive a response from the reverse in-addr.arpa domain.

NOTE WINS lookup integration is common in a mixed-mode client environment in which UNIX clients use only DNS and earlier-version Microsoft clients require NetBIOS naming. Most enterprises running an NT 4.0 architecture have implemented WINS.


239

WINS lookup integration is supported only by Windows DNS servers, so if BIND servers are in service on the network, additional configuration is necessary to prevent duplication of WINS records.

CAUTION If a zone is configured for WINS lookup, all DNS servers authoritative for the zone need to be capable of WINS lookup or intermittent behavior may result.

Configuring WINS Resolution WINS resolution can be configured on both primary (Active Directory–integrated included) and secondary servers. To enable DNS to use WINS resolution, perform the following steps: 1. In DNS Manager, right-click the applicable zone, and select Properties. 2. Select either the WINS tab (for a forward lookup zone) or the WINS-R tab (for a reverse lookup zone). 3. Select the appropriate check box for WINS resolution: • Use WINS-R Lookup 4. Type the IP address of a WINS server. For the reverse lookup zone, enter a name in Domain to append to the returned name. 5. Click Add, and the IP address appears in the window list, as shown in Figure 8.7. 6. Repeat steps 4 and 5 as appropriate. 7. Select the Do Not Replicate This Record check box for this WINS record if applicable. If you are replicating this zone between other DNS servers that do not recognize the WINS or WINS-R resource records, click this check box. This option prevents these records from being replicated to these other servers during zone transfers. 8. Optionally, click Advanced to adjust advanced WINS lookup parameters.

An Example of WINS Lookup Suppose that a user at a client workstation issues the following command to another workstation running Windows NT 4.0: net use \\myhost.eur.north-rim.com.\shared


• Use WINS Forward Lookup

8

240

FIGURE 8.7 Configuring WINS lookup in the DNS console.

This command establishes a connection between the client workstation and the shared folder on the computer myhost.eur.north-rim.com. First, the domain name must be resolved by DNS. In this case, WINS must be referenced to provide an IP address. This process, illustrated in Figure 8.8, assumes that no cached resolution or forwarding is being provided by the servers involved.

.com

Recursive query process

north-rim.com Primary DNS server

eur.north-rim.com with WINS lookup enabled

client

FIGURE 8.8 A WINS lookup for myhost.eur.north-rim.com.

WINS server


241

1. The client queries the DNS server for myhost.eur.north-rim.com. 2. The query follows the recursive process through the DNS hierarchy from a root server down to an authoritative DNS server for the eur.north-rim.com domain. After the DNS server for the eur.north-rim.com zone receives the myhost query, it searches the zone for an A resource record. If no A resource record is found and the zone is configured to use WINS lookup, the server continues with the following process: 3. The DNS server separates the host part of the name (myhost) from the FQDN. 4. The DNS server sends a NetBIOS name request (myhost) to the WINS server. 5. On successful resolution, the WINS server returns the IP address to the DNS server. 6. The Windows DNS server forwards the IP address to the requesting client. 7. The client workstation establishes the session with myhost.eur.north-rim.com and connects to the shared folder. In this example, only the DNS server configured for WINS resolution had knowledge of WINS. The client and other DNS servers are oblivious to the WINS resolution process, and DNS appears responsible for the entire name resolution process. Further modification of IP address changes for myhost.eur.north-rim.com are automatically addressed by WINS.

WINS Lookup Interoperability Obviously, WINS lookup functions best with Windows DNS servers. However, there are options for WINS lookup as an interoperable solution when other DNS servers such as BIND exist in the enterprise. One option is to configure a Windows 2000 DNS server to host a WINS lookup-enabled zone, using a subdomain added to the existing DNS namespace (such as wins.eur.north-rim.com). This zone would be used specifically for WINS referrals in the DNS domain namespace. The wins.eur.north-rim.com WINS referral zone would serve as the root zone for any WINSbased systems with names not identified in the other traditional DNS zones.


Because the WINS database is not indexed by IP address, the DNS server cannot send a reverse name lookup to a WINS server to get the name of a computer given its IP address. For this reason, the reverse lookup with WINS integration works differently than a forward lookup. In this situation, the DNS server acquires the IP address from the network adapter and appends the DNS domain name specified in the WINS-R record to the hostname. This process of appending the domain suffix for WINS-R lookups is shown in Figure 8.9.

8

242

FIGURE 8.9 Appending the domain suffix for a reverse WINS lookup in the DNS console.

NOTE The WINS referral zone domain name (wins.eur.north-rim.com) must be specified in the client search list on the client machine. This can be configured manually or through DHCP.

For more information on WINS lookup interoperability with BIND DNS servers, see Chapter 9, “BIND and Windows 2000 Interoperability.”

Format of WINS and WINS-R Resource Records A WINS resource record has the following syntax: <domain> WINS [] ➥

The fields used with the WINS resource record include the following: domain class TTL Local

Always represented as @ Always represented as IN for WINS records Cache time limit before the record is discarded Specifies whether the record must be included in zone replication or is just local to the machine

Windows 2000 DNS and WINS Replication CHAPTER 8 LookupTimeout CacheTimeout WINSServers

243

Time in seconds a DNS server that uses WINS lookup waits before it gives up Time in seconds a DNS server that uses WINS lookup can cache the response from the WINS server List of WINS server IP addresses to be used

The following is an example of a WINS resource record: @

IN

WINS LOCAL 3 3600 192.168.1.2

A WINS-R resource record has the following syntax: owner class WINS [LOCAL] [L] [C] ➥<wins_ip_addresses>

The fields used with the WINS-R resource record are consistent with those used with the WINS resource record. The following are examples of WINS-R records: @ IN

WINS-R LOCAL L1 C10 eur.north-rim.com.

@ IN

WINS-R wins.eur.north-rim.com.

Two following advanced timing parameters are used with the WINS and WINS-R records: • Cache timeout value • Lookup timeout value These values are configured via the Advanced button in the zone properties on either the WINS or the WINS-R tab, as shown in Figure 8.10. The Cache Time-out value indicates to a DNS server how long it should cache any of the information returned in a WINS lookup. By default, this value is set to 15 minutes.

NOTE The SOA TTL value is not applicable to WINS and WINS-R records. Instead the cache timeout value determines the TTL for cached values.

The Lookup Time-out value specifies how long to wait before timing out and expiring a WINS lookup performed by the DNS Server service. By default, this value is set to 2 seconds.


Advanced WINS Lookup Parameters

8

244

FIGURE 8.10 The Advanced WINS lookup values.

Summary Windows 2000 Active Directory uses multimaster replication to copy directory data to all domain controllers. Directory data consists of three partitions: schema, configuration, and domain. The schema and configuration partitions are fully copied, whereas the domain partition is copied in full only to other domain controllers within the domain. A partial replica is copied to other domain controllers in the enterprise. The domain partition contains the DNS information. Windows 2000 also still supports WINS for integration purposes. The WINS MMC can manage Windows NT 4.0 WINS servers as well as Windows 2000 WINS servers. WINS replication is significantly different from AD replication, because it focuses on push/pull partners, which can be customized to accommodate the network and server topology.

CHAPTER

BIND and Windows 2000 Interoperability

9

IN THIS CHAPTER • Understanding BIND

246

• Comparing BIND and Windows 2000 DNS File Types 247 • Integrating BIND with Windows 2000 DNS 250 • Integrating Windows 2000 DNS with BIND 253 • Disadvantages and Considerations • Summary

264

262

246

Integrating BIND and Windows 2000 DNS may be one of the greatest challenges of implementing Active Directory into current enterprises. Active Directory requires DNS, and obviously favors Windows 2000 DNS. However, organizations with BIND implementations will be resistant to transition to Windows 2000 DNS, based on its popularity and Microsoft’s previous struggles with its DNS product.

Understanding BIND As noted earlier in the book, Berkeley Internet Name Domain (BIND) was the earliest implementation of DNS. BIND remains very common on the Internet working on such platforms as Linux and UNIX. BIND is a complex and robust DNS server, with many features that are not included in Windows 2000 DNS. BIND comes in several flavors or versions: • BIND 4 • BIND 8 • BIND 9 For the sake of this chapter, we will focus on versions 8 and 9. Although BIND 4.9.6 meets the minimal requirements for integration with Active Directory, it does not possess some strong enhancements found in later versions that can ease the integration process. We will discuss these differences later in the chapter.

BIND History BIND was originally written in the early 1980s at the University of California at Berkeley by a group of graduate students under a project grant from the US Defense Advanced Research Projects Agency (DARPA). Versions of BIND through 4.8.3 were maintained at UC Berkeley. In the late 1980s, Digital Equipment Corporation (DEC) released BIND versions 4.9 and 4.9.1, and one of its employees, Paul Vixie, took over BIND’s development. Forming his own company, Vixie Enterprises, Paul released version 4.9.2. The Internet Software Consortium released and supports BIND versions 4.9.3 and later. However, BIND version 4 is no longer officially supported now that BIND versions 8 and 9 have become more common and recommended. BIND is now supported on most versions of UNIX, Linux, and even Windows NT/2000.

BIND Configuration Files BIND versions 8 and 9 use a two-level file hierarchy when defining zones. The first level consists of the named.conf file, usually located in the /etc directory on a UNIX server. The named.conf file (pronounced “name-dee”) gets its nomenclature from the DNS server

BIND and Windows 2000 Interoperability CHAPTER 9

247

application named, which is short for name daemon. On UNIX platforms, many services are referred to as daemons (pronounced “demons”). The named.conf file contains information regarding general DNS configuration characteristics, such as defining zone(s) hosted by the name server and the source domain database file for the zone. The second level consists of the actual zone text files stored on either primary or secondary DNS servers. These files include the forward lookup zone file, the reverse lookup zone file, the cache file, and the loopback file. Table 9.1 documents the name associations for each file. TABLE 9.1 BIND Zone Text Files Name

Description

Named.conf db.domain_name

Boot file (formerly named.boot). Forward lookup zone. If the DNS domain is kevinkocis.com, this file is called db.kevinkocis.com. Reverse lookup zone. If the network is the class C network address 195.19.1, this file is called db.195.19.1. Root hints file that contains the names and IP addresses for the root DNS domain name servers. File for loopback address resolution on the local server.

Db.x.y.z Db.cache db.127.0.0.1

The forward lookup zone file uses the domain name with the db prefix (for example, db.kevinkocis). The reverse lookup zone file uses the network IP address with the db prefix, such as db.195.19.1 for a network with an IP network address of 195.19.1.

Comparing BIND and Windows 2000 DNS File Types Unfortunately, the naming systems for file types are not constant between BIND and Windows 2000 DNS. Their nomenclature is based on the specific server configuration. Windows 2000 DNS server uses the .dns suffix as opposed to the db prefix. However, for porting purposes, Windows 2000 DNS server can be configured to interpret BIND DNS db files.

9 BIND AND WINDOWS 2000 INTEROPERABILITY

The named.conf is the UNIX boot file located in the UNIX /etc directory. In BIND versions earlier than 8.x, this file was called named.boot and used a different format. A PERL script called named-bootconf in BIND 8.2 can convert older named.boot files to named.conf files without incident. The BOOT file, used only by BIND servers, is not specified in the DNS standards.

248

Table 9.2 shows examples of how BIND server files are renamed for use with the DNS service provided in Windows 2000 Server. TABLE 9.2 BIND File Renaming for Windows 2000 DNS Description

UNIX Filename

Windows 2000 Filename

Boot file Forward lookup zone file Reverse lookup zone file

named.boot db.domain_name db.x.y.z

Boot domain_name.dns z.y.x.dns

Windows 2000 DNS servers, however, use the fully qualified domain name (FQDN) for the zone, which includes the in-addr.arpa domain, to complete the filename. For example, for the class C network 192.1.10, the correct name to use for the same zone in Windows 2000 Server is 10.1.192.in-addr.arpa.dns when copying and renaming the file (as shown in Figure 9.1).

FIGURE 9.1 The reverse lookup zone file (10.1.192.in-addr.arpa.dns) on the Windows 2000 server in the C:/winnt/system32/dns directory.


249

BIND Security BIND also maintains an adequate security mechanism, featuring more granularity on IP address and subnet restricting than Windows 2000 DNS. On the other hand, Windows 2000 DNS features more granular rights and permissions through its security model. In BIND, administrators can secure transactions, including DNS queries and responses, plus zone transfer requests and dynamic updates from unauthorized addresses. BIND 8.2 introduced DNS Security Extensions, called DNSSEC (RFC 2535), which treats resource records as “sets” maintaining the same TTL instead of individual records. DNSSEC introduced a new security feature for DNS messages called transaction signatures, or TSIG, as documented in RFC 2845. TSIG is a “meta-record” that does not appear in zone data and is never cached by a resolver or name server. The TSIG record is added to a DNS message (when it has been configured on the appropriate name servers), and the recipient removes and verifies the record before performing any other functions, such as caching. The TSIG record also includes a time-stamp feature for security. The dnssec-keygen program included in BIND 9 and the dnskeygen program in BIND 8 allow for TSIG configuration. BIND 8 and 9 allow administrators to apply IP addresses–based access control lists (ACLs) to queries, including ACLs applicable to a specific zone, or even zone transfer. Any authoritative name server, primary or secondary, can apply ACLs, which restrict access through security permissions.

NOTE Although DNSSEC is based on TSIG, this security is not compatible with the GSS-TSIG feature in Windows 2000 Kerberos security. Understand that each security is acceptable, but they are incompatible when integrated.

• SIG—Holds a digital signature. • KEY—Holds a public key. • NXT—Indicates data present and the span of missing names. • TSIG—Holds a message signature (not stored in file or cache). • CERT—Holds public key certificates (such as PGP).

BIND AND WINDOWS 2000 INTEROPERABILITY

Other DNSSEC resource records not supported by Windows 2000 DNS include the following:

9

250

Integrating BIND with Windows 2000 DNS When AD is being integrated into an existing DNS infrastructure, staff discussions need to focus on whether the Active Directory namespace will join, overlap, or trump the existing DNS namespace (if any). In larger corporations, chances are that Active Directory will be designed to integrate into the existing DNS infrastructure. Let’s take a closer look at the options for integrating Windows 2000 into an existing current DNS. These are the three options for integrating Active Directory into an existing DNS infrastructure: • Implement Microsoft DNS in Active Directory and replace current DNS services. • Integrate UNIX DNS structure into the DNS required for Windows 2000. • Maintain UNIX DNS structure with Windows 2000. We’ll explore these options in further detail momentarily. Your option will depend on variables including your current DNS infrastructure and specifications, as well as the many pending political issues. Microsoft believes strongly that the following features of Windows 2000 DNS make it a good choice for corporations looking to implement a reliable hierarchical distributed network environment: • AD integration • Incremental zone transfer • Dynamic update and secure dynamic update • Unicode character support • Enhanced domain locator • Enhanced caching resolver service • Enhanced DNS Manager • Record scavenging Remember that some of the UNIX Internet DNS servers in your environment are currently stable and secure. Add to this the fact that many UNIX administrators feel that Microsoft tends to “alter” existing technologies and preface them with their name (for example, Microsoft TCP/IP, Microsoft DNS) and this concern can be validated.

Implement Windows 2000 DNS to Replace Current DNS Implementing proprietary Microsoft DNS with Active Directory is Microsoft’s obvious choice. If the enterprise is committed to redesigning DNS infrastructure around Windows 2000 Active


251

Directory, this is the appropriate choice. This option may also be recommended if the enterprise hosts older UNIX machines running legacy versions of BIND (such as 4.x) and feels that the upgrade process is not worthwhile based on the impending shift to Active Directory. A final consideration for this implementation may be if the enterprise already uses Windows NT 4.0 DNS. The upgrade path from NT 4.0 DNS is relatively easy, as documented in the next section.

Upgrading to Windows 2000 DNS from NT 4.0 DNS The upgrade process from an existing NT 4.0 DNS server is simple and issue free, because server zone and configuration files are stored in the same system folder locations in Windows NT and 2000. The upgrade requires no data conversion or file renaming and relocation as in a BIND conversion (covered in the next section). As with any DNS implementation, the number of domain controllers per domain will depend on fault tolerance, network availability, or redundancy and load distribution requirements. Before performing any in-place upgrade, make sure that a successful recent (preferably immediate) backup has been completed. Also, make sure that existing hardware and software are supported by referring to the Hardware Compatibility List (HCL) for Windows 2000 on the Windows 2000 Server CD. Then insert the CD and follow the setup instructions.

Migrating to Windows 2000 DNS from BIND When migrating UNIX DNS servers to the Windows 2000 DNS, administrators have two primary options: • Zone file transfer via FTP • Zone file transfer via DNS zone transfer

Also, if Windows 2000 DNS will continue to use a BIND boot file to provide the initial configuration settings used by the DNS service when it is started, the boot method of the DNS service will need to be changed to point to the boot file. For more information on changing the DNS boot process, see the section “Load Zone Data on Startup Options” in Chapter 6, “Administering DNS Servers Using MMC.”


The zone files can be transferred via the file transfer protocol (FTP) from BIND servers to Windows 2000 DNS servers. In this scenario, the administrator can FTP the forward and reverse zone files from the UNIX server (db.xxx files located in etc/named.boot or etc/named.conf, depending on the BIND version) to the %systemroot%\winnt\system32\dns directory on your Windows 2000 DNS server and appropriately renamed with the .dns suffix from the db.xxx prefix format. Then, the file can be used for configuring the new zone, as shown in Figure 9.2.

252

FIGURE 9.2 Using the existing zone file (north-rim.com.dns) after it was migrated to the Windows 2000 DNS server.

The zone files can also be transferred through a standard DNS zone file transfer. A BIND server already configured authoritative for the zone can transfer the zone files to a Windows 2000 secondary server. To migrate from BIND-based server zones to Windows 2000 DNS servers, perform the following steps: 1. Install the DNS server on the Windows 2000 Server. 2. In the DNS Manager, add secondary zones for all of your existing zones hosted at the BIND-based DNS servers. (The BIND servers should already be masters for the secondary zones. If not, make sure that they get configured.) 3. Initiate a zone transfer from the Windows 2000 DNS server(s) to transfer the zones from the BIND server(s). 4. Verify that the transfers occurred without errors, which may result if the Windows 2000 DNS server cannot recognize resource records sent by the UNIX DNS server. Either repair or remove the records from the zone for the transfer to occur correctly. 5. Convert any of the secondary zones to primary zones that were obtained from primary zones at the BIND servers. 6. For the other secondary zones, update the master servers for those zones to use the new primary servers running Windows 2000 Server. After the files have been transferred, the secondary zones can be upgraded to Active Directory–integrated zones. The SOA resource record will need to be updated to one of the Active Directory–integrated DNS servers. Subsequently, the remaining UNIX DNS servers can be terminated from the network to avoid duplicate SOA records for the same zone.


253

NOTE A disadvantage of Active Directory–integrated zones is that they must be stored on domain controllers in the same domain. If the zone data must cross domains, secondary zones are required on DNS servers outside the domain.

Integrating Windows 2000 DNS with BIND You can integrate your current DNS structure into the DNS required for Windows 2000. If your current DNS meets the recommended requirements for Windows 2000 and you have tested dynamic updates, you can integrate it with Active Directory. This includes BIND 8.2.2 and higher, as well as Novell’s NetWare 5.x. Remember that BIND 4.9.6 and 4.9.7 meet the minimum requirements. However, BIND 8.x does support dynamic updates, and it is strongly recommended to update to this version before integrating with Active Directory. The advantage to integrating your current DNS structure into Windows 2000 DNS is that less administrative effort is required to implement it. Your company can maintain current equipment and infrastructure. UNIX and NT administrators can cohabitate, and you can focus on your Windows 2000 implementation as opposed to fighting the DNS war. A disadvantage to supporting Windows 2000 and Active Directory in a legacy BIND environment is that many UNIX DNS servers are running BIND 4.x and this may create a crossroads situation: upgrade or convert. The possible increase in future administrative overhead and manual data entry may be an issue. There will also be a single point of failure for dynamic registrations.

NOTE

BIND as Root DNS Another option is to supplement the current DNS structure with Windows 2000. If the internal root DNS servers do not host recent BIND versions, and issues have been minimal, the enterprise may elect to maintain this infrastructure. In many large organizations, the DNS servers are not equipped to support the DNS requirements for deploying Active Directory. This issue can be resolved by upgrading BIND DNS servers to version 8.2.2 or later, or replacing the BIND DNS service with Windows 2000 DNS servers.


BIND DNS servers do not support Active Directory–integrated zones, because they are limited to primary and secondary zones.

9

254

If the existing (or recently upgraded) BIND root DNS supports Active Directory requirements, it can delegate a new Windows 2000 DNS namespace that corresponds to the Active Directory root domain.

NOTE Delegation of a new namespace for the Active Directory domain is recommended to maximize the client benefits of using the Windows 2000 DNS server. However, existing DNS servers support SRV records, and dynamic updates do not require an Active Directory namespace delegation.

One advantage of this option is that initial integration efforts will be minimized, because the physical DNS infrastructure requires minimal changes. Because your current DNS root is UNIX-based (north-rim.com), you can configure a subdomain (w2k.north-rim.com) and create a new zone strictly for your Windows 2000 clients. Another advantage is that you reduce Active Directory’s dependence on your current DNS and avoid any potential incompatibility problems. A disadvantage to this option is that it requires a separate namespace for Windows 2000 logons. This may increase administrative overhead in the long run, including managing dual DNS services. However, companies running DNS on BIND are familiar with distributed or “localized” DNS support, so hierarchical support of DNS as mentioned in this option is quite common already. As a result, many companies will likely opt for this integration solution. If you are using the BIND boot file with the DNS service after migration, there are other limitations that apply to the use of this file by the DNS service. For example, some BIND boot directives are not supported—in particular, xfrnets and DNS security extensions provided with versions of BIND, such as version 8.1.1 or later.

NOTE Xfrnets restrict zone transfers from the primary name server to a list of secondary name servers using an IP list or network address.

When manually editing DNS zone files, be aware that the DNS service uses RFC-compliant notation for its supported resource records. In most cases, the DNS service interprets and loads records from zone files originally created for BIND DNS servers without any need for file changes. If, however, you have used nonstandard record formatting, the DNS service can detect these edits and interpret them as bad or erroneous zone data.


255

Although the integration of Active Directory can succeed with non-Microsoft DNS servers (for example, BIND 8.2.2), Microsoft strongly recommends that you use Windows 2000’s DNS server because it adds several features to the standard RFCs that are not necessarily found in non-Microsoft DNS servers. These features include integration with WINS, dynamic registration of down-level clients with the help of Windows 2000 DHCP server, and support for UTF-8 characters (as mentioned later in the section “Non-RFC Compliant BIND Data”).

NOTE Microsoft tested BIND interoperability with the Windows 2000 DNS Server service with the following versions: • BIND 4.9.7 • BIND 8.1.2 • BIND 8.2

Additional manual administration of SRV resource records is needed for DNS configuration support of Active Directory to function properly on a DNS server that does not support SRV records (BIND 4.9.3 and earlier). Table 9.3 shows a wider range of integration support options for BIND and Windows 2000 DNS. TABLE 9.3 Integration Support Options for BIND and Windows 2000 DNS Windows NT 4.0

BIND 9.0

BIND 8.2

BIND BIND 8.1.2 4.9.7

Support for the IETF InternetDraft “A DNS RR for Specifying the Location of Services (DNS SRV)” (SRV records) Support for dynamic update Support for secure dynamic update based on the GSS-TSIG algorithm Support for transaction signatures—TSIG (RFC 2845)

Yes

Only with Service Pack 4 or later

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

No

Yes

No

No

No

No

No

No

No

Yes

Yes

No

No


Windows 2000 Feature

256

TABLE 9.3 Continued Windows 2000

Windows NT 4.0

BIND 9.0

BIND 8.2

BIND BIND 8.1.2 4.9.7

Yes

Yes

Yes

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

No

No

Yes

No

No

No

No

No

Feature Support for WINS and WINS-R records Support for fast zone transfer Support for incremental zone transfer Support for UTF-8 character encoding

NOTE The DNS standards do not specify the internal data structure for resource records. Therefore, BIND servers use zones stored in text files, and Windows 2000 allows for integration with Active Directory.

You can modify your DNS namespace by creating a new single DNS subdomain for Active Directory, or by creating multiple subdomains based on a registered second-level domain name. For example, north-rim.com is registered to North Rim, Inc.; the BIND DNS administrator can create the delegation from the primary zone. Then, the Active Directory administrator can create a single subdomain such as ad.north-rim.com to implement as the root to the DNS domain namespace used by Active Directory. Creating multiple subdomains based on a DNS second-level domain to support registration of Active Directory in DNS is more complex. In this scenario, the administrator would create additional subdomains delegated to Windows 2000 DNS servers for registering DNS names related to Active Directory. This scenario allows for less impact and change to the current non-Windows DNS infrastructure. With this namespace design, you create only those additional subdomains and appropriate zones needed to support your Active Directory deployment. For example, the domain name north-rim.com is both the root DNS and the root Active Directory domain name. In this situation, delegation from the primary zone for the following zones need to be created on the BIND DNS server:


257

_msdcs.north-rim.com _ldap._tcp.north-rim.com

After this process, create these subdomains using the Windows 2000 DNS Manager. To integrate Windows 2000 DNS into an existing namespace based on nondynamic DNS servers, you can delegate the subdomains used by the SRV locator records to support dynamic updates. To allow this option, perform the following steps: 1. On the nondynamic BIND DNS server that is authoritative for the zone with the name of the Active Directory domain, delegate the following zones to a Windows 2000–based server running DNS: _udp. _tcp. _sites. _msdcs.

For example, if the root zone is called north-rim.com, delegate _udp.north-rim.com, _tcp.north-rim.com, _sites.north-rim.com, and _msdcs.north-rim.com to the Windows 2000 DNS server. 2. Next, create the forward zones delegated in the preceding step on the Windows 2000 DNS server, and enable the zones for dynamic update. Be sure to include the underscore on the zone name field in the New Zone Wizard.

NOTE To enable the zone to accept dynamic updates, refer to the section “Managing Zone Properties in the MMC Console” in Chapter 6. Repeat this process for each of the four zones described in step 1.

a. Delegate a new zone from the nondynamic DNS server (authoritative for the parent zone) to the Windows 2000 DNS server. For example, delegate the dynreg.north-rim.com zone to the Windows 2000 server. b. Create a forward lookup zone for the delegated zone on the Windows 2000 DNS server (dynreg.north-rim.com). c. Enable the zone(s) for dynamic updates.


3. Also, a single zone or several zones may be created and configured to allow clients and servers to dynamically register themselves with the Windows 2000 DNS server. For example, a zone called dynreg.north-rim.com could be configured for dynamic registrations. To configure such a zone, perform the following steps:

9

258

4. Reset clients and servers will have to register themselves in the new zone, because by default they will register themselves in a DNS zone with the same name as the Windows 2000 domain where they are members. To reconfigure the clients and servers, perform the following steps: a. Right-click My Computer, click Properties, and then click the Network Identification tab. b. Click Properties, and then click More. c. Click to clear the Change Primary DNS Suffix When Domain Membership Changes check box. d. Type the appropriate zone name in the Primary DNS Suffix of This Computer box. For example, type dynreg.north-rim.com. e. Click OK. Note that this change requires that the client be rebooted after the change has been completed. After the computer is rebooted, it will dynamically register itself in the new zone. When Windows 2000 domain controllers start, the netlogon service tries registering several SRV records in the authoritative zone. Because the zones for registering SRV records have been delegated (in steps 1 and 2) to a Windows 2000 server where they can be dynamically updated, these registration attempts will succeed. Additionally, a domain controller will attempt to register the host records (A) listed in its netlogon.dns file in the root zone (for example north-rim.com). Because the root zone is located on a nondynamic DNS server, these updates will not succeed, and will generate an event in the system log on the domain controller similar to the following: Event Type: Warning Event Source: NETLOGON Event Category: None Event ID: 5773 Date: 3/29/2000 Time: 9:32:56 AM User: N/A Computer: DC Description: The DNS server for this DC does not support dynamic DNS. Add the DNS records from the file ‘%SystemRoot%\System32\Config\netlogon.dns’ to the DNS server serving the domain referenced in that file.

Netlogon.dns Files Every Windows 2000 domain controller has a netlogon.dns file located in its %SystemRoot%\ System32\Config folder, which contains a list of DNS records that the domain controller will attempt to register when the netlogon service starts.


259

NOTE Consider making a copy of this file before making the following changes so that an original list of the records can be maintained. Each domain controller will have different records specific to each domain controller’s network adapter.

Examine the netlogon.dns file for host (A) records in the file. For example: north-rim.com. 600 IN A 192.168.1.1 gc._msdcs.north-rim.com. 600 IN A 192.168.1.1

The number of host records in the netlogon.dns file depends on the number of adapters the DC has, the number of configured IP addresses for each adapter, and the domain controller’s role. The host records are calculated as shown here: • The name server totals one host (A) record for each of its IP addresses for the domain name. • Also, if the domain controller is also a global catalog (GC) server, it registers gc._msdcs. for each IP address on the server. As mentioned earlier, the nondynamic BIND DNS server will not accept any dynamic registrations from any Windows 2000 domain controller. Therefore, the domain controller’s host (A) records have to be manually configured on the authoritative DNS server for the root zone. The addition of the host record is not required unless third-party LDAP clients do not support SRV DNS records are searching for the domain controllers.

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

After you have an Active Directory forest and domain in place, you should integrate Active Directory with the DNS domains that the Windows 2000 server running DNS is responsible for. Also, you should reconfigure zones that have been configured to accept dynamic updates to accept only secure dynamic updates.

Windows 2000 DNS as Root DNS The option of configuring Windows 2000 DNS at the root zone usually implies that no current BIND implementation exists at the root zone, or that it has been replaced. Because most companies with an Internet presence maintain BIND servers at their root domain, replacing the company’s root domain while maintaining BIND secondaries will prove to be uncommon.


The following registry key should be used to disable the domain controller from attempting to register the A records seen in the netlogon.dns file. In the Registry, change the REG_DWORD RegisterDnsARecords value to 0 (zero) under

260

However, in the event of certain political or platform circles, this remains a possibility (such as Engineering groups or remote sites committed to maintaining BIND servers). In this scenario, administrators should review any interoperability issues related to zone transfers for this configuration, as documented in the next sections.

Zone Transfers Between AD and BIND When transferring a zone between two Windows DNS servers, the DNS Server service always uses a fast transfer method that uses compression. This method includes multiple resource records (RRs) in each message sent to complete the transfer of the zone between servers. For Windows 2000 DNS servers, this is the default method used when initiating transfers with other DNS server implementations. If necessary, Windows 2000 DNS servers can be configured to transfer a zone using the slower uncompressed transfer format. This enables successful zone transfers to be made with DNS servers that do not support the faster transfer method, such as BIND servers before version 4.9.4. When the BIND Secondaries option in the Advanced tab of the DNS server properties is checked, no fast transfers are made. By default, the check box is cleared to enable fast transfers. This setting is used to optimize zone transfers between Windows 2000 DNS servers and other DNS server implementations, because Windows 2000 DNS zone transfers always use the fast transfer format.

NOTE Because BIND versions 4.9.3 and earlier do not support the fast transfer format, enable this option only if you are transferring zones to BIND servers running version 4.9.4 or later.

To enable or disable fast transfer format during zone transfers, perform the following steps (as shown in Figure 9.3): 1. Open DNS Manager, and right-click the DNS server. 2. Select Properties, and click the Advanced tab. 3. In the Server Options list, select the BIND Secondaries check box, and then click OK. There is a significant advantage to storing your Microsoft DNS information in Active Directory. In standard DNS, replication was single master, pulling updates to secondary servers. This left a single point of failure, and many companies implemented primary and backup DNS servers. However, by implementing Active Directory storage of DNS, replication


261

is multi-master because Active Directory replicates between the domain controllers running DNS on your network. With Active Directory storage of Microsoft DNS, there is no need to manage a separate replication structure, transfers are secure (managed by trusts in Active Directory), and there is no single point of failure. You can also send standard zone transfers to other servers as necessary. With Active Directory storage, DNS data is converted to an object model in which a DNS name becomes the object and the resource record set is the attribute.

FIGURE 9.3 Enabling slow transfers to BIND servers.

To determine whether your version of BIND supports dynamic record updates, use the nsupdate tool that ships with BIND. Create a test domain and its zone file in the DNS server, and then turn on dynamic updating using the nsupdate tool to perform manual dynamic updates.

NOTE It is imperative to coordinate and plan any Active Directory and UNIX DNS integration with your current DNS team.


The minimum DNS requirement for Active Directory integration is support of SRV resource records. BIND 4.9.6 and later versions meet this requirement. However, it is strongly recommended that you upgrade to at least 8.x to support dynamic updates. Note that BIND 8.2.2 supports integration with Active Directory, including dynamic updates, zone transfers, and updating SRV records.

262

Disadvantages and Considerations In the real world, DNS has been managed effectively on UNIX servers for years. Many UNIX administrators see no value in implementing Microsoft DNS. This section addresses some of the issues from both perspectives. In this section, the issues that may arise when Microsoft DNS servers are used in the mixed environment with non-Microsoft DNS servers are discussed. Because it is RFC compliant, the Microsoft DNS server is fully interoperable with all other RFC-compliant DNS servers. However, because the Microsoft DNS server provides a wider spectrum of features than are specified in the RFC, the user is advised to exercise caution using these features. These features are limited to the use of WINS and WINS-R resource records and to the use of the UTF-8 character encoding.

Using WINS and WINS-R Records Because currently only Microsoft DNS servers support the WINS and WINS-R resource records, we recommend disabling replication of these records if the following conditions are satisfied: • The primary copy of the zone contains one of these records. • At least one of the secondaries resides on the non-Microsoft DNS server. At the same time, if the secondaries reside partially on Microsoft and non-Microsoft DNS servers, disabling WINS and WINS-R resource records replication may require manual input of these records to the secondary zones residing on the Microsoft DNS servers. To disable replication of WINS and WINS-R records, perform the following steps: 1. In the DNS Manager, expand the server and right-select either the forward or the reverse lookup zone. 2. Right-click the zone for which you want to disable replication of WINS and WINS-R records, and then click Properties. 3. Select the WINS tab. 4. Select the Do Not Replicate This Record check box. If WINS and WINS-R record replication is disabled, only queries directed at the primary servers will provide results to the querying client. Queries directed at secondary servers will prompt the response that the name was not found. To prevent this situation, configure the DNS servers to use WINS referral as discussed previously in this chapter.


263

Using UTF-8 Characters Format The Windows 2000 DNS server can be configured to allow or disallow the use of UTF-8 characters on a per-server or per-zone basis. A non-UTF-8-aware DNS server may accept a zone transfer of a zone containing UTF-8 names, but it may not be able to write back those names to a zone file or reload those names from a zone file. Administrators should exercise caution when transferring a zone containing UTF-8 names to a non-UTF-8-aware DNS server.

Non–RFC Compliant BIND Data If a Windows 2000 server supports a secondary zone and receives unknown resource records, such as DNSSEC records, it will drop such records and continue zone replication. These records include those listed in the “BIND Security” section earlier in this chapter. The Windows 2000 DNS server also drops circular CNAME resource records upon receipt.

BIND as Primary and Secondary (No Windows 2000 DNS) If the Windows 2000 DNS server is not installed and the BIND server can support Active Directory, a file (netlogon.dns) is written and created during the Active Directory installation process that contains the SRV records and other records needed to support the use of Active Directory. This file is created in the %SystemRoot%\System32\Config folder.

NOTE In the future, the SRV resource record may also be utilized by other TCP/IP services for certain applications.

Windows 2000 DNS server provides some interoperability with other TCP/IP services, which may improve administrative overhead on the network. These options include the following: • WINS forward and reverse lookups • Dynamic integration with DHCP servers In Windows NT Server 4.0 and later, the DNS service supports WINS lookup, enabling DNS zones to refer unanswered queries for a zone to a WINS server for further resolution. In this situation, both the DNS and the WINS service collaborate to perform a comprehensive search of registered names. As mentioned in Chapter 8, “Windows 2000 DNS and WINS Replication,” WINS lookup is supported for both forward and reverse lookup zones and can be enabled on a per-zone basis or


Interoperability Planning

264

configured for selected zones. This feature prevents any replication or zone transfer of WINS records to DNS servers not supporting them. The Windows 2000 DNS server also integrates with the Windows 2000 DHCP service to support, register, and update legacy DHCP clients in DNS zones. This feature gives a DHCP client unable to dynamically update DNS resource records directly the capability to have its information updated in DNS forward and reverse lookup zones by the DHCP server.

NOTE Dynamic integration with the DHCP service is available only with Windows 2000 Server. Also, DHCP servers running versions Windows NT 4.0 and earlier do not support DNS-DHCP integration.

Summary Although integrating Windows 2000 DNS server and Active Directory into existing BIND environments may seem challenging, it is very possible. Each DNS server has its share of security enhancements, dynamic registration, and standard RFC features. The decision on which of the three integration options for Windows 2000 to implement will most likely be based more on political and social concerns than on technical concerns. The migration paths from BIND DNS to Windows 2000 DNS can be complicated and will require significant testing in a lab. Also, integration will undoubtedly decrease a level of available features in each DNS system, because security and fast transfers are incompatible features of each.

CHAPTER

DNS Best Practices and Maintenance

10

IN THIS CHAPTER • DNS Suggested Standards

266

• DHCP Suggested Standards

267

• WINS Suggested Standards

269

• Internet DNS Suggested Standards

270

• Basic DNS Configuration Recommendations 270 • DNS Server Configuration Verification

271

• Monitoring DNS Server Performance

277

• Tuning Advanced Server Parameters

291

• Summary

292

266

Windows 2000 DNS deployment can be quite complicated in larger organizations, particularly when integrating with other third-party DNS solutions, DHCP, and WINS. This chapter focuses on some “suggested standards” based on Microsoft’s suggestions and real-world scenarios. As with any business-critical implementation, it is important to monitor and maintain the DNS server to avoid service interruptions. Later sections of this chapter focus on monitoring and maintenance of the Windows 2000 DNS server.

DNS Suggested Standards Following are some suggested standards for Windows 2000 DNS as suggested by Microsoft: • Enter the correct email address of the responsible person for each zone added to or managed on a DNS server. This field is used by applications to notify DNS administrators for issues including query and resolution errors, incorrect data, and security problems. Standard email applications use the “at” sign (@); you must replace this symbol with a period (.) when entering an email address for this field. For example, the email address [email protected] would be replaced with admin.north-rim.com. • Be conservative with alias records. Don’t add unnecessary CNAME records. CNAME records are most commonly used for Web and email convenience. Restrict them to this functionality. Also, ensure that any alias names are exclusive to the zone. Don’t duplicate names within the zone.

NOTE Windows 2000 DNS permits the repetition of a name label used in other types of resource records (such as NS, MX, or TXT records) at the same domain level in the namespace tree, but zones must be administered manually to support this process.

• Follow standard guidelines, RFCs, and integration considerations when managing the DNS infrastructure. • Deploy at least two name servers for each zone. They can host either primary and secondary copies of the zone, or two directory-integrated copies of each zone. • If Active Directory is deployed and will not be integrated with a legacy DNS system, consider using directory-integrated zones. • If the plan for the company is DNS integration with BIND, be aware that a standard primary zone becomes a single point of failure for dynamic updates and for zone replication because only the primary server (as listed in the SOA) can process an update to the zone.

DNS Best Practices and Maintenance CHAPTER 10

267

• Consider using secondary or caching-only servers to offload DNS query traffic for zones. • In heterogeneous DNS environments, zone transfer efficiency may be slower than Windows 2000 DNS server-only environments. For more information, refer to Chapter 9, “BIND and Windows 2000 Interoperability.” • In Windows 2000 DNS environments, use incremental zone transfers for standard zone replication, which can reduce DNS replication traffic.

DHCP Suggested Standards Following are some suggested standards for Windows 2000 DHCP as suggested by Microsoft: • Use the 80/20 design rule for balancing scope distribution of addresses when multiple DHCP servers manage the same scope. Multiple DHCP servers on the same subnet can provide increased fault tolerance. A common practice when balancing a single network and scope range of addresses between two DHCP servers is to have 80% of the addresses distributed by one DHCP server and the remaining 20% provided by a second. • Use superscopes for multiple DHCP servers on each subnet in a LAN environment. Because DHCP clients use broadcasts during their initial startup, the responding server cannot be predicted if more than one DHCP server is active on the same subnet. For example, if two DHCP servers service the same subnet and its clients, addresses can be leased at either server. During DHCP renewal, a different DHCP server might respond to the client request. If this occurs, the responding server might send a DHCP negative acknowledgment message (DHCPNAK) in reply, even if the lease-originating server is available on the network. Configuring a superscope on the DHCP servers for the subnet can alleviate this issue. The superscope should include all valid scopes for the subnet as member scopes. • Deactivate scopes only when removing a scope permanently from service. After a scope is activated, it should not be deactivated until it is ready to be retired. It should not be deactivated to pause the issuing of addresses. • Minimize DHCP server-side conflict detection.

• Reservations should be created on all DHCP servers that can potentially service the reserved client.

10 DNS BEST PRACTICES AND MAINTENANCE

Conflict detection can be used by either DHCP servers or clients to determine whether an IP address is already in use on the network before leasing or using the address. For resource purposes, perform client-based conflict detection before completing configuration and use of a server-offered IP address.

268

Consider using client reservations for hosts that need to maintain the same IP address when it boots. Such hosts may include printers and dedicated workstations. • For server performance, note that DHCP is a disk-intensive process that will require optimal disk performance. Consider RAID solutions when purchasing hardware for servers to improve disk access time. • Enable audit logging for troubleshooting purposes. The DHCP service enables audit logging of service-related events by default. Refer to the application portion of the Event Viewer for details • Reduce lease times for DHCP clients using Routing and Remote Access service for remote access. Also reduce lease times for portable systems that move between subnets on the network. Lease options can be configured by class to enable this option. See Chapter 5, “Configuring DHCP and DNS Client Configurations,” for more information. • Increase lease times for fixed and stable clients if sufficient address space is available. In this scenario, consider increasing the length of scope leases to reduce DHCP-related network broadcast traffic. • Integrate DHCP with other services, such as WINS and DNS on a Windows 2000 network. WINS and DNS can be integrated when registering dynamic name-to-address mappings on the network. • Consider using relay agents or setting appropriate timers to prevent undesired forwarding and relay of BOOTP and DHCP message traffic on routed networks. With multiple physical networks connected through routers, the routers must be capable of relaying BOOTP and DHCP traffic. Without these routers, the DHCP Relay Agent must be configured on a Windows 2000 server (or Windows NT Server) in each subnet to relay DHCP and BOOTP message traffic.

NOTE When using relay agents, be sure to set the initial time delay in seconds so that relay agents wait before relaying messages on to remote servers.

• Deploy the appropriate number of DHCP servers for the number of DHCP-enabled clients.


269

• For dynamic updates performed by the DHCP service, use the default client preference settings. Remember, Windows 2000 clients can dynamically register their host (A) records with the DNS server. Legacy Windows clients can register their A and PTR records via a Windows 2000 DHCP server.

WINS Suggested Standards Following are some suggested standards for Windows 2000 WINS as suggested by Microsoft. Because WINS integrates with Windows 2000 DNS, it is important to adhere to the following suggested standards when deploying WINS: • Use default settings to configure WINS servers, because modified settings can impact performance and resolution. • Avoid using static WINS entries, because this may increase overhead for the local machine and require additional manual entries for other systems on the network. If static WINS entries must be used, the following are suggestions for configuring other WINS and DHCP service properties and avoiding common problems: • Schedule consistency checking for an off-peak time, because it is fairly network- and resource-intensive for the WINS server. • When configuring replication partners, select Push/Pull replication, because it is a simple and effective way to ensure full WINS replication between partners. In some large enterprise WINS networks, limited replication partnering can effectively support replication over slow WAN links. • Consider the hub-and-spoke design model for WINS replication and convergence. In most cases, the hub-and-spoke model provides a simple and effective planning method for organizations that require full and efficient convergence with minimal administrative overhead. • Limit the number of WINS servers on the network to reduce replication issues. • Monitor and perform regular, offline compaction. Monitor any changes to the size of the server database file, Wins.mdb, located in the %systemroot%\System32\WINS\ folder. Verify the file size of Wins.mdb before and after compaction, to track growth and reduction, and plan for future compacting schedules. • Perform regular backups of the WINS database.

• Configure clients with more WINS server IP addresses.

DNS BEST PRACTICES AND MAINTENANCE

In addition to the standard Windows 2000 backup utility, the WINS console offers a backup option that can restore a server database if corruption occurs.

10

270

Windows 2000 allows WINS clients (either manually or through DHCP) to use up to 12 WINS servers (as opposed to only 2 in previous Windows versions), which can be statically or dynamically assigned. Additional WINS server addresses also provide a level of fault tolerance for WINS clients. • Use nbtstat to register and troubleshoot client connectivity. For Windows 2000, the NBTSTAT -R command-line option purges remote names from the local NetBIOS names cache, and the -RR switch forces immediate renewal and re-registration of local client names. • Configure each WINS server computer to point to itself. Each WINS server on the network must register its own set of NetBIOS unique and group names in WINS.

Internet DNS Suggested Standards As mentioned in Chapter 1, “Domain Name System Fundamentals,” the Internet Engineering Task Force (IETF) has published several Request for Comment (RFC) documents for DNS. The RFCs for DNS are recommended by various DNS architects and planners for the Internet. These documents are recommended for review when planning a large DNS design, such as for an Internet service provider (ISP) or a Web-based organization. Current RFCs that cover Internet DNS suggested standards include those listed in Table 10.1. TABLE 10.1 Internet DNS RFCs RFC

Title

1912 2182 2219

Common DNS Operational and Configuration Errors Selection and Operation of Secondary DNS Servers Use of DNS Aliases for Network Services

Basic DNS Configuration Recommendations This section provides a quick reference for standard DNS configurations, including location and redundancy.

DNS Server Location The following factors need to be considered in deciding where a DNS server is needed: • Centrally locate the DNS server.


271

• Install at least one DNS server per subnet. • Monitor network connectivity and the effect of zone transfers over WAN links. • Configure backup or redundant DNS server (local or remote). • Consider remote backup (DNS server on another subnet). • Consider caching-only DNS servers for remote locations. For example, with a routed local area network and high-speed, reliable links, it is feasible to implement one DNS server for a larger, multiple subnetted network area. When making any final determinations about the number of servers to use, first assess the level of fault tolerance needed for the network: • When only a single Windows 2000 Server is used on a small LAN in a single-subnet environment, configure the single server to simulate both the primary and the secondary servers for a zone. • When administering zone files created by the DNS service, the DNS Manager console is the preferred tool. Standardize and minimize the use of alternative tools that can compromise data and process integrity.

DNS Server Redundancy With most installations, consider at least two server computers hosting each of the DNS zones for fault tolerance. DNS was designed to have two servers for each zone, one as a primary server and the other as a backup or secondary server. When an administrator installs and configures a DNS server during the Active Directory Installation Wizard, the zones are created based on the DNS name specified during the promotion process. When promoted to a domain controller, the zone type can be changed from Standard primary to Active Directory–integrated. The update policy can also be set for the zone to Allow Only Secure Updates. If DNS is being deployed to support Active Directory, a simple and reliable method for redundancy and fault-tolerance planning is to have a DNS server running on each domain controller. For each subnet, configure two Windows 2000 servers as domain controllers running the DNS service using Active Directory–integrated zones.

DNS Server Configuration Verification


Various methods can be used to test the availability and reliability of the Windows 2000 DNS server. This section addresses some essential verification processes.

10

272

Verifying Server Configuration When using the DNS console, perform either manual or automated verification testing of the DNS servers to monitor their capability to process and resolve queries. This feature is accessed through the Monitoring tab in DNS server Properties. When you’re using this feature, two types of tests are available: • A simple query against this DNS server. This type of test specifies that the DNS server perform a simple or iterative query. This test is a localized query using the DNS resolver (client) on the server to query the local DNS server (itself). • A recursive query to other DNS servers. This type of test specifies that the DNS server perform a recursive query. This test is similar in its initial query processing to the other test in that it uses the local DNS resolver (client) to query the local DNS server, also located on the same computer. In this recursive query test, the client asks the server to use recursion to resolve an NS-type query for the root of the DNS domain namespace (“.”). This query can verify the integrity of the server’s root hints or zone delegations.

Using DNS Console to Perform a Test Query You can use the DNS console to perform a test query to determine whether your server is working properly. To perform test queries from within the DNS console, perform the following steps: 1. In the DNS console, double-click the server name to expand the server information. 2. Right-click the server, and then click Properties. 3. Click the Monitoring tab. 4. Select the tests you want to perform, and then click Test Now. If the simple query fails, check whether the local server contains the zone 1.0.0.127.in-addr.arpa. If the recursive query fails, check whether the root hints are correct and whether the root servers are running.

TIP Some zones cannot be viewed unless the MMC view is set to Advanced. For example, the 1.0.0.127.in-addr.arpa zone will not show up in that standard view.


273

With either query, clicking the Test Now button manually performs the tests immediately. These tests can also be performed automatically at specified time intervals. See Figure 10.1 for a visual of this process.

FIGURE 10.1 The test options in the Monitoring tab of the DNS Manager.

Automated tests are performed periodically when the Perform Automatic Testing at the Following Interval check box is selected, and they are done according to the duration configured in Time Interval. The results of the selected tests are then displayed in the Test Results list box. Typically, this information includes the date and time of each query, as well as the test type (such as simple or recursive query) and its result.

Verifying Query Responses from the DNS Server Use the following process to verify that the DNS server is started and can answer queries: • Ensure basic network connectivity to the server. • Test both simple and recursive queries from the Monitoring tab in the DNS Manager (as documented in the preceding section). • From a client, use nslookup.exe to look up a domain name and host in the domain.


• Run netdiag.exe on the server to ensure that the server is functioning properly and that the resource records netlogon requires are registered. For more details on netdiag.exe, see Chapter 12, “Remote and Command-Line Utilities for DNS Management.”

10

274

• Make sure that the server can reach a root server by typing the following at the command prompt: nslookup set querytype=NS server

• Ensure that A and PTR resource records are configured for the server.

Verifying the Forward Lookup Zone After creating a forward lookup zone, use nslookup to make sure that it is properly configured. If Active Directory is to be installed, also consider testing its integrity to host Active Directory. To start nslookup, type the following: Nslookup set querytype=any server

When nslookup starts, if the resolver cannot locate a PTR resource record for the server, an error message is displayed. To verify that the zone is responding correctly, simulate a zone transfer by typing the following: ls -d <domain name>

If the server is configured to restrict zone transfers, an error message may be listed in Event Viewer. Otherwise, a list of all the records in the domain is displayed. Next, query for the SOA record by typing the following and pressing Enter: <domain name>

If the server is configured correctly, an SOA record is displayed, which includes a primary name server field. To verify that the primary name server has registered an NS record, type the following: set type=ns <domain name>

If the server is configured correctly, an NS record for the name server is displayed. Make sure that the authoritative name server listed in the NS record can be contacted to request queries by typing the following: server <server name or IP address>

Next, query the server for any name for which it is authoritative. If these tests are successful, then the NS record points to the correct hostname, and the hostname has the correct IP address associated with it.


275

Verifying Reverse Lookup Zones and PTR Resource Records Although reverse lookup zones and PTR resource records are not required for Active Directory to function, they are required if clients will need to resolve FQDNs from IP addresses. Also, PTR resource records are commonly used by some applications for security purposes (verifying client identity). After configuring the reverse lookup zones and PTR resource records, manually view them in DNS Manager. A reverse lookup zone is required for each subnet, and the parent reverse lookup zone must have a delegation to the reverse lookup zone. For example, if the network has a private root and the subnets 192.168.1.x and 192.168.2.x, the private root can host all reverse lookup zones, or it can contain the reverse lookup zone 192.168.x and delegate the reverse lookup zones 192.168.1.x and 192.168.2.x to other servers. PTR resource records should exist for all the network hosts. The nslookup utility can also be used to verify that the reverse lookup zones and PTR resource records are configured correctly. To make sure that the reverse lookup zones and PTR resource records are configured correctly, perform the following steps: 1. Initiate nslookup at the command prompt. 2. Switch to the server to query by typing the following: server <Server IP Address>

3. Enter the host’s IP address for verification, and press Enter. If the reverse lookup zone and PTR resource record are configured correctly, nslookup returns the name of the computer. 4. Type exit and press Enter to quit nslookup.

Verifying DNS Configuration After Installing Active Directory If third-party DNS servers remain in the organization to support Active Directory, administrators need to verify the registration of domain controller locator resource records. If the server does not support dynamic update, these records need to be added manually.

This file, shown in Figure 10.2, can be referenced to discover which locator resource records are created for the domain controller.


The netlogon service creates a log file that contains all the locator resource records and places the log file in %SystemRoot%\System32\Config\Netlogon.dns.

276

FIGURE 10.2 The netlogon.dns file as viewed with Notepad.

The locator resource records are stored in a text file, compliant with RFC specifications. If the server is configured correctly, the LDAP SRV record for the domain controller should appear as follows: _ldap._tcp.Active Directory domain name

IN

SRV

priority weight 389 DC name

0

100

389

For example, in Figure 10.2 the first line reads _ldap._tcp.kevinkocis.com.

600

IN

SRV

dc1.kevinkocis.com

Next, use the nslookup command-line tool to verify that the domain controller registered the SRV resource records that were listed in netlogon.dns. To verify that SRV resource records are registered for the domain controller, perform the following steps: 1. At the command prompt, type nslookup and press Enter. 2. To set the DNS query type to filter for SRV records only, type set press Enter.

type=SRV

and then

3. To send a query for the registered SRV record for a domain controller in the Active Directory domain, type _ldap._tcp. and then press Enter.


277

4. The SRV records should be listed in netlogon.dns. If they are not, the SRV resource records may not be registered for the domain controller. The following example shows an nslookup session verifying SRV records registered for locating two domain controllers on a network. In this example, the two domain controllers (dc1 and dc2) are registered for the domain kevinkocis.com. C:\>nslookup Default Server: dc1.kevinkocis.com Address: 192.168.1.1 > set type=SRV > _ldap._tcp.kevinkocis.com Server: dc1.kevinkocis.com Address: 192.168.1.1 _ldap._tcp.kevinkocis.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = dc1.kevinkocis.com _ldap._tcp.noam.reskit.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = dc2.kevinkocis.com dc1.kevinkocis.com internet address = 192.168.1.1 dc2.kevinkocis.com internet address = 192.168.1.2

NOTE You must have sufficient permissions to perform the previous commands, because these commands actually trigger a full or incremental zone transfer.

Monitoring DNS Server Performance Windows 2000 Server provides two options for monitoring the DNS service. These options include the DNS Event Viewer log and the trace logging option for debugging.


For Windows 2000 Server, DNS server event messages are separated and kept in their own system event log, the DNS server log, which can be viewed using Event Viewer, as shown in Figure 10.3.

278

FIGURE 10.3 The DNS server log in Event Viewer (with an opened error).

To view the DNS server system event log, perform the following steps: 1. Open Event Viewer. 2. If the DNS server log is located on another computer, right-click the Event Viewer container, and select Connect to Another Computer. 3. Select Another Computer and specify the name or IP address of the remote computer. 4. When the correct DNS server has been selected, click the DNS Server event log. 5. Review the logged events listed for the DNS Server service in the details pane. Double-click an event for additional details. The DNS server log contains predetermined events logged by the DNS Server service, such as when the DNS server starts or stops. Some additional critical DNS service events are also logged here, such as when the server starts but cannot locate initializing data, such as zones or boot information stored in the Windows 2000 registry or (in some cases) Active Directory. This is the case for the error shown in Figure 10.3. Event Viewer is one of the most useful tools for identifying problems, ranging from name resolution to directory service to hardware and software failures. It categorizes error codes for problem identification, and analyzes the cause. Event Viewer also allows administrators to view and monitor client-related DNS events. These events are written by the DNS Client service on Windows 2000 clients and copied to the System Log on the DNS server.


279

The logging option in the DNS console can also be configured to selectively enable additional debug logging options. This allows for temporary trace logging to a text-based file of DNS server activity. The file created and used for this feature, Dns.log, is stored in the %systemroot%\System32\Dns folder.

System Monitor System Monitor is a Windows 2000 utility that tracks performance monitoring using additional service-specific counters that measure DNS server performance. From these counters, an administrator can create charts and graphs of server time-based performance trends, which can be reviewed and analyzed to determine any future server modifications.

NOTE The DNS console in Windows 2000 replaces DNS Manager used in Windows NT Server 4.0.

The System Monitor tool included with Windows 2000 is the administrative tool replacing the Performance Monitor tool from Windows NT 4.0. Some improvements in the System Monitor tool include the following: • The capability to log specific counters and instances of an object, which reduces the size of log files • The capability to start the log on an event using Performance Logs and Alerts • The addition of new Performance objects To open System Monitor, open the Performance tool in Administrative Tools from the Start/Programs submenu. Unless counters have already been added, the interface should appear static, as shown in Figure 10.4.

Adding System Counters To add counters to System Monitor, perform the following steps: 1. Open Performance (if necessary). 2. Right-click the System Monitor details pane and click Add Counters, or click the “+” symbol in the icon bar of the details pane.

4. In Performance object, select the DNS object to monitor. The Processor object is selected by default (as shown in Figure 10.5).


3. To monitor any computer on which the monitoring console is run, click Use Local Computer Counters. Otherwise, click the Select Counters from Computer button and enter the DNS server name (the local server name appears by default).

280

FIGURE 10.4 The System Monitor with no counters selected.

FIGURE 10.5 The Add Counters window in System Monitor with the default settings.

5. To monitor all counters, click All Counters; to monitor only selected counters, click Select Counters from List and select the specific counters (use Ctrl to select individually). 6. To monitor all instances of the selected counters, click All Instances, or, to monitor only selected instances, click Select Instances from List and select the instances you want to monitor (use Ctrl to select individually). 7. Click Add.


281

NOTE For a detailed listing of the various DNS counters, see the section “DNS Server Performance Counters,” later in this chapter.

If an object on a remote computer is selected, the local system may experience a short delay as System Monitor refreshes the list to reflect objects from the remote system. Also, if the console is being created for export, select Use Local Computer Counters, or System Monitor will obtain data from the computer named in the text box, regardless of where the console file is installed.

TIP For a description of a particular counter, click the name of the counter in Performance Object and then click Explain.

By default, counters are shown with both the instance name and an instance index. To turn off this feature, right-click the details pane, click Properties, and clear the Allow Duplicate Counter Instances check box at the bottom of the General tab (as shown in Figure 10.6).

10 Removing the Allow Duplicate Counter Instances option in the System Monitor Properties dialog box.


FIGURE 10.6

282

Deleting Counters from System Monitor To delete counters from System Monitor, click the name of the counter in the legend and click Delete. Counters can also be deleted by using the Data tab in the System Monitor Properties dialog box.

Creating Counters or Trace Logs Administrators can create a counter or trace log file to track performance over time. To create a new log, perform the following steps: 1. In Performance Logs and Alerts, right-click Counter Logs or Trace Logs. 2. Select New Log Settings, type a name for the log, and click OK. 3. On the General tab, click Add to add the necessary counters, as shown in Figure 10.7.

FIGURE 10.7 Adding DNS counters to a new log file called DNS counter log.

4. Set the time interval at the bottom of the General tab (the default is 15 seconds). 5. On the Log Files tab, modify the logging options as appropriate. 6. On the Schedule tab, modify the scheduling options, and then click OK. Similar options can be set in Alerts. For example, an alert can be configured to send a message, start a performance data log, or run a program, if a counter exceeds a certain value. To view the system monitor log or performance monitor log, perform the following steps: 1. Open Performance and click System Monitor.


283

2. Right-click in the details pane, and select Properties. 3. On the Source tab, click Log File, browse to the appropriate log file, and click OK. 4. Add counters as necessary.

NOTE Perfmon4.exe is a Microsoft Windows 2000 Resource Kit tool that is similar in appearance and operability to Performance Monitor in Microsoft Windows NT 4.0. The tool allows administrators to view and collect performance logs on a Windows 2000–based computer. Perfmon4.exe can be used to collect Windows 2000 performance data without having to use System Monitor. However, Perfmon4.exe cannot be used to view performance logs taken with System Monitor in Windows 2000.

DNS Server Performance Counters Depending on the monitoring requirements or error tracking of DNS, administrators will need to identify the appropriate performance counter(s) to monitor. The following sections identify the various counters for the respective DNS tasks and describe them in more detail.

All Zone Transfer (AXFR) Counters • AXFR Request Received The total number of full zone transfer requests received by the DNS Server service when operating as a master server for a zone. • AXFR Request Sent The total number of full zone transfer requests sent by the DNS Server service when operating as a secondary server for a zone. • AXFR Response Received The total number of full zone transfer requests received by the DNS Server service when operating as a secondary server for a zone. • AXFR Success Received The total number of full zone transfers received by the DNS Server service when operating as a secondary server for a zone. • AXFR Success Sent


The total number of full zone transfers successfully sent by the DNS Server service when operating as a master server for a zone.

10

284

DNS Server Memory Counters • Caching Memory The total amount of system memory in use by the DNS Server service for caching. • Database Node Memory The total amount of system memory in use by the DNS Server service for database nodes. • Nbtstat Memory The total amount of system memory in use by the DNS Server service for Nbtstat. • Record Flow Memory The total amount of system memory in use by the DNS Server service for record flow.

Dynamic Update Counters • Dynamic Update NoOperation The total number of No-operation/Empty dynamic update requests received by the DNS server. • Dynamic Update NoOperation/sec The average number of No-operation/Empty dynamic update requests received by the DNS server in each second. • Dynamic Update Queued The total number of dynamic updates queued by the DNS server. • Dynamic Update Received The total number of dynamic update requests received by the DNS server. • Dynamic Update Received/sec The average number of dynamic update requests received by the DNS server in each second. • Dynamic Update Rejected The total number of dynamic updates rejected by the DNS server. • Dynamic Update TimeOuts The total number of dynamic update timeouts of the DNS server. • Dynamic Update Written to Database The total number of dynamic updates written to the database by the DNS server. • Dynamic Update Written to Database/sec The average number of dynamic updates written to the database by the DNS server in each second.


285

Incremental Zone Transfer (IXFR) Counters • IXFR Request Received The total number of incremental zone transfer requests received by the master DNS server. • IXFR Request Sent The total number of incremental zone transfer requests sent by the secondary DNS server. • IXFR Response Received The total number of incremental zone transfer responses received by the secondary DNS server. • IXFR Success Received The total number of successful incremental zone transfers received by the secondary DNS server. • IXFR Success Sent The total number of successful incremental zone transfers of the master DNS server. • IXFR TCP Success Received The total number of successful TCP incremental zone transfers received by the secondary DNS server. • IXFR UDP Success Received The total number of successful UDP incremental zone transfers received by the secondary DNS server.

Notification Counters • Notify Received The total number of notifies received by the secondary DNS server. • Notify Sent The total number of notifies sent by the master DNS server.

Recursion Counters • Recursive Queries The total number of recursive queries received by the DNS server. The average number of recursive queries received by the DNS server in each second. • Recursive Query Failure The total number of recursive query failures.


• Recursive Queries/sec

286

• Recursive Query Failure/sec The average number of recursive query failures in each second. • Recursive TimeOuts The total number of recursive queries sending timeouts. • Recursive TimeOuts/sec The average number of recursive queries sending timeouts in each second.

Secure Dynamic Update Counters • Secure Update Failure The total number of secure updates failed on the DNS server. • Secure Update Received The total number of secure update requests received by the DNS server. • Secure Update Received/sec The average number of secure update requests received by the DNS server in each second.

TCP Counters • TCP Message Memory The total TCP message memory used by the DNS server. • TCP Query Received The total number of TCP queries received by the DNS server. • TCP Query Received/sec The average number of TCP queries received by the DNS server in each second. • TCP Response Sent The total number of TCP responses sent by the DNS server. • TCP Response Sent/sec The average number of TCP responses sent by the DNS server in each second.

Total (Overall Performance) Counters • Total Query Received The total number of queries received by the DNS server. • Total Query Received/sec The average number of queries received by the DNS server in each second.


287

• Total Response Sent The total number of responses sent by the DNS server. • Total Response Sent/sec The average number of responses sent by the DNS server in each second.

UDP Counters • UDP Message Memory The total UDP message memory used by the DNS server. • UDP Query Received The total number of UDP queries received by the DNS server. • UDP Query Received/sec The average number of UDP queries received by the DNS server in each second. • UDP Response Sent The total number of UDP responses sent by the DNS server. • UDP Response Sent/sec The average number of UDP responses sent by the DNS server in each second.

WINS Lookup Counters • WINS Lookup Received The total number of WINS lookup requests received by the server. • WINS Lookup Received/sec The average number of WINS lookup requests received by the server in each second. • WINS Response Sent The total number of WINS lookup responses sent by the server. • WINS Response Sent/sec The average number of WINS lookup responses sent by the server in each second. • WINS Reverse Lookup Received The total number of WINS reverse lookup requests received by the server. • WINS Reverse Lookup Received/sec


The average number of WINS reverse lookup requests received by the server in each second.

288

• WINS Reverse Response Sent The total number of WINS Reverse lookup responses sent by the server. • WINS Reverse Response Sent/sec The average number of WINS Reverse lookup responses sent by the server in each second.

Zone Transfer Counters • Zone Transfer Failure The total number of failed zone transfers of the master DNS server. • Zone Transfer Request Received The total number of zone transfer requests received by the master DNS server. • Zone Transfer SOA Request Sent The total number of zone transfer SOA requests sent by the secondary DNS server. • Zone Transfer Success The total number of successful zone transfers of the master DNS server.

Logging DNS Servers A second performance feature of Windows 2000 DNS is the logging option. The logging option allows the administrator to track various server events and save them to a text file for review and analysis. When selectively enabled, the DNS Server service can perform additional trace-level logging of selected types of events or messages for general troubleshooting and debugging of the server. Debug logging can be resource intensive, affecting overall server performance and consuming disk space. Therefore, it should be used only temporarily when more detailed information about server performance is needed. To select and enable debug logging options on the DNS server, perform the following steps: 1. In the DNS Console, right-click the DNS server, and select Properties. 2. Click the Logging tab. 3. Select the DNS server events for debug logging (as shown in Figure 10.8), and click OK.


289

FIGURE 10.8 The Logging tab of the DNS server (DC1) with the Query, Answers, and Full Packets debugging options set.

This process slows DNS server performance. For this reason, all debug logging options are disabled by default. To disable again, select Reset to Default in the Logging tab. To view a DNS server debug log file, perform the following steps: 1. Stop the DNS Server service. 2. Open WordPad, Microsoft Word, or another text editor. 3. On the File menu, click Open. 4. In Open, for File Name, specify the path to the DNS server debug log file. By default, if the applicable DNS server is running locally, the file and path are as shown here: %SystemRoot%\System32\Dns\Dns.log 5. After you specify the correct path and file, click Open to view the log file.

NOTE By default, the Dns.log file is empty if the debug logging option has never been enabled.


290

DNS Log Windows 2000 Server provides a set of DNS server performance counters that can be used to measure and monitor various aspects of server activity. As mentioned earlier, the DNS log is saved in RTF format and is located in %Systemroot%\System32\dns\Dns.log. The DNS server can be configured to create a log file that records the following types of events: • Queries • Notification messages from other servers • Dynamic and secure dynamic updates • Memory usage counters • Content of the question-and-answer section for DNS query message • Number of queries the DNS server sends and receives • Number of DNS requests received over a specific port (UDP or TCP) • Number of full sent packets • WINS lookups • Zone transfer counters To change the directory and filename in which the DNS log appears, add the following entry to the registry with the REG_SZ data type: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LogFilePath

Set the value of LogFilePath equal to the file path and filename for the DNS log. The minimum dns.log file size is 64KB; the maximum is 4MB. To change the file size (in bytes), add the following entry to the registry with the REG_DWORD data type: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS \Parameters\LogFileMaxSize

Set the value of LogFileMaxSize equal to the desired file size in bytes. When the log file reaches the maximum size, Windows 2000 writes over the beginning of the file. Higher values provide longer data retention, but reduce disk space. Lower values use less disk space, but limit data retention times.

CAUTION Do not leave DNS logging during normal operation because it consumes both processing and hard-disk resources. Enable it only when diagnosing and solving DNS problems.


291

Tuning Advanced Server Parameters For most implementations of Windows 2000 DNS, the installation defaults are acceptable and should not require modification. However, the DNS console can be customized to tune certain advanced parameters, depending on the situations. For making these adjustments, use the Advanced tab in DNS server Properties. These are the advanced parameters you may be able to customize: • Disable recursion Determines whether the DNS server uses recursion. By default, Windows 2000 DNS servers are enabled to use recursion. • BIND secondaries Determines whether to use fast transfer format when transferring a zone to DNS servers running legacy Berkeley Internet Name Domain (BIND) implementations. By default, all Windows-based DNS servers use a fast zone transfer format, which uses compression and can include multiple records per TCP message during a connected transfer. This format is compatible with BIND-based DNS servers running versions 4.9.4 and later. • Fail on load if bad zone data Sets the DNS server to parse files strictly. By default, Windows 2000 DNS servers log data errors, ignore any erred data in zone files, and continue to load a zone. This option can be reconfigured using the DNS console so that the DNS Server service logs errors and fails to load a zone file containing record data that is determined to have errors. • Enable round robin Determines whether the DNS server uses round robin to rotate and reorder a list of multiple host (A) resource records if a queried hostname is for a computer configured with multiple IP addresses. By default, Windows 2000 DNS servers use round robin. • Enable netmask ordering Determines whether the DNS server reorders a list of multiple A resource records based on local subnet priority if the queried hostname is for a multihomed computer. • Secure cache against pollution Determines whether the server attempts to clean up responses to avoid cache pollution.


By default, Windows 2000 DNS servers use local subnet priority.

292

By default, Windows 2000 DNS servers use a secure response option that eliminates adding unrelated resource records included in a referral answer to their cache. In most cases, any names added in referral answers are typically cached and help expedite the speed of resolving subsequent DNS queries. With this feature, however, the server can determine that referred names are potentially polluting or are unsecured and discard them. The server determines whether to cache the name offered in a referral on the basis of whether it is part of the exact related DNS domain name tree for which the original queried name was made. For example, if a query was originally made for test.kevinkocis.com and a referral answer provided a record for a name outside of the kevinkocis.com domain name tree, such as north-rim.com, then that name would not be cached where this feature is enabled for use. DNS server parameter key values are stored in the Windows 2000 registry. Each of these is a value stored under the following: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

NOTE When using registry-based configuration, changes are applied to DNS servers only when the service is re-initialized. If a value is manually changed directly in the registry, the DNS server must always be restarted for the new value to be used.

Summary When deploying and integrating Windows 2000 DNS, DHCP, and WINS, it is a good policy to consider the suggested standards recommended by Microsoft. Some strategies regarding DNS server location and redundancy will vary depending on the size of the organization, as well as the sight layout. However, some standards, such as at least one DNS server per subnet, are strongly recommended. Some verification processes are recommended after the DNS server has been installed and configured. These steps, including utilizing the Monitoring tab in the DNS console and the nslookup tool, should be performed during a pilot process to ensure proper connectivity and resolution. Administrators can maintain and monitor the server through events logged in the DNS Server event log (in Event Viewer) and performance counters in System Monitor. Logging is another option for debugging DNS, but it should be used sparingly because it is quite resource intensive.

CHAPTER

Troubleshooting DNS

11

IN THIS CHAPTER • The Troubleshooting Process

295

• Troubleshooting Name Resolution

297

• Identifying and Verifying DNS Problems

297

• Solving Problems with Dynamic Update

305

• Troubleshooting Zone Problems

307

• DNS Server Log Errors and Event Codes • Informational Events • DHCP Server Issues

309 319

• Network Monitor Analysis • Summary

321

319

308

294

The process of identifying and resolving DNS and Active Directory issues is relatively straightforward. This chapter focuses on the troubleshooting process, some related techniques and methods, and the associated error codes reported in Event Viewer. From the certification process, systems engineers learn a specific sequence of events to follow when troubleshooting communication-related issues. This sequence acts as a roadmap to accurately identify a problem, diagnose that problem, and then resolve it. A sample roadmap for resolving DNS and Active Directory issues is shown in Figure 11.1.

Does this process/ computer work?

Use these troubleshooting tools (somecovered in Chapter 12)

networking

Event Viewer ping ipconfig netdiag netmon

name resolution

Event Viewer ping nslookup nbtstat dnscmd

domain controller

Event Viewer dcdiag dsastat ndsutil

Event Viewer netsetup authentication

access control

Finished

FIGURE 11.1 A sample troubleshooting roadmap for DNS and Active Directory.

Event Viewer dsacls netdom clone principlal sdcheck

Troubleshooting DNS CHAPTER 11

The Troubleshooting Process As with any troubleshooting process, always start at the physical layer. Begin by verifying the cabling connections and power to the appropriate devices. Next, verify network connectivity through the client or server local area connection. Also check the computer’s Event Viewer for any logged warnings or errors.

NOTE Event Viewer can be found in the Administrative Tools directory. To view messages about the DNS server, select the DNS server log. To view messages about the DNS client, select the System Log.

On a client, if DNS event errors appear in the System Log, that is an indication that the client has a problem dynamically updating DNS records. On a domain controller, the Netlogon event error 5781 is typically an indication of a dynamic update problem. Specific methods for troubleshooting these errors are discussed later in this chapter. Next, ensure that the system is connected to the network and has the proper IP address through the ipconfig tool. To view IP configuration details with the ipconfig tool, type ipconfig /all at the command prompt, and press Enter. Verify that the host has an IP address (not 0.0.0.0) and a subnet mask. If the computer is a DHCP client on a routed network, verify that the DHCP server is listed in the IP information, and that the computer received a default gateway. Figure 11.2 shows a well-connected local area network using the ipconfig utility. Next, test TCP/IP connectivity using the ping command as follows: 1. At the command prompt, ping the loopback address (127.0.0.1). If this fails, verify that the computer was restarted after TCP/IP was installed and configured. 2. Ping the computer’s IP address. If this fails, restart the computer and check the routing table by typing route print at the command prompt. Also check the bindings to verify that TCP/IP is bound to the adapter you are attempting to ping.

11 TROUBLESHOOTING DNS

Because some of the tools documented in this process apply to the troubleshooting of Active Directory, they are beyond the scope of this book. However, the tools used for networking and name resolution are covered in detail in Chapter 12, “Remote and Command-Line Utilities for DNS Management.”

295

296

3. Ping the default gateway IP address. If necessary traverse to other subnets. If this fails, verify the correct default gateway IP address and make sure that it is functioning. 4. Ping a functioning remote host IP address (from a different subnet). If this fails, verify that the correct remote host IP address is being used. Also verify that all gateways between the computer and the remote host are up and functioning. 5. Ping the DNS server IP address. If this fails, verify the correct DNS server IP address and that the server is up and functional. These five steps are critical when diagnosing local computer issues. They are precursors to diagnosing any DNS or Active Directory issues.

FIGURE 11.2 An IP configuration for a domain controller displayed using the IPCONFIG utility.

TIP In reality, you may choose to ping a remote host by name first because this will confirm that all seven layers are functioning (including name resolution). If that attempt fails, try the aforementioned steps.


Troubleshooting Name Resolution

This section discusses diagnostic tools and gives examples of possible name resolution problems, along with suggested solutions. Let’s first review how a Windows 2000–based computer registers names and locates domain controllers.

Registering Names and Locating Domain Controllers When a Windows 2000 domain controller is booted, it registers both its DNS domain name (with the DNS service) and a NetBIOS name (with WINS or another transport service if NetBIOS is enabled). The domain controller then registers DNS records including multiple SRV records, A records, and CNAME records identifying its location in the domain and forest. When a Windows 2000–based computer logs onto a domain, the computer either queries DNS to locate a domain controller for authentication, or sends a mailslot message to locate a domain controller (if the name of the logon domain is a NetBIOS name). The domain controller information is then cached at the local client, so a new query is not required for subsequent domain controller discoveries.

Identifying and Verifying DNS Problems Typically, there are three main situations one may encounter regarding DNS problems: • The user cannot log in to the domain. • The Active Directory Installation Wizard fails to find an existing domain controller in the domain or forest. • A domain controller cannot locate another domain controller. The tools discussed in the following sections are useful for troubleshooting DNS problems.

Verifying DNS Configuration For the previously mentioned problems, it is important to verify the DNS configurations for the client and server, as well as the zone files (or registered records in Active Directory–integrated zones). Remember that DNS locates network resources for Active Directory, so proper configuration is essential to directory service functionality. Start by verifying the following:


If the user or computer continues to experience a problem connecting to Active Directory, after network connectivity has been verified, a name resolution problem may exist. If other hosts or network resources cannot be resolved with queries, it could mean that domain names and/or hostnames are not being resolved to IP addresses.

297

298

• Client configuration • Server configuration • Registered and replicated resource records in DNS Before verifying the configuration of the DNS server and the existence of records, verify that the DNS client settings are correct.

Verifying DNS Client Settings When verifying DNS settings for a Windows 2000 client, perform the following steps: 1. Right-click My Network Places, and then click Properties. 2. Right-click the appropriate connection, and select Properties. 3. Click Internet Protocol (TCP/IP), and then select Properties. 4. On the Internet Protocol (TCP/IP) Properties page, verify or enter the IP address of the existing DNS server in the Preferred DNS Server field. Add the IP address of an alternate DNS server in the Alternate DNS Server field. If DHCP is enabled, verify that the DNS servers are listed after typing ipconfig /all at the command prompt. 5. Click Advanced if additional alternate DNS servers are required. Then click the DNS tab, and then enter the servers in the DNS Server Addresses box. Use ipconfig to view the DNS client settings and reset locally cached DNS name queries, as well as registering the resource records for a dynamic update client. For more information on the functionality of the ipconfig command-line tool, see Chapter 12. After verifying the client configuration and DNS servers, the next step is to verify that the DNS server contains the necessary records.

Verifying Records on the DNS Server The most common DNS error a client will receive is the “Name not found” error message. There are various possible reasons for this error, including the following: • A nonvalid IP and network configuration exists on the client. • A hardware or network issue is preventing contact. • The client cannot contact the DNS server (may have the wrong preferred or alternate server). • A DNS server is not running or responding to queries (or the zone may be paused). • The DNS server is not authoritative for the name and is responding with outdated answers, or may be authoritative (secondary) with outdated answers. • The primary zone may have missing or erroneous data. • There is an invalid user or machine query.


If the client does not have a valid TCP/IP configuration, either renew the IP configuration from the DHCP server (using the ipconfig /renew command) or adjust the configuration settings manually for a static client. If the client was not able to contact a DNS server due to a network or hardware-related failure, first verify that the client’s network connection (cables and adapters) is functioning. Next, follow the ping command process as mentioned in the first section of this chapter. If the DNS client cannot contact its configured DNS servers and the network settings have been verified, start by pinging the preferred DNS server by its IP address. If the server does not respond, that indicates a network connectivity problem between the client and the DNS servers, not a DNS issue. If the server responds to pinging its IP address, but not its name, this is indicative of a DNS issue. In this case, verify the forward lookup zone data and the host (A) record for the DNS server. If the DNS server is not running, make sure that the computer is up and that the DNS service has started. If these factors are positive and the zone is not paused, but the server is not responding to queries, use the nslookup utility (as covered in Chapter 12) to test whether the server can respond to clients. In the situation in which the client’s primary DNS server does not have authority for the queried name and cannot locate the authoritative server, confirm whether the DNS domain name is one for which the primary DNS servers are authoritative. If so, verify that the DNS server loads the zone where the host (A) record should exist. If the primary DNS server does not host the zone, then there is a DNS configuration error, perhaps with the root hints, because the recursive query is not occurring. Verify the root hints on the DNS server. If the DNS client receives stale responses from the DNS server, the first step is to determine whether the DNS server is authoritative for the name. If the preferred server is authoritative for the name and answered using incorrect data, it indicates that the zone may be hosting stale resource record data. In that situation, add or remove the appropriate resource record, and reload the zone. If dynamic updates are enabled, the Windows 2000 client can force registration and update of its resource records via use of the ipconfig /registerdns command at a command prompt.


To resolve any client IP and network configuration issues, verify the TCP/IP configuration settings using the ipconfig /all command.

299

300

NOTE The ipconfig /registerdns command will reregister only the A and PTR resource records. For a DC to reregister its SRV resource records, the Netlogon service must be restarted.

If the preferred server is not authoritative for the queried name, the information sent to the client was most likely cached during an earlier recursive lookup. In this situation, clear the server names cache. If the server is secondary with outdated answers, initiate a zone transfer at the secondary server to its master server to update the zone. You may also consider decreasing the refresh interval on the zone to keep files current. In the situation in which the primary zone might have missing or erroneous data, verify that the primary server’s zone has data. The most likely cause for this scenario is a failed update request, such as support for dynamic update that has not been fully implemented or configured. Check the requirements for dynamic update and make sure that the clients and servers are compliant. In the case of directory-integrated zones, the records for the errored query have been updated in Active Directory, but due to replication latency, not all DNS servers loading the zone were updated yet. By default, all DNS servers that load zones from Active Directory poll it at a set interval (typically every 15 minutes), and update the zone for any incremental changes to it. If WINS lookups are integrated within the specified zone, verify that WINS is not the source of the errored data. In most cases, incorrect data in a positive query response, indicates one of three possibilities: • A DNS name was incorrectly entered. • A host/NetBIOS name was suffixed with an unintended DNS domain name by the local client resolver. • Incorrect or erroneous resource records were specified in the DNS server. Confirm that the user did not enter the name in error. Verify the exact set of characters entered by the user for the original query. Also, check the application settings, such as Web browser configurations for any proxy or other restrictive settings. If the name used in the initial query was unqualified, and not the fully qualified domain name (FQDN), try using the FQDN instead in the client application and repeating the query.


NOTE

If the FQDN query succeeds and returns correct data in the response, the most likely cause of the problem is a misconfigured DNS domain suffix search list used in the client resolver settings. If the DNS configuration does not support dynamic updates, or administrators manage the zone data manually, verify that the records for the query are correct, and modify them accordingly.

Verifying DNS on the Domain Controller As mentioned earlier, domain controllers register additional various resource records that indicate their role. Every time the Netlogon service initiates (such as when the server is restarted), the service attempts to register the SRV resource records in the netlogon.dns file under the %systemroot%\System32\config folder. To join a domain, the following record is used: _ldap._tcp.dc._msdcs.<domain name>

To join a tree, the following record is used: _ldap._tcp.dc._msdcs.<parent domain>

To join a forest, the following record is used: _ldap._tcp.dc._msdcs.

The nslookup tool can confirm that the appropriate records are registered in DNS. The following example shows how to use an nslookup query to verify that the generic records for the kevinkocis.com domain (such as _ldap._tcp.kevinkocis.com) exists in DNS: C:\>nslookup Default Server: dc1.kevinkocis.com Address: 192.168.1.1 > set type=SRV > _ldap.tcp.kevinkocis.com Server: dc1.kevinkocis.com Address: 192.168.1.1 _ldap.tcp.kevinkocis.com SRV service location: priority = 0 weight = 0 port = 389 svr hostname = dc1.kevinkocis.com


Be sure to include the trailing dot (.) at the end of the name to indicate that the name entered is an exact FQDN.

301

302

_ldap.tcp.kevinkocis.com SRV service location: priority = 0 weight = 0 port = 389 svr hostname = dc2.kevinkocis.com dc1.kevinkocis.com internet address = 192.168.1.1 dc2.kevinkocis.com internet address = 192.168.1.2

The most common DNS error a server will encounter is that it is not responding to client queries. There are various possible reasons for this error, including the following: • The DNS server is affected by a network failure. • The DNS server is reachable through basic network testing but is not responding to DNS queries from clients. • The DNS server has been configured to limit service to a specific list of its configured IP addresses. The IP address originally used in testing its responsiveness is not included in this list. • The DNS server has been configured to disable the use of its automatically created default reverse lookup zones. • The DNS server provides incorrect data for queries it successfully answers. • The DNS server is not configured to use other DNS servers to assist it in resolving queries. • Current root hints for the DNS server are not valid. • The DNS server does not have network connectivity to the root servers. • Other problems exist with updating DNS server data, such as an issue related to zones or dynamic update.

NOTE Because most DNS server problems start with failed queries at a client, start with troubleshooting the DNS client first before addressing the DNS server.

If the server experiences a network or hardware-related failure, first verify that the network connection (cables and adapters) is functioning. If the server hardware appears to be functioning properly, follow the ping command process as mentioned in the first section of this chapter. Then use the nslookup command to test whether the server can respond to DNS clients. In some cases, a multihomed DNS server may be configured to restrict the IP addresses that listen and respond to queries. It is possible that the IP address being used by clients to contact


For issues with reverse lookup zones, verify that automatically created reverse lookup zones exist on the server. There is a possibility that the zones were disabled through manual administration of the server registry. To verify that these zones have been created at a Windows 2000 DNS server, perform the following steps: 1. Open the DNS console. 2. Under the View menu, click Advanced. 3. Expand the DNS server container and the Reverse Lookup Zones folder. 4. Verify the following reverse lookup zones: •

0.in-addr.arpa

•

127.in-addr.arpa

•

255.in-addr.arpa

If the DNS server does not resolve names correctly due to incorrect data, this may be due to one of the following problems: • Resource records that have not been dynamically updated in a zone. • Stale resource records from cached lookups that have not been scavenged or deleted. • Typographical errors during the addition or modification of static records. If a DNS server fails to resolve a name that is not part of the zone for which it is authoritative, this is usually indicative of a failed recursive query (a process for resolving remote names delegated to other DNS zones and servers). A recursive query may fail for several reasons, including the following: • A remote DNS server does not respond. • A remote DNS server provides incorrect data. • A query timeout occurs.


it is not in the list of interfaces to provide DNS service to clients. Try testing the server for a response again, using an IP address known to be in the restricted interfaces list for the server. If the DNS server responds for that address, simply add the missing server IP address to the list.

303

304

NOTE All Windows 2000 DNS servers are enabled to use recursion by default. However, the option to disable recursion is available through the DNS advanced server options in the DNS console. Verify that this option is not disabled before proceeding with remote errors.

When root hints are configured and implemented correctly, they should always point to the domain root and top-level domain DNS servers. By default, Windows 2000 DNS servers are configured or updated to use root hints depending on the initial deployment. For example, if the DNS server is installed as the first DNS server on the network, it is configured as a root server and root hints are disabled because the server is authoritative for the root zone. If the DNS server is not the first installed on the network, the Configure DNS Server Wizard can update the root hints from an existing DNS server. Lastly, if there are no other DNS servers on the network but the company needs to resolve Internet DNS names, the default root hints file can be used. This list includes the Internet root servers authoritative for the Internet DNS namespace. A common reason for root hint issues outside of the previously mentioned possibilities is poor network connectivity between the local DNS server and the root servers.

NOTE The DNS service has a 15-second recursive timeout value before it fails a recursive query. This value typically does not need to be changed, unless severe networking issues warrant a time increase.

Verifying Record Registration Use the following steps to diagnose and troubleshoot the problem: • Review Event Viewer on the DNS server responsible for registering the records. Check for any DNS and Netlogon errors. • Run the Netdiag tool, and look for the expression [FATAL] in the results. For more information about the Netdiag tool, see Chapter 12. • Verify that the DNS server is hosting the zone authoritative for the name to be registered and that it allows dynamic updates (if this is the preferred registration option). In performing this task, verify the following:


• The Allow Dynamic Update list box is set to Yes. • The client’s host (A) record exists in DNS. • Verify that the registering client is properly configured with the preferred and alternate DNS servers If all the preceding steps have been verified, the DNS server can receive dynamic updates from the clients. If necessary, perform the troubleshooting steps in the following section.

Solving Problems with Dynamic Update If dynamic update does not register a resource record properly, use the following process to troubleshoot the problem. If the client does not point to a valid DNS server (for example, find out which DNS servers the client is pointing to by typing ipconfig /all from the command prompt), change the DNS server list. Force the client that is experiencing registration failures to renew its registration by typing the following: ipconfig /registerdns

Wait approximately five minutes, check Event Viewer on the DNS server, and then check for any DNS events registered. Check whether dynamic update is enabled for the zone that is authoritative for the name of the client that is attempting the update. Run the Netdiag tool to verify whether the registration failure has been corrected. At least one DNS server should have the DNS entry registered correctly. Due to replication latency, other DNS servers may not have the registration immediately. When dynamic DNS updates fail for a client and the DNS server is online and operational, there are several possible reasons for the problem, including the following: • The client or its DHCP server does not support the dynamic update protocol. • The client has missing or incomplete DNS configuration settings. • The DNS server does not support dynamic updates. • The DNS server is not configured to support dynamic updates. • The DNS server is configured to allow only secure dynamic updates and an access/security problem exists. • The DNS server is not accepting dynamic updates because the zone is being transferred. • The DNS server or zone file is not available.


• The SOA record contains the FQDN for the primary server.

305

306

Dynamic DNS clients need to register either directly (must be a Windows 2000 client) with a DNS server, or through a Windows 2000 DHCP server that acts as a proxy for non–Windows 2000 clients. Verify that the DHCP server (for non–Windows 2000 clients) and DNS server for the client support the DNS dynamic update protocol described in RFC 2136.

NOTE Windows NT Server 4.0 does not support the dynamic update protocol.

Another common reason for the client failing to dynamically update is its lack of a DNS suffix (either a primary suffix or a connection-specific suffix), which may result in the client attempting to register its name in the wrong domain (such as a root or top-level domain). To update the DNS configuration for a client, configure a primary DNS suffix at the client computer for static TCP/IP clients. DHCP clients can be configured for a domain suffix via the Windows 2000 DHCP server. The default for Windows 2000 DNS server zones is to not accept dynamic updates. The administrator will need to modify zone properties to allow updates.

NOTE If a Windows 2000 DHCP server must perform a secure dynamic update on behalf of clients that are running a version of Windows earlier than Windows 2000, place the DHCP server in a special security group called DNSUpdateProxy.

CAUTION Any objects created by the DNSUpdateProxy group have no security. As a result, they can be updated by any computer on the network.

If secure dynamic updates are configured for the server, zone or resource-record security might block or prevent updates from a DNS client or its DHCP server.


NOTE

If necessary, change the Access Control List (ACL) for the Active Directory–integrated zones to modify security permissions in order to enable the appropriate update functionality. This process should be required only if the computer requesting the update is different from the owner or creator of the resource records.

TIP The client-side DNS code has a cache for performance. In this scenario, a recent IP address change may not be seen if the cache TTL has not expired for the old IP address. At a command prompt, type ipconfig /flushdns, which purges the DNS Resolver cache. To disable the DNS Caching Resolver, either type net stop dnscache at a command prompt or set the registry key REG_DWORD MaxCacheEntryTtlLimit to a value of 0. The registry key can be found in the following location: HKEY_LOCAL _MACHINE\System\CurrentControlSet\Services\DnsCache\Parameters

Troubleshooting Zone Problems The most common DNS zone errors revolve around zone transfers. There are various possible reasons for these errors, including the following: • The DNS Server service is stopped or the zone is paused. • There is a lack of DNS server connectivity. • Identical serial numbers are used at the source and destination servers. • There is erroneous or noncompliant resource record data. • Authoritative zone data is incorrect. • Zone delegations are not configured correctly. If the DNS service is paused or stopped, verify that there are no current troubleshooting or logging efforts in process, and restart the service or zone.


Secure update can be enabled only for Active Directory–integrated zones. Active Directory–integrated zones may be configured only on domain controllers running the DNS server service.

307

308

In the case of poor or lacking server connectivity, use the network troubleshooting (ping) process mentioned earlier in the chapter. If the zone transfer fails due to identical serial numbers at the source and destination servers, use the DNS console to increase the value of the serial number for the source zone on the master server, and then initiate a zone transfer at the secondary server.

TIP To increase the zone serial number, open the zone properties and select the Start of Authority (SOA) tab. Then click Increment to increase the number.

For any problems related to DNS interoperability in terms of zone transfers or erroneous data between Windows 2000 DNS servers and BIND DNS, consider the following possibilities: • Zone transfer formats (BIND uses uncompressed, whereas Windows 2000 uses fast transfer by default) To accommodate zone transfer with older BIND server(s), change the advanced server options at the Windows 2000 DNS server(s). • WINS and WINS-R record resolution BIND servers do not recognize these Microsoft-proprietary records in zone data being transferred, which can cause the zone transfer to fail. Select Do Not Replicate This Record when configuring WINS properties at the applicable zone. • Nonstandard data (no RFC compliance) Both Windows 2000 DNS and BIND use records that are not standard. If the zone files are edited manually, make sure that they are formatted and implemented according to standard record usage and formatted as documented in the DNS RFCs. In regard to zone delegations, the error can typically be resolved using the New Delegation Wizard. Because zones contain information about DNS domains and subdomains, each parent zone needs to have delegation records added for each subdomain delegated to its own zone. With Windows 2000 DNS servers, use the New Delegation Wizard in the DNS console to add these records accordingly.

DNS Server Log Errors and Event Codes This section documents a comprehensive listing of events 1 through 1614 recorded in the DNS server log. The events are categorized by type. The error log can be viewed in Event Viewer on any server running the Windows 2000 DNS service.


Informational Events 2. (Informational) DNS_EVENT_STARTUP_OK The DNS server has started. 3. (Informational) DNS_EVENT_SHUTDOWN The DNS server has shut down.

Initialization Errors 111 (Error) DNS_EVENT_CANNOT_CREATE_THREAD The DNS server could not create a thread, which may indicate a lack of system resources. 112 (Error) DNS_EVENT_RECURSION_INIT_FAILED The DNS server could not initialize a recursion thread, which may indicate a lack of system resources. For both of these errors, close any unused programs not in use. If this does not resolve the error, restart the DNS server or reboot the server.

WINS and NBSTAT Errors 130 (Error) DNS_EVENT_WINS_INIT_FAILED The DNS server could not initialize WINS lookup, which may indicate a lack of system resources. Close any unused programs not in use. If this does not resolve the error, restart the DNS server or reboot the server. 131 (Error) DNS_EVENT_NBSTAT_INIT_FAILED The DNS server did not initialize WINS reverse lookup (WINS-R) through NetBIOS adapter status lookup. Although the DNS server will continue to operate, it will not try to perform any WINS-R lookups. This error may be the result of an incorrect configuration. Restart the server and verify that the WINS/NetBT configuration in the TCP/IP client properties is correct. 132 (Warning) DNS_EVENT_NBSTAT_ADAPTER_FAILED The DNS server did not open the specified adapter for NetBIOS adapter status lookup. Although this event is just a warning, the administrator should verify that the WINS/NetBT configuration for the adapter is correct.


1. (Informational) DNS_EVENT_STARTING The DNS server is starting.

309

310

RPC Initialization Error 140 (Error) DNS_EVENT_RPC_SERVER_INIT_FAILED The DNS server could not initialize the remote procedure call (RPC) service. If the service is not running, try starting the RPC service. If it still fails, reboot the server.

Winsock/Interface Initialization Errors 403 (Error) DNS_EVENT_CANNOT_CREATE_TCP_SOCKET The DNS server could not create a Transmission Control Protocol (TCP) socket. Restart the DNS server or reboot the server. 404 (Error) DNS_EVENT_CANNOT_BIND_TCP_SOCKET The DNS server could not bind a Transmission Control Protocol (TCP) socket. An IP address of 0.0.0.0 can indicate a valid “any address” configuration in which all configured IP addresses on the computer are available for use. 405 (Error) DNS_EVENT_CANNOT_LISTEN_TCP_SOCKET The DNS server could not listen on a Transmission Control Protocol (TCP) socket. An IP address of 0.0.0.0 can indicate a valid “any address” configuration in which all configured IP addresses on the computer are available for use. 406 (Error) DNS_EVENT_CANNOT_CREATE_UDP_SOCKET The DNS server could not create a User Datagram Protocol (UDP) socket. 407 (Error) DNS_EVENT_CANNOT_BIND_UDP_SOCKET The DNS server could not bind a User Datagram Protocol (UDP) socket.

NOTE For errors 403 through 407, restarting the DNS service or rebooting the server resolves the issue.

408 (Error) DNS_EVENT_OPEN_SOCKET_FOR_ADDRESS The DNS server could not open a socket for the specified address. Verify that this is a valid IP address (if it is not, remove it from the list of IP interfaces in the DNS Console under Server Properties), and then stop and restart the DNS server. If the error occurred on the server’s only IP interface, remove the DNS\Parameters\ListenAddress value in the services section of the registry, and restart the server.


409 (Warning) DNS_EVENT_UPDATE_LISTEN_ADDRESSES The DNS server list of restricted interfaces contains IP addresses not configured on the server. Use the Interfaces tab in DNS Console, Properties to verify and reset the listening IP addresses. This is just a warning event. 410 (Error) DNS_EVENT_INVALID_LISTEN_ADDRESSES The DNS server list of restricted interfaces contains IP addresses not configured on the server. Use the Interfaces tab in DNS Console, Properties to verify and reset the listening IP addresses. Remember, the DNS server will use all IP interfaces on the computer. 411 (Error) DNS_EVENT_HOSTENT_MAX_IPS The DNS server did not bind to all the server’s available IP addresses. Use the Interfaces tab in DNS Console, Properties to edit (and add) any missing IP addresses. Then stop and restart the DNS service.

NOTE Although it incurs minimal administrative and performance overhead to have a large number of IP interfaces on the server, it is recommended that the administrator remove any unnecessary IP addresses from the server.

412 (Warning) DNS_EVENT_MANY_IP_INTERFACES The DNS server is bound to too many IP addresses. As indicated in the preceding error, unnecessary IP addresses can be removed to eliminate this warning. 413 (Warning) DNS_EVENT_NON_DNS_PORT This warning occurs on a multihomed DNS server when it sends requests to other DNS servers on a port other than its default port (TCP port 53). The server’s DNS configuration does not run on all available IP addresses on the server, so it is impossible to guarantee that a DNS query to a remote DNS server will be sent to the IP address the DNS server is using. It is also impossible to guarantee that the response to that IP address will be received on the DNS port. To avoid this problem, sends to other DNS servers will be done on a non-DNS port, and the response will be received regardless of the IP address used.


If the server’s IP address is valid, check to see whether another operating program, such as another DNS server, is trying to use the DNS port.

311

312

If an administrator wants to use the DNS port for sends to other DNS servers, the configuration must be changed to use all the server’s IP addresses for DNS (eliminate the listen address list) or limit the DNS server to use a single IP address. 414 (Warning) DNS_EVENT_SINGLE_LABEL_HOSTNAME The DNS server computer currently has no DNS domain name. The DNS name is merely a hostname with no domain (example: myhost rather than myhost.kevinkocis.com). The configuration may lack a primary DNS domain for the server, and because the DNS server has only a hostname, all zones created will have default records (SOA and NS) created using only this hostname (that is, myhost) for the server’s hostname. As a result, incorrect and failed referrals may result when clients and other DNS servers use these records for name resolution. To correct this problem, verify and enter the domain or workgroup name in the DNS Domain Name field in the System Properties, Network Identification tab under the Properties button. Then reboot the server. After the reboot, verify that the zone’s SOA and NS records use the server’s correct domain name.

Registry Boot Errors 500 (Error) DNS_EVENT_INVALID_REGISTRY_ZONE The DNS server has detected that the zone has invalid or corrupted registry data. To resolve the error, delete the applicable zone subkey from the registry (under DNS server parameters), and then re-create the zone. 501 (Error) DNS_EVENT_INVALID_ZONE_TYPE The DNS server has detected that the zone has a missing or corrupted zone type in registry data. To resolve the error, delete the applicable zone subkey from the registry (under DNS server parameters), and then re-create the zone. 502 (Error) DNS_EVENT_NO_ZONE_FILE The DNS server has detected that the primary zone has no zone filename stored in the registry. To resolve the error, either update the zone filename or delete the zone and re-create it. To remove the zone, delete the applicable zone subkey from the registry (under DNS server parameters), and then re-create it. 503 (Error) DNS_EVENT_SECONDARY_REQUIRES_MASTERS The DNS server has detected that the secondary zone has no master IP addresses in the registry. Because secondary zones require at least one master server, the administrator must add or change the IP address to a confirmed master DNS server.


504 (Error) DNS_EVENT_REG_ZONE_CREATION_FAILED

505 (Error) DNS_EVENT_INVALID_REGISTRY_ZONE_DATA The DNS server zone has invalid or corrupted registry data. Remove or repair any corrupted registry key values and confirm that the zone database is available in the DNS Console. 506 (Error) DNS_EVENT_INVALID_REGISTRY_PARAM The DNS server has invalid or corrupted registry parameter. To resolve the error, either update the zone filename or delete the zone and re-create it. To remove the zone, delete the applicable zone subkey from the registry (under DNS server parameters), and then re-create it. 507 (Error) DNS_EVENT_INVALID_REGISTRY_FORWARDERS The DNS server encountered invalid or corrupted forwarder parameters in registry data. To resolve this error, verify and reset the forwarder information in the Server Properties, Forwarders tab of the DNS Console.

General Database Load Errors 706 (Warning) DNS_EVENT_NO_ROOT_NAME_SERVER The DNS server does not have any root name server database entries or cache. Either Active Directory or the root hints file (cache.dns) requires at least one NS resource record (and a corresponding host [A] record), or the DNS server will not answer queries for names outside its authoritative zones. To correct this warning, update the server root hints in the DNS Console. 707 (Error) DNS_EVENT_NO_CACHE_FILE_SPECIFIED The DNS server is not root authoritative and no root hints were specified in the cache.dns file. If the server is not a root server, the cache file must contain at least an NS resource record for indicating an internal root DNS server and a corresponding host (A) record for that server. Otherwise, the DNS server will not answer queries for names outside its authoritative zones. To correct this error, update the server root hints in the DNS Console. 708 (Informational) DNS_EVENT_CACHING_SERVER_ONLY The DNS server did not detect any zones of either primary or secondary type, and therefore will operate as a caching-only server. It will not be authoritative for any zones.


The DNS server could not create a zone from registry data as a result of one or more corrupt zone registry key values or because the zone file is missing. Remove or repair any corrupted registry key values and confirm that the zone database is available in the DNS Console.

313

314

File Loading Errors 1000 (Error) DNS_EVENT_FILE_OPEN_ERROR The DNS server could not open the file. Open the %SystemRoot%\System32\Dns folder and verify that the file exists. Also make sure that it contains valid data. 1001 (Error) DNS_EVENT_FILE_NOT_MAPPED The DNS server could not map the specified file to memory. If closing unused programs does not resolve the error, reboot the server to clear the memory. 1003 (Error) DNS_EVENT_CACHE_FILE_NOT_FOUND The DNS server could not find or open the root hints file, Cache.dns, in the %SystemRoot%\System32\Dns folder. Verify that this file is located in this folder and that it contains at least one name server (NS) resource record, indicating a root DNS server and a corresponding host (A) resource record for that server. 1004 (Error) DNS_EVENT_COULD_NOT_OPEN_DATABASE The DNS server could not find or open the specified zone file in the %SystemRoot%\System32\Dns folder. Verify that it is located in this folder and that it contains valid data. 1008 (Error) DNS_EVENT_FILE_PATH_TOO_LONG The DNS server was unable to create the path for the specified file in the specified folder. Because the specified path is too long, the administrator must select a different path.

Boot File Problems 1200 (Error) DNS_EVENT_BOOT_FILE_NOT_FOUND The DNS server could not find or open the boot file. This file should be located in the %SystemRoot%\System32\Dns folder, and be named Boot. 1201 (Error) DNS_EVENT_ZONE_CREATION_FAILED The DNS server could not create the specified zone. Verify that the zone file is located in the SystemRoot%\System32\Dns folder and that it contains valid data. 1202 (Warning) DNS_EVENT_DIRECTORY_DIRECTIVE The DNS server encountered an unsupported “folder” directive in the server boot file. Verify that all the database files are located in the %SystemRoot%\system32\dns folder. The folder directive is ignored. 1203 (Error) DNS_EVENT_NO_FORWARDING_ADDRESSES


To correct the problem, in the DNS console right-click the server, select Properties, and then click the Forwarders tab. Add the appropriate IP addresses for forwarders. 1204 (Error) DNS_EVENT_SLAVE_REQUIRES_FORWARDERS The DNS server encountered a “slave” directive without a preceding forwarders list. Despite this error, the DNS server will continue running. However, it will not be able to forward queries to the forwarders. To correct the problem, in the DNS console right-click the server, select Properties, and then click the Forwarders tab. Add the appropriate IP addresses for forwarders. 1205 (Error) DNS_EVENT_UNKNOWN_BOOTFILE_OPTION The DNS server encountered an unknown boot option that is therefore ignored. Consider removing the option from the boot file located in the %SystemRoot%\System32\Dns folder. 1206 (Error) DNS_EVENT_MISSING_DIRECTORY_NAME The DNS server encountered a missing database folder name. Verify the folder’s existence and rename as appropriate.

Database File Parsing Problems 1501 (Error) DNS_EVENT_COULD_NOT_PARSE_DATABASE The DNS server could not parse the specified zone file. Verify that the zone file is located in the %SystemRoot%\System32\Dns folder and that it contains valid data. 1502 (Error) SymbolicName=DNS_EVENT_DATABASE_PARSING_ERROR The DNS server could not parse the specified token in the zone file. The DNS service will continue to load and function. However, it is recommended that the administrator either correct the token or remove the record from the zone file. 1503 (Error) SymbolicName=DNS_EVENT_PARSING_ERROR_LINE The DNS server could not parse the specified zone file. The DNS service will continue to load and function. However, it is recommended that the administrator either correct the line or remove it from the zone file. 1504 (Error) SymbolicName=DNS_EVENT_UNEXPECTED_TOKEN


The DNS server encountered a “forwarders” directive with no forwarding addresses. Despite this error, the DNS server will continue running. However, it will not be able to forward queries to the forwarders.

315

316

The DNS server could not parse an unexpected token in the zone file. The DNS service will continue to load and function. However, it is recommended that the administrator either correct the token or remove the record from the zone file. 1505 (Error) SymbolicName=DNS_EVENT_UNEXPECTED_END_OF_TOKENS The DNS server encountered the unexpected end of a line in the specified zone file. To correct the problem, edit this line as appropriate in the zone file. 1506 (Error) SymbolicName=DNS_EVENT_INVALID_TOKEN The DNS server encountered an invalid token in the specified zone file. The DNS service will continue to load and function. However, it is recommended that the administrator either correct the token or remove the record from the zone file. 1507 (Error) SymbolicName=DNS_EVENT_INVALID_CLASS_TOKEN The DNS server encountered an invalid class token in the specified zone file. The DNS server will continue to load and function while ignoring this record. However, it is recommended that the administrator correct the record class to use the Internet (IN) class or remove it from the zone file. Remember, the DNS server supports only the Internet (IN) class in resource records. 1508 (Error) SymbolicName=DNS_EVENT_IGNORING_FILE_RECORD The DNS server is ignoring an invalid resource record in the specified zone file. See the previously logged event for a description and resolution for the error.

Directive Problems 1520 (Warning) SymbolicName=DNS_EVENT_UNKNOWN_DIRECTIVE The DNS server encountered the unknown directive, which was ignored. 1521 (Warning) SymbolicName=DNS_EVENT_UNSUPPORTED_DIRECTIVE The DNS server encountered the unsupported directive, which was ignored. 1522 (Warning) SymbolicName=DNS_EVENT_OBSOLETE_DIRECTIVE The DNS server encountered the obsolete directive, which was ignored. 1523 (Warning) SymbolicName=DNS_EVENT_DIRECTIVE_NOT_YET_IMPLEMENTED The DNS server encountered the specified directive in the zone file. Because the directive is not yet supported, it was ignored.

Domain Name Problems 1540 (Error) SymbolicName=DNS_EVENT_DOMAIN_NODE_CREATION_ERROR


The DNS server was unable to create the domain node.

The DNS server encountered an invalid domain name in the specified zone file. The DNS server continues to load and function while ignoring the invalid name. However, it is recommended that the administrator correct the name or remove the record from the zone file. 1542 (Error) SymbolicName=DNS_EVENT_INVALID_DOTTED_DOMAIN_NAME The DNS server encountered an invalid domain name. 1543 (Error) SymbolicName=DNS_EVENT_DOMAIN_NAME_TOO_LONG The DNS server encountered a domain name that exceeds the maximum length. The DNS server continues to load and function while ignoring the invalid name. However, it is recommended that the administrator correct the name or remove the record from the zone file. 1544 (Error) SymbolicName=DNS_EVENT_INVALID_ORIGIN_TOKEN The DNS server encountered an invalid token in the specified zone file. The DNS server continues to load and function while ignoring the invalid name. However, it is recommended that the administrator correct the token or remove the record from the zone file. 1545 (Error) SymbolicName=DNS_EVENT_FILE_NODE_OUTSIDE_ZONE The DNS server encountered a name outside the zone in the specified zone file. The DNS server continues to load and function while ignoring the invalid name. However, it is recommended that the administrator correct the record or remove it from the zone file. 1546 (Error) SymbolicName=DNS_EVENT_FILE_INVALID_NS_NODE The DNS server encountered an invalid name server (NS) resource record in the specified zone file. The DNS server continues to load and function while ignoring the invalid name server (NS) name. However, it is recommended that the administrator correct the name or remove the record from the zone file. 1547 (Error) SymbolicName=DNS_EVENT_FILE_INVALID_A_NODE The DNS server encountered an invalid host (A) resource record in the specified zone file. The DNS server continues to load and function while ignoring the invalid host (A) name. However, it is recommended that the administrator correct the name or remove the record from the zone file.

Resource Record Problems 1600 (Error) SymbolicName=DNS_EVENT_UNKNOWN_RESOURCE_RECORD_TYPE The DNS server encountered an unknown or unsupported resource record type (such as a reccord type that includes $INCLUDE or $ORIGIN statements) in the specified zone file. The DNS


1541 (Error) SymbolicName=DNS_EVENT_PARSED_INVALID_DOMAIN_NAME

317

318

server continues to load and function while ignoring the invalid type. However, it is recommended that the administrator correct the resource type or remove the record from the zone file.

NOTE Both $INCLUDE and $ORIGIN statements are supported in BIND DNS, but not in W2K DNS.

1601 (Warning) SymbolicName=DNS_EVENT_OBSOLETE_RECORD_SKIPPED The DNS server encountered the obsolete record type, and therefore the record was ignored. MD or MF record types are obsolete and should be converted to the MX record type and format as shown here: north-rim.com MX 10 mai11.eur.north-rim.com

1602 (Error) SymbolicName=DNS_EVENT_INVALID_SOA_RECORD The DNS server encountered an invalid Start of Authority (SOA) resource record, which is required in every zone file. To correct the problem, modify or repair the SOA record in the specified zone file in the %SystemRoot%\System32\Dns folder. 1610 (Error) SymbolicName=DNS_EVENT_PARSED_ADD_RR_AT_CNAME The DNS server encountered a resource record in the specified zone file for a domain name with an existing CNAME record. CNAME records (when used) must be the only record for the domain name they are aliasing. Either the record or its conflicting CNAME record needs to be deleted from the zone file. 1611 (Error) SymbolicName=DNS_EVENT_PARSED_CNAME_NOT_ALONE The DNS server encountered a CNAME resource record in the specified zone file for a domain name with existing records. CNAME records (when used) must be the only record for the domain name they are aliasing. Either the record or its conflicting CNAME record needs to be deleted from the zone file. 1612 (Error) SymbolicName=DNS_EVENT_PARSED_CNAME_LOOP The DNS server encountered a CNAME resource record in the specified zone file that forms a name loop with another CNAME record in the same zone. One of the CNAME records must be removed from the zone file. 1613 (Error) SymbolicName=DNS_EVENT_INVALID_PREFERENCE The DNS server encountered an invalid preference value, which must be a valid 16-bit unsigned integer. To correct the problem, modify the preference field to a valid value. 1614 (Error) SymbolicName=DNS_EVENT_INVALID_DWORD_TOKEN


DHCP Server Issues To determine whether the DHCP server is the problem, release the client IP address, restart DHCP, and then renew the IP address by carrying out the following commands at a command prompt: (at the client) net stop dhcp (at the server) net start dhcp (at the server) ipconfig /renew (at the client) ipconfig /release

If the client still cannot connect to the domain controller (even with a valid IP address), a Network Monitor sniffer trace of the connection attempt might be useful.

Network Monitor Analysis Network Monitor sniffer traces track all network traffic to and from a computer, including the respective DHCP server that issues dynamic IP addresses. A limited version of Network Monitor is packaged with Windows 2000 Server, whereas the full version is included with Microsoft’s Systems Management Server (SMS).

Installing Network Monitor To install the limited version of Network Monitor on the Windows 2000 server, from the Start menu, point to Settings, Control Panel, Add/Remove Programs, Add/Remove Windows Components, Management and Monitoring Tools, Details, Network Monitoring Tools.

NOTE The full version of Network Monitor (from SMS) allows administrators to capture and view every packet on the network.

Network Monitor displays the speed of operations, the source to network traffic, if packets are being dropped or if processes are experiencing timeouts. Be sure to run Network Monitor on the computer experiencing problems or on a machine located on the local hub or switch.


The DNS server encountered a token with the wrong format in the specified zone file. The DNS server continues to load and function while ignoring the token. However, it is recommended that the administrator correct the token or remove the record from the zone file.

319

320

A Sample Network Frame of DNS Dynamic Update The following text example shows the captured network frame indicating a client’s request to dynamically update its DNS server: DNS: 0x1B:Dyn Upd UPD records to dc1.kevinkocis.com. of type Host Addr DNS: Query Identifier = 27 (0x1B) DNS: DNS Flags = Query, OpCode - Dyn Upd, RCode - No error DNS: 0............... = Request -----> DNS: .0101........... = Dynamic Update DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......0........ = Iterative query desired DNS: ........0....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Zone Count = 1 (0x1) DNS: Prerequisite Section Entry Count = 0 (0x0) DNS: Update Section Entry Count = 3 (0x3) DNS: Additional Records Count = 0 (0x0) DNS: Update Zone: kevinkocis.com. of type SOA on class INET addr. DNS: Update Zone Name: kevinkocis.com. DNS: Update Zone Type = Start of zone of authority DNS: Update Zone Class = Internet address class DNS: Update: dc1.kevinkocis.com. of type Host Addr on class Req. for any (2 records present) DNS: Resource Record: dc1.kevinkocis.com. of type Host Addr on class Req. for any (2 records present) DNS: Resource Name: dc1.kevinkocis.com. DNS: Resource Type = Host Address DNS: Resource Class = Request for any class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 0 (0x0)

This frame also includes the record to be written: DNS: Resource Record: dc1.kevinkocis.com. of type Host Addr on class INET addr. DNS: Resource Name: dc1.kevinkocis.com. DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 192.168.1.1 ---> example IP address

When using Network Monitor, note the following options:


• Administrators can save a capture to a *.cap file for later use. • Administrators can save filters (to see only IP information, for instance) and reload them. Press F8 to modify the filter. • Capture Buffer Settings allows for configuration of larger buffers, depending on sniff duration.

The Capture Process To begin the capture process in Network Monitor, press F10. After the process is started, perform the failing operation (such as the DNS query). Captured network packets will be displayed in the bottom window of Network Monitor. Press F11 to stop a capture, then F12 to display the capture. After capturing is complete, save the file for future analysis.

Summary This chapter focused on the basic troubleshooting process for Windows 2000 DNS, focusing on Microsoft-documented errors displayed in Event Viewer. Utilities (such as ipconfig and ping) are essential to troubleshooting network and name resolution issues. Because dynamic updates are new to Windows 2000 DNS, there are some processes to follow when determining whether the issue is client or server related. Microsoft has documented server and error logs that range from 1 to 1614. This chapter also listed the errors, their categories, and solution opportunities.


• The Network Monitor user interface is context sensitive, and different results will occur when either the Capture Window or a capture window is selected.

321

Remote and Command-Line Utilities for DNS Management

IN THIS CHAPTER • IPCONFIG

324

• NSLOOKUP

326

• PathPing

329

• DNSCMD

330

• NBTSTAT

335

• NetDiag

337

• NETSH

342

• Saving Output from Troubleshooting Tools 344 • Summary

344

CHAPTER

12

324

Several command-line utilities can be used for DNS troubleshooting and management. These tools are usually referenced after verifying an error or issue in the client or server’s Event Viewer (which should be the starting point for troubleshooting). However, investigating the source of Windows 2000 DNS errors, as well as the resolution, requires additional tools. Windows 2000 offers the following tools for researching DNS and networking event log errors: • ipconfig • nslookup • pathping • dnscmd • nbtstat • netdiag • netsh

IPCONFIG Ipconfig.exe provides diagnostic information related to a computer’s TCP/IP network configuration. Ipconfig also accepts various Dynamic Host Configuration Protocol (DHCP) commands, allowing a system to update or release its TCP/IP network configuration. The ipconfig utility was included in the Windows NT 4.0 platform, and its functionality is expanded in Windows 2000. The syntax for the ipconfig utility is as follows: Ipconfig [/? | /all | /release adapter | /renew adapter]

With no parameters, ipconfig displays only the IP address, subnet mask, and default gateway for any adapters bound to TCP/IP. With the /all switch, ipconfig displays all the current TCP/IP configuration values, including the IP address, subnet mask, default gateway, DHCP functionality, and WINS and DNS configuration (including hostname and domain suffix). The following items detail additional ipconfig switches and their functionality: •

/all

Produces a detailed configuration report for all interfaces. •

/release adapter

Releases the IP address for the specified adapter. If no adapter name is specified, all DHCP leases for adapters bound to TCP/IP are released.

Remote and Command-Line Utilities for DNS Management CHAPTER 12

•

325

/renew adapter

Renews the IP address for the specified adapter. If no adapter name is specified, all DHCP leases for adapters bound to TCP/IP are renewed. •

/flushdns

Removes all DNS Resolver Cache entries. •

/registerdns

Refreshes all DHCP leases and reregisters DNS names. •

/displaydns

•

/showclassid adapter

Displays all the DHCP class IDs allowed for the specified adapter. •

/setclassid adapter

Modifies the DHCP class ID for the specified adapter. •

/?

Displays the previous command options in a list as shown in Figure 12.1.

FIGURE 12.1 The ipconfig command with the help (/?) switch.

12 REMOTE AND COMMAND-LINE UTILITIES

Displays the contents of the DNS Resolver Cache.

326

NSLOOKUP Nslookup.exe is a command-line administrative tool for testing and troubleshooting DNS servers. Nslookup can perform DNS queries and examine the contents of zone files on local and remote servers. This tool is installed along with the TCP/IP protocol through Control Panel. For nslookup to function, the following criteria must be met: • The querying host must have TCP/IP installed. • At least one DNS server must be specified in the DNS tab of the TCP/IP properties page (if the machine is configured for DHCP, this value can be automatically assigned). Nslookup.exe can be run in two modes: interactive and non-interactive. Non-interactive mode can be used when a specific type of information needs to be returned. This is the syntax for non-interactive mode: nslookup -option hostname server

Interactive mode allows for continuous information to be returned. To start Nslookup.exe in interactive mode, simply type nslookup at the command prompt: C:\> nslookup Default Server: dc1.kevinkocis.com Address: 192.168.1.1

Typing help or ? at the command prompt generates a list of available commands (as shown in Figure 12.2). Anything typed at the command prompt that is not recognized as a valid command is assumed to be a hostname, and an attempt is made to resolve it using the default server. To interrupt interactive commands, press Ctrl+C. To exit interactive mode and return to the command prompt, type exit at the command prompt. Various options can be set in nslookup by use of the set command at the command prompt. The following text is a list of options: > set all Default Server: dc1.kevinkocis.com Address: 192.168.1.1 Set options: nodebug defname search recurse nod2 novc

Remote and Command-Line Utilities for DNS Management CHAPTER 12 noignoretc port=53 type=A class=IN timeout=2 retry=1 root=A.ROOT-SERVERS.NET. domain=kevinkocis.com MSxfr IXFRversion=1 srchlist=kevinkocis.com

327


FIGURE 12.2 The nslookup utility commands and parameters.

To look up different data types within the domain name space, type set type or set q (for querytype) at the command prompt. For example, to query for the mail exchanger data, type the following: C:\> nslookup Default Server: dc1.kevinkocis.com Address: 192.168.1.1 > set q=mx > mail Server: mail.kevinkocis.com Address: 192.168.1.10 mail.kevinkocis.com

MX preference = 10, mail exchanger =

328

mailhost.domain.com >

mail.kevinkocis.com internet address = 192.168.1.10

The first time a query is made for a remote name, the answer is authoritative, but subsequent queries are non-authoritative. The first time a remote host is queried, the local DNS server contacts the DNS server that is authoritative for that domain. The local DNS server then caches that information, so subsequent queries can be answered from the local server’s cache. To query another name server directly, use the server or lserver commands to switch to that name server. The lserver command uses the local server to get the address of the server to switch to, whereas the server command uses the current default server to get the address (as shown in the following text): C:\> nslookup Default Server: dc1.kevinkocis.com Address: 192.168.1.1 > server 192.168.1.2 Default Server: dc2.kevinkocis.com Address: 192.168.1.2 >

Nslookup can be used to transfer an entire zone by using the ls command. This is useful to see all the hosts within a remote domain. This is the syntax for the ls command: ls [- a | d | t type] domain [> filename]

Using ls with no arguments returns a list of all address and name server data. The -a switch returns alias and canonical names, -d returns all data, and -t filters by type. The following text is an example of the ls command: >ls kevinkocis.com [dc1.kevinkocis.com] kevinkocis.com. kevinkocis.com. kevinkocis.com. kevinkocis.com. gc._msdcs gateway dc1 dc2 host1 host2 >

A A NS NS A A A A A A

192.168.1.2 192.168.1.1 server = dc2.kevinkocis.com server = dc1.kevinkocis.com 192.168.1.1 192.168.1.101 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4


329

PathPing Whereas Ping is a tool used to verify IP-level connectivity, PathPing.exe is a tool that detects packet loss over multiple-hop trips. Pathping is a new utility in Windows 2000 that traces the route of a packet and displays information on packet losses for each router in the destination path. Pathping can also be used to troubleshoot Quality of Service (QoS) connectivity. The PathPing tool combines features of Ping and Tracert with additional information not available in either. PathPing sends packets to each router on the way to a final destination over a period of time, and then computes results based on the packets returned from each hop. The syntax for pathping is as follows:

PathPing can identify which routers or links might be causing network problems. Several switches are available, as shown in Table 12.1. TABLE 12.1 PathPing Switches Switch

Name

Description

-n

Hostnames

-h max_hops

Maximum hops

-g host list

Host list

-p milliseconds

Period

Does not resolve addresses-to-hostnames. Maximum number of hops to search for target. (The default is 30.) Routes hosts using a target list of router IP addresses. Time to wait between pings. (The default is 250ms.)

-q num_queries

Number of queries

-w milliseconds

Timeout

-T

Layer-2 Priority

-R

RSVP Help

-?

Number of queries per hop. (The default is 100.) Time waited for each reply. (The default is 3000ms.) Tests connectivity using Layer-2 priority tags. Tests whether each hop is RSVP-aware. Displays this list.

REMOTE AND COMMAND-LINE UTILITIES

pathping [-n] [-h maximum_hops] [-g host-list] [-p period] [-q number of_queries] [-w timeout] [-t] [-R] [-r] target_name

12

330

DNSCMD The command-line tool dnscmd.exe handles most of the DNS server management tasks performed from the DNS console. Dnscmd allows the administrator to view the configuration parameters of DNS servers, zones, and resource records. In addition, dnscmd can be used to manually modify these properties, to create and delete zones and resource records, and to force replication events between DNS server physical memory and DNS databases and datafiles. The dnscmd command can be installed by copying it from the \Support\Enterprise\Reskit folder on the Windows 2000 Server CD. After it’s installed, simply type dnscmd at the command prompt as shown in Figure 12.3.

FIGURE 12.3 The dnscmd command and parameters.

NOTE Dnscmd replaces and enhances the functionality of dnsstat.exe, a tool included in the Windows NT 4.0 Resource Kit.

Syntax For command-line Help, type dnscmd command /?

/?.

For Help on a specific command, type dnscmd


331

The syntax for dnscmd.exe is as follows: dnscmd

ServerName

Command

[Command Parameters]

Let’s take a look at the parameters shown in the preceding syntax in more detail: •

dnscmd

The command-line utility. •

ServerName

Specifies the name of the DNS server based on the following inputs: or “.”—Specifies the local computer. The connection is made via Local Procedure Call (LPC).

•

IP Address—Specifies

•

DNS Name—Specifies

•

NetBIOS Name—Specifies

No Name

the server by IP addresses in the x.x.x.x format. The connection is made via Remote Procedure Call (RPC) over TCP/IP.

the server by the fully qualified domain name (FQDN). The connection is made via Remote Procedure Call over TCP/IP. the server by the NetBIOS computer name. The connection is made via Remote Procedure Call over named pipes.

Command

One of the commands listed in the following section. •

Command Parameters

The optional parameters associated with some of the commands listed in the following section.

NOTE Dnscmd uses the credentials of the currently logged-on user.

DNSCMD Switches The dnscmd utility includes numerous switches to allow for command-line configuration of Windows 2000 DNS. This section details all the available switches and provides examples for the popular commands. The dnscmd switches include the following: •

/Info

Provides DNS server properties (see also /ZoneInfo). The following text is an example of the /info parameter:


•

•

332

C:\>dnscmd 192.168.1.1 /info Query result: Server info: ptr = 0007EB80 server name = dc1.kevinkocis.com version = C2000005 DS container = c Configuration: dwLogLevel = 00000000 dwDebugLevel = 00000000 dwRpcProtocol = FFFFFFFF dwNameCheckFlag = 00000002 cAddressAnswerLimit = 0 dwRecursionRetry = 3 dwRecursionTimeout = 15 dwDsPollingInterval = 300 Configuration Flags: fBootMethod = 3 fAdminConfigured = 1 fAllowUpdate = 1 fDsAvailable = 1 fAutoReverseZones = 1 fAutoCacheUpdate = 0 fSlave = 0 fNoRecursion = 0 fRoundRobin = 1 fLocalNetPriority = 1 fStrictFileParsing = 0 fLooseWildcarding = 0 fBindSecondaries = 1 fWriteAuthorityNs = 0 Aging Configuration: ScavengingInterval = 0 DefaultAgingState = 1 DefaultRefreshInterval = 168 DefaultNoRefreshInterval = 168 ServerAddresses: Addr Count = 1 Addr[0] => 192.168.1.1 ListenAddresses: NULL IP Array. Forwarders: NULL IP Array. forward timeout = 5 slave = 0 Command completed successfully.


•

333

/Config

Resets server or zone configuration. This command option has more detailed switches for configuring DNS options ranging from protocols to refresh intervals. •

/EnumZones

Enumerates zones on the specified DNS server as shown in the following text example:

•

DS file DS file file DS

Rev Rev Rev Rev

Auto Auto Auto

Up=0 Up=0 Up=2 Up=0 Up=0 Up=1

12 Aging

Aging

/Statistics

Queries/clears server statistics data. This command provides a detailed results display. •

/ClearCache

Clears the DNS server cache. •

/WriteBackFiles

Writes back all zone or root hint datafile(s) for the specified zone. •

/StartScavenging

Initiates server scavenging. •

/ResetListenAddresses

Resets/selects server IP address(es) to serve DNS requests. •

/ResetForwarders

Resets/selects forwarders IP address(es). •

/ZoneInfo

Displays zone information. •

/ZoneAdd

Creates a new zone on the DNS server. •

/ZoneDelete

Deletes the specified zone on the DNS server, as shown here: C:\>dnscmd . /zonedelete kevinkocis.com Are you sure to you want to DeleteZone?(y/n) y


C:\>dnscmd 192.168.1.1 /enumzones Enumerated zone list: Zone Count = 6. . 0 0.in-addr.arpa 1 1.168.192.in-addr.arpa 1 127.in-addr.arpa 1 255.in-addr.arpa 1 kevinkocis.com 1 Command completed successfully.

334

DNS Server . deleted zone kevinkocis.com: Status = 0 (0x00000000) Command completed successfully.

•

/ZonePause

Pauses the specified zone on the DNS server. •

/ZoneResume

Resumes the specified zone on the DNS server. •

/ZoneReload

Reloads the specified zone from its databases (file or directory service) on the DNS server. •

/ZoneWriteBack

Writes back the specified zone to the file on the DNS server. •

/ZoneRefresh

Forces refresh of the specified secondary zone on the DNS server from its master. •

/ZoneUpdateFromDs

Updates the Active Directory–integrated zone by data from the directory service (DS) on the DNS server. •

/ZoneResetType

Changes the zone type (Primary/Secondary/AD-integrated) of the zone on the DNS server. •

/ZoneResetSecondaries

Sets/resets a notify list for the specified zone on the DNS server. •

/ZoneResetScavengeServers

Resets scavenging servers for a specific zone. •

/ZoneResetMasters

Resets master name servers for a specific zone. •

/EnumRecords

Enumerates records at a DNS server name. •

/RecordAdd

Creates a record in the specified zone or a root hints file on the specified DNS server. •

/RecordDelete

Deletes a record from the specified zone or root hints on the specified DNS server.


•

335

/NodeDelete

Deletes all records at a name from the specified zone, root hints, or cache for the DNS server. •

/AgeAllRecords

Forces timestamp and aging on the records in a zone. •

/Restart

Restarts the specified DNS server service.

12

Nbtstat.exe is designed to help troubleshoot NetBIOS name resolution problems. When a network is functioning normally, NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. The process for NetBIOS name resolution can occur through various processes, including local cache lookup, WINS server query, broadcast, LMHOSTS lookup, Hosts lookup, and DNS server query. Nbtstat was included in Windows NT 4.0, and it displays the local NetBIOS name table and the NetBIOS name cache. It also verifies the state of current NetBIOS over TCP/IP connections, updates the Lmhosts cache, and determines the registered names and scope ID.

NOTE Nbtstat arguments are case sensitive.

NBTStat removes and corrects preloaded entries using case-sensitive switches as shown in Table 12.2. TABLE 12.2 NBTStat Switches Switch

Name

Function

-a NetBIOS name

Adapter status by NetBIOS name

-A IP address

Adapter status by IP address

-c

Cache

Returns the NetBIOS name table and MAC address of the host’s network card. Provides the same information as -a when the target’s IP address is provided. Displays the contents of the NetBIOS name cache.


NBTSTAT

336

TABLE 12.2 Continued Switch

Name

Function

-n

Names

-r

Resolved

-R

Reload

-RR

Release refresh

-s

Sessions by NetBIOS names

-S

Sessions by IP addresses

Number

Interval

-?

Help

Lists the names registered locally by NetBIOS applications. Displays a count of all names resolved by broadcast or WINS server. Clears the name cache and reloads all #PRE entries from LMHosts. Sends name release packets to the WINS server and starts a refresh, reregistering all names from the DNS server. Lists the NetBIOS sessions table converting destination IP addresses to computer NetBIOS names. Lists the current NetBIOS sessions and their status, with the IP addresses. Redisplays selected statistics at intervals specified in seconds, pausing between each display. Ctrl+C stops the statistical display. Displays this list.

The NetBIOS Remote Cache Table One of the useful switches for nbtstat is -c, which identifies IP addresses residing in the NetBIOS/TCP remote cache table. It also displays the most recent resolved NetBIOS names. Table 12.3 displays a sample query of recent NetBIOS names that have been resolved on a host on the network 192.168.2.


337

TABLE 12.3 NetBIOS/TCP Remote Cache Names Name

Type

Eng1 Host2 Dc1 North-rim

UNIQUE UNIQUE UNIQUE GROUP

Host Address

Life (sec)

192.168.2.201 192.168.2.202 192.168.2.50 600 192.168.2.15 480

60 120

12

NOTE

Table 12.4 provides a key for understanding the NetBIOS types mentioned in Table 12.3. TABLE 12.4 Explanations of NetBIOS Types Name

Type

Usage

00 00 01 01 03 20 2F 33 1B 1C 1E

Unique Group Unique Group Unique Unique Group Group Unique Group Group

Workstation Domain Messenger Service Master Browser Logon Name/Computer Name/Messenger Service Server Lotus Notes Lotus Notes Domain Master Browser Domain Controllers Browser Service Elections

NetDiag NetDiag.exe is a command-line diagnostic tool that helps isolate networking and connectivity problems by performing a series of tests. The netdiag tool does not require parameters or switches, and it diagnoses network problems by verifying a client’s network configuration and connections, including Internet Packet Exchange (IPX) and NetWare configurations.


This table shows what is in the NetBIOS/TCP remote name cache, not the DNS cache. If WINS was the form of name resolution, the cache should be purged.

338

Run NetDiag whenever a computer is having network problems. The tool attempts to diagnose the problem and may identify problem areas for closer examination. The command-line syntax for NetDiag is as follows: netdiag [[/q|/v|/debug][/l][/d:DomainName][/fix][/dcaccountenum] [/test:TestName|/skip:TestName]]

No switches or syntax need to be specified, but several are available that can increase or decrease the amount of detail in the NetDiag reports. These switches are listed in Table 12.5. TABLE 12.5 NetDiag Switches Switch

Name

Function

/q

/debug

Quiet output Verbose output Most verbose output

/l

Log output

/d:DomainName

Find DC Fix DNS problems

Lists only the tests returning errors. Lists enhanced test details. Lists the most enhanced detail, including reasons for success or failure. Creates an output document (NetDiag.log) in the current folder. Locates a domain controller. Troubleshoots DNS on domain controllers. Enumerates computer accounts on the domain controller. Runs only the specified test. Skips the specified test. Specifies the test to be run or skipped. For a complete list, see Table 12.4. Displays this list.

/v

/fix

TestName

Domain controller account enumeration Perform single test Skip one test Test name

/?

Help

/DCAccountEnum /test: /skip:

NOTE To verify the DNS registration for a domain, run netdiag /debug on all domain controllers.


339

NetDiag Tests NetDiag reviews the system registry, dynamic link library (DLL) files, and output from other tools to locate potential issues. Netdiag is a new utility in Windows 2000 that verifies currently enabled network services or functions and performs network configuration tests in order as listed in Table 12.6. If the computer is not running one of the network troubleshooting tools listed in Table 12.6, that test is skipped. TABLE 12.6 NetDiag Tests Function

Details

NDIS

Network adapter status

IPConfig

IP configuration

Member

Domain membership

NetBTTransports Autonet

Transports test Autonet address

IPLoopBk

IP loopback ping

DefGw

Default gateway

NbtNm

NetBT name test

WINS

WINS service test

Winsock

Winsock test

Lists the network adapter configuration information. If the NIC fails, the remaining tests are cancelled. Provides the functionality of the ipconfig /all command, pings the DHCP and WINS servers, and verifies the default gateway. Lists domain details and verifies that the NetLogon service is started, and queries the primary domain security identifier (SID). Lists NetBT transports. Verifies interfaces using Automatic Private IP Addressing (APIPA). Pings the IP loopback address (127.0.0.1). Pings the default gateways for each interface. Is comparable to the nbtstat -n command. Sends NetBT name queries to the WINS server(s). Uses Windows Sockets to retrieve available transport protocol information.


Test Name

340

TABLE 12.6 Continued Test Name

Function

DNS

DNS test

Browser

DsGetDc

DcList

Trust

Details

Checks the DNS cache service and checks whether the computer is registered on the DNS servers. For domain controllers, this test verifies the registration of the DNS entries in Netlogon.dns. The /fix option will tries to re-register the domain controller record. Redirector and browser test Checks whether the workstation service is running. Retrieves the transport lists from the redirector and the browser. Checks whether the NetBT transports are in the list from the NetBT transports test. Checks whether the browser is bound to all the NetBT transports and whether the computer can send mailslot messages. Tests via both browser and redirector. DC discovery test Finds a generic domain controller from directory service, finds the primary domain controller, and then finds a Windows 2000 domain controller. If the tested domain is the primary domain, checks whether the domain GUID stored in Local Security Authority (LSA) is the same as the domain GUID stored in the domain controller. If not, the test returns a fatal error; if the /fix option is used, DsGetDC tries to fix the GUID in LSA. DC list test Gets a list of domain controllers from Active Directory, and verifies status. If the previous attempt fails, uses the browser to find the domain controllers, checks their status, and adds them to the list. Trust relationship test Tests trust relationships to the primary domain only if the computer is a member workstation, member server, or domain controller. Checks the primary domain SID, and verifies domain controller secure connectivity.


341

TABLE 12.6 Continued Function

Details

Kerberos

Kerberos test

Tests Kerberos protocols only if the computer is a member computer or domain controller and the user is not logged on to a Windows 2000 domain account and not logged on to a local account. Connects to LSA and looks up the Kerberos package. Gets the ticket cache of the Kerberos package and checks whether the Kerberos package has a ticket for the primary domain and the local computer. Tests LDAP on all the active domain controllers running Active Directory in the domain. Searches the LDAP directory with various authentication types. Prints the static and persistent entries in the routing table. Displays statistics of protocols and current TCP/IP network connections. Similar to the NetStat tool. Lists all bindings, even if not currently enabled, and the binding owner. Displays the settings and status of current active remote access connections. Retrieves all available line devices, and displays each configuration. Determines whether NetWare is using the directory tree or bindery logon process, and determines the default context if NetWare is using the directory tree logon process. Examines the network’s IPX configuration. Checks the current status of the IP Security Policy Agent service, and any current IPSec policy (if any).

LDAP

Lightweight Directory Access Protocol (LDAP) test

Route

Route test

NetStat

NetStat test

Bindings

Bindings test

WAN

WAN test

Modem

Modem test

NetWare

NetWare test

IPX

IPX test

IPSec

IP Security test


Test Name

342

NETSH Netsh is a tool an administrator can use to configure and monitor Windows 2000–based computers at a command prompt. The netsh tool, new to Windows 2000, can direct the context commands you enter to the appropriate helper, which then carries out the command. A helper is a dynamic link library (.dll) file that extends the functionality of the netsh tool by providing configuration, monitoring, and support for one or more services, utilities, or protocols. The helper may also be used to extend other helpers. The netsh tool can be used to configure the following network parameters: • Interfaces • Routes and routing protocols • Filters • Routing and Remote Access Server (RRAS) service behavior • Scripted setup of DHCP service • Scripted setup of WINS service The netsh tool can also display the configuration of a currently running router on any computer, and because it is scriptable, it can run batch file collections against a router if necessary. This is the syntax for the Netsh tool: netsh [-r router name] [-a AliasFile] [-c Context] [Command | -f ScriptFile]

To display a list of subcontexts and commands that can be used in a context, type the context name followed by a space and a ? at the netsh> command prompt. For example, to display a list of subcontext and commands that can be used in the /routing context, type routing ? at the netsh> command prompt, and then press Enter (as shown in Figure 12.4).

NETSH Contexts Context strings are appended to the Netsh.exe tool command and are passed to an associated helper. The helper may have one or more entry points that map to contexts. These are the toplevel contexts available in the Netsh.exe tool (as directly referenced from the Microsoft text in the Help window): Commands in this context: .. - Goes up one context level. ? - Displays a list of commands. aaaa - Changes to the ‘aaaa’ context. abort - Discards changes made while in offline mode. add - Adds a configuration entry to a list of entries. alias - Adds an alias.

Remote and Command-Line Utilities for DNS Management CHAPTER 12 -

Exits the program. Commits changes made while in offline mode. Deletes a configuration entry from a list of entries. Changes to the ‘dhcp’ context. Displays a configuration script. Runs a script file. Exits the program. Displays a list of commands. Changes to the ‘interface’ context. Sets the current mode to offline. Sets the current mode to online. Pops a context from the stack. Pushes current context on stack. Exits the program. Changes to the ‘ras’ context. Changes to the ‘routing’ context. Updates configuration settings. Displays information. Deletes an alias. Changes to the ‘wins’ context.

A number of contexts may also nest within other contexts. For more information, refer to the Help file in netsh (by typing /? or /h or /help).

FIGURE 12.4 The netsh command with the list of /routing commands.


bye commit delete dhcp dump exec exit help interface offline online popd pushd quit ras routing set show unalias wins

343

344

Saving Output from Troubleshooting Tools Most of the command line–based troubleshooting tools produce useful information in the form of reports but do not have a switch or an option offering to save their reports to disk. However, the display output of any tool results can be saved to a text file that can be viewed in Notepad. To perform this task, at the command prompt type this: toolname /switch > toolname.txt

In the toolname string, use the tool (such as ipconfig) followed by any applicable switch(es). The redirector (>) transfers the screen output to the text file named at the end of the command. The output file is then saved in the current folder or directory by default.

Summary Event Viewer is an initial troubleshooting utility, but for more detailed information, administrators must rely on command-line utilities such as ipconfig and nslookup for more detailed analysis. All command-line utilities take advantage of switches (or tags) that enable them to filter information or provide more detail. The results are then displayed back in the command line. If necessary, the displayed results can be saved to a text file in the current folder for record keeping.

Resource Record Types

CHAPTER

A

346

A—Host Address (A) Resource Record Maps a DNS domain name to an Internet Protocol (IP) version 4 32-bit address, as referenced in RFC 1035. Syntax: owner class ttl A IP_v4_address

Example: myhost.eur.north-rim.com.

IN

A

127.0.0.1

AAAA—IPv6 Host Address (AAAA) Resource Record Maps a DNS domain name to an Internet Protocol (IP) version 6 128-bit address as referenced in RFC 1886. Syntax: owner class ttl AAAA IP_v6_address

Example: ipv6_myhost.eur.north-rim.com.

IN

AAAA

4321:0:1:2:3:4:567:89ab

AFSDB—Andrew File System Database (AFSDB) Resource Record Maps a DNS domain name in the server_host_name field to the hostname for a server computer of a server subtype, as referenced in RFC 1183. The subtype field can have either of the following recognized and supported values: • A value of 1 indicates that the server is an AFS version 3.0 volume location server for the named AFS cell. • A value of 2 indicates that the server is an authenticated name server holding the cellroot directory node for the server that uses either Open Software Foundation’s (OSF) DCE authenticated cell-naming system or HP/Apollo’s Network Computing Architecture (NCA).

Resource Record Types APPENDIX A

347

Syntax: owner ttl class AFSDB subtype

server_host_name

Example: north-rim.com.

AFSDB

1 afs-server1.north-rim.com.

ATMA—Asynchronous Transfer Mode Address (ATMA) Resource Record Maps a DNS domain name in the owner field to an ATM address referenced in the atm_address field. The technical specification titled “ATM Name System Specification Version 1.0” is published by the ATM Forum. Syntax: owner ttl class ATMA atm_address

A

Example: ATMA

C5.0079.00010200000000000000.00a03e000002.00

Note: Microsoft can use arbitrary dots in the hexadecimal field instead of 40 hexadecimal digits.

CNAME—Canonical Name (CNAME) Resource Record Maps an aliased or alternate DNS domain name in the owner field to a canonical or primary DNS domain name specified in the canonical_name field. The canonical or primary DNS domain name is required and must resolve to a valid FQDN. Syntax: owner ttl class CNAME canonical_name

Example: www.eur.north-rim.com.

CNAME

websrv1.eur.north-rim.com.

HINFO—Host Information (HINFO) Resource Record Specifies the type of CPU and operating system in the cpu_type and os_type fields, respectively, for the host DNS domain name in the owner field, as documented in RFC 1700.

RESOURCE RECORD TYPES

atm-server

348

Syntax: owner ttl class HINFO cpu_type os_type

Example: nthost1.eur.north-rim.com.

HINFO

INTEL-386

WIN32

ISDN—Integrated Services Digital Network (ISDN) Resource Record Maps a DNS domain name to an ISDN telephone number, as referenced in RFC 1183. Telephone numbers used with this record should follow ITU-T E.163/E.164 international telephone numbering standards, currently compatible with operational international phone numbering plans. Syntax: owner ttl class ISDN isdn_address sub_address

Example: isdnhost1.north-rim.com.

ISDN

13125550099

MB—Mailbox (MB) Resource Record Maps a specified domain mailbox name in the owner field to a mailbox hostname in mailbox_hostname, as specified in RFC 1035. The mailbox hostname must be identical to a host (A) resource record assigned to the host in the same zone. The host must also have a domain mailbox that accepts mail for the specified owner. Syntax: owner ttl class MB mailbox_hostname

Example: mail.eur.north-rim.com.

MB

mailsrv1.eur.north-rim.com

MG—Mail Group (MG) Resource Record Is used to add domain mailboxes as documented in RFC 1035. Each domain mailbox is specified by a mailbox (MB) resource record in the current zone to the domain mailing group identified by owner in this resource record. Names used in the mailbox_name field must be identical to valid mailbox (MB) resource records already present in the current zone.


349

Syntax: owner ttl class MG mailbox_name

Example: administrator.eur.north-rim.com.

MG

mailbox1.eur.north-rim.com mailbox2.eur.north-rim.com mailbox3.eur.north-rim.com

MINFO—Mailbox Mail List Information (MINFO) Resource Record Specifies (in responsible_mailbox) a domain mailbox name for a responsible person who maintains a mailing list or mailbox specified in the owner field, as referenced in RFC 1035. The error_mailbox field can also be used to specify a domain mailbox that receives error messages related to this mailing list or mailbox. Mailboxes specified for responsible contacts and error forwarding must be the same as valid mailbox (MB) records that already exist in the current zone. Syntax:

Example: administrator.eur.north-rim.com. errmb.eur.north-rim.com

MINFO

resmb.eur.north-rim.com

MR—Mailbox Renamed (MR) Resource Record Specifies a domain mailbox name in new_renamed_mailbox, the proper rename of an existing mailbox specified in the owner field. An MR resource record can act as a forwarding entry for a user recently moved to a different mailbox. For more information, review RFC 1035. Syntax: owner ttl class MR new_renamed_mailbox

Example: old-mbox.eur.north-rim.com.

MR

renamedmb.eur.north-rim.com

RESOURCE RECORD TYPES

owner ttl class MINFO responsible_mailbox error_mailbox

A

350

MX—Mail Exchanger (MX) Resource Record Routes messages to a mail exchanger host, listed in mail_exchanger_host of the record. If multiple exchanger hosts are listed in the zone file, a preference value allows for priority. Each exchanger host must have a corresponding host (A) record in the zone. For more information, review RFC 1035. Syntax: owner ttl class MX preference mail_exchanger_host

Example: eur.north-rim.com.

MX

10 mail1.eur.north-rim.com

PTR—Pointer (PTR) Resource Record Points from the name in the owner field to a different DNS namespace location as specified by targeted_domain_name. Used in the in-addr.arpa domain tree to provide reverse lookups of address-to-name mappings, as referenced in RFC 1035. Commonly, each record points to a corresponding host (A) address resource record in a forward lookup zone. Syntax: owner ttl class PTR targeted_domain_name

Example: 1.0.0.10.in-addr.arpa.

PTR

myhost.eur.north-rim.com.

RP—Responsible Person (RP) Resource Record Specifies the domain mailbox name for a responsible person in mailbox_name, as specified in RFC 1183. This name is then mapped to a domain name in text_record_name for associated (TXT) resource records. When RP records are used in DNS queries, subsequent queries are used to retrieve text (TXT) resource record information. Syntax: owner ttl class RP mailbox_name text_record_name

Example: eur.north-rim.com. RP admin.eur.north-rim.com. admin-info.eur.north➥ rim.com. admin-info.eur.north-rim.com. TXT “John Doe, (312) 555-5555”


351

RT—Route Through (RT) Resource Record Provides an intermediate host binding for internal hosts without a direct wide area network (WAN) or external network connection, as referenced in RFC 1183. The RT record is similar to the MX record in that any communication from an internal host is routed through the intermediate_host to the DNS domain name specified in the owner field. A preference value sets the priority when multiple intermediate routing hosts are listed. Each intermediate host must also have a corresponding host (A) address resource record in the zone. Syntax: owner ttl class RT preference intermediate_host


RT RT

5 lanrtr1.eur.north-rim.com 10 wanrtr1.eur.north-rim.com

SRV—Service Locator (SRV) Resource Record

For more information, see the Internet draft “A DNS RR for Specifying the Location of Services (DNS SRV).” Syntax: service.protocol.name ttl class SRV preference weight port target

Example: _ldap._tcp.ms-dcs

SRV 0 0 SRV 10 0

389 dc1.eur.north-rim.com 389 dc2.eur.north-rim.com

TXT—Text (TXT) Resource Record Maps a DNS domain name specified in the owner field to a string of characters in text_string serving as descriptive text, as referenced in RFC 1035. Syntax: owner ttl class TXT text_string


TXT

“Sample of specific domain information.”

A RESOURCE RECORD TYPES

Allows for clients and servers to locate servers providing a similar TCP/IP-based service using a single DNS query operation. This record documents a list of servers for a well-known server port and transport protocol type ordered by preference.

352

WKS—Well-Known Service (WKS) Resource Record Describes the well-known TCP/IP services supported by a protocol on a specific IP address, as documented in RFC 1035. WKS records provide TCP and UDP availability information for servers. Syntax: owner ttl class WKS address protocol service_list


WKS

10.0.0.1 TCP ( telnet smtp ftp )

X25—X.25 (X25) Resource Record Maps a DNS domain name in the owner field to a Public Switched Data Network (PSDN) address number specified in psdn_number. PSDN numbers used with this record should follow the X.121 international numbering plan, as documented in RFC 1183. Syntax: owner ttl class X25 psdn_number


X25

31370054066

Internet Standards Supported by Windows 2000 DNS

APPENDIX

B

354

The following RFCs support a Windows 2000 DNS server implementation.

RFCs: • 1034 Domain Names—Concepts and Facilities • 1035 Domain Names—Implementation and Specification • 1123 Requirements for Internet Hosts—Application and Support • 1886 DNS Extensions to Support IP Version 6 • 1995 Incremental Zone Transfer in DNS • 1996 A Mechanism for Prompt DNS Notification of Zone Changes • 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) • 2181 Clarifications to the DNS Specification • 2308 Negative Caching of DNS Queries (DNS NCACHE) • 2782 DNS SRV for Specifying the Location of Services

Drafts: • Draft-skwan-utf8-dns-02.txt (Using the UTF-8 Character Set in the Domain Name System) • Draft-ietf-dhc-dhcp-dns-08.txt (Interaction Between DHCP and DNS) • Draft-ietf-dnsind-tsig-11.txt (Secret Key Transaction Signatures for DNS [TSIG]) • Draft-ietf-dnsind-tkey-00.txt (Secret Key Establishment for DNS [TKEY RR]) • Draft-skwan-gss-tsig-04.txt (GSS Algorithm for TSIG [GSS-TSIG]) • Draft-levone-dns-wins-lookup-00.txt (WINS Lookup by DNS Server [WINS-Lookup]) Refer to the IETF Web site (www.ietf.org/) for more information on these documents.

A A resource records, 37-38, 71-72, 346 AAAA resource records, 346 Access Control Entries (ACEs), 197 Access Control Lists (ACLs), 60, 197 ACEs (Access Control Entries), 197 ACLs (Access Control Lists), 60, 197 Active Directory BIND, 263 capabilities, 56 components domains, 64 forests, 63-64 namespaces, 62-63 organizational unit (OU), 64-65 overview, 62 sites, 65 trees, 63

DNS integration, 78-80 Group Policy, 204-214 installation, 92-93, 107 integration with DNS, 19-20 interoperability, 61-65 manageability, 56-59 objects security, 201-204 types, 202

overview, 56 replication, 224-226 schemas, 62

INDEX

356

Active Directory

security ACLs (Access Control Lists), 60, 197 authentication, 194-196 Kerberos, 59, 194-196 new features, 60-61 object security, 201-204 object-oriented security, 196-197 permissions, 199, 202-204 public key infrastructure (PKI), 60 rights, 198-199 security descriptors, 199-201 security identifier (SID), 198 security model, 194 x.509 certificates, 60

Service Locator (SRV) record, 66-67 troubleshooting, 294-296 zones, 32-34 Active Directory Connector (ADC), 62 Active DirectoryIntegrated Server, 114-115 ADC (Active Directory Connector), 62 adding counters, 279-281 DNS servers, 156 MMC, 154 address (A) resource records, 37-38, 71-72, 346 administration with MMC adding DNS servers, 156 MMC, 154

Advanced tab, 162-168 configuring DNS servers, 156 customizing, 154-155 Forwarders tab, 161-162 Interfaces tab, 160-161 Logging tab, 168-169 manual DNS updates, 171 modifying DNS servers, 157-159 Monitoring tab, 169-170 removing DNS servers, 156 resource records, 178-190 Security tab, 170 standard primary and secondary zones, 177-178 zone properties, 171-177 administrative tools DNS console, 22 DNScmd.exe , 22 WMI (Windows Management Instrumentation), 22 advanced parameters, tuning, 291-292 AFSDB resource records, 346 All Zone Transfer (AXFR) counters, 283 Andrew File System Database resource records, 346 architecture of DNS, 4-5 ARPANET, 4 assigning roles to name servers, 24 Asynchronous Transfer Mode Address resource records, 347

ATMA resource records, 347 authentication (Active Directory), 194-196 AXFR (All Zone Transfer) counters, 283

B backups, 235-236 backward compatibility (Active Directory), 59 Berkeley Internet Name Domain. See BIND BIND (Berkeley Internet Name Domain), 5 Active Directory, 263 comparison of BIND and DNS file types, 247-248 configuration files, 246-247 history, 246 integration with DNS, 250-261 security, 249 versions, 246 zone transfers, 260-261 boot file errors, 314-315 BOOTP, 143-145 Bootstrap protocol, 143-145

C cache hints file, 50 caching, 51-52 caching-only servers, 29-30, 113

DHCP servers

canonical name (CNAME) resource records, 347 certificates, 60 CNAME (canonical name) resource records, 347 command-line utilities. See utilities configuring DHCP clients, 148-151 DHCP servers, 120-123, 133-143 DNS servers, 156 Active DirectoryIntegrated Server, 114-115 caching-only servers, 113 Configure DNS Server Wizard, 108-109 primary name servers, 112 root name servers, 110-111 secondary name servers, 112-113 standards, 270-271 verification, 272-277

Group Policy, 207-208 WINS servers, 231-237 conflicts, 219-220 counters adding, 279-281 All Zone Transfer (AXFR) counters, 283 creating, 282 deleting, 282 dynamic update counters, 284 Incremental Zone Transfer (IXFR) counters, 285 notification counters, 285

recursion counters, 285-286 secure dynamic update counters, 286 server memory counters, 284 TCP counters, 286 total counters, 286-287 UDP counters, 287 viewing, 282 WINS Lookup counters, 287-288 zone transfer counters, 288 customizing MMC, 154-155

D DARPA (Defense Advanced Research Projects Agency), 4 database load errors, 313 debugging, 288 DEC (Digital Equipment Corporation), 246 Defense Advanced Research Projects Agency (DARPA), 4 delegation records, 49-50 deleting counters, 282 deploying DHCP servers, 129-130 DHCP (Dynamic Host Configuration Protocol) benefits, 118 IP addresses, 118

reservation process, 118-119 standards, 267-269 DHCP clients configuring, 148-151 leases, 146-148 operating systems, 119-120 predefined options, 150-151 user class support, 125 vendor class support, 126 DHCP Manager, 120, 125-126 DHCP servers address pools, 120 Automatic Private IP Addressing (APIPA), 127-128 configuring, 120-123, 133-143 deployment, 129-130 DNS-DHCP integration, 264 dynamic updates, 145-146 exclusion ranges, 120, 135-136 installing, 130 integration with DNS, 124-125 IP addresses, 140-142 leases, 120, 146-148 monitoring, 120, 125-126 multicast address allocation, 127 new features, 123-125 options, 121-122, 138-142 pausing, 130 permissions, 128-129, 131-133

357

358

DHCP servers

reservations, 121 scope, 120-121, 133-138 starting, 130 stopping, 130 superscopes, 122-123, 142-143 troubleshooting, 319 unauthorized DHCP server detection, 127 user class support, 125 vendor class support, 126 Digital Equipment Corporation (DEC), 246 directives, 316 directory partitions, 224 DNS (Domain Name System) Active Directory, 78-80 architecture, 4-5 BIND, 5 comparison of BIND and DNS file types, 247-248 configuring Active DirectoryIntegrated Server, 114-115 caching-only servers, 113 Configure DNS Server Wizard, 108-109 primary name servers, 112 root name servers, 110-111 secondary name servers, 112-113 standards, 270-271 verification, 272-277

hierarchy, 5-13 identifying problems, 297

installation instructions, 105-109 planning, 88-105 verification, 115

integration with BIND, 250-261 with WINS, 238-242

legacy DNS, 78 logging, 288-290 monitoring performance, 277-283 name servers, 14-15 naming restrictions, 18-19 performance, 277-283 redundancy, 271 replication, 224-227 resolvers, 17 resource records, 16-17, 20 RFCs, 17 security DNS Client Security, 219-221 DNS Service Security, 214 DNS Zone and Record Security, 214-217 Dynamic DNS Security, 217-218 overview, 214

specifications, 17 standards, 266-267 troubleshooting, 294-297 upgrading, 251 uses, 4 verifying configuration, 297-305 WINS (Windows Internet Name Service), 80-84

zone files, 16 zones, 15-16 DNS (Domain Name System) servers integration with DNS, 124-125 interoperability, 263-264 non-RFC compliant BIND data, 263 DNS Caching Resolver, 307 DNS Console, 22 DNS domains, 12-13 DNS Notify, 54 DNS servers adding, 156 advanced options, 162-168 configuring, 156 forwarders, 161-162 hostnames, 157 interfaces, 160-161 IP addresses, 157-158 logging, 168-169 manual DNS updates, 171 memory counters, 284 modifying, 157-159 monitoring, 169-170 primary DNS domain name, 158 removing, 156, 159 resource records, 178-190 root hints, 167-168 security, 170 standard primary and secondary zones, 177-178 starting, 161 stopping, 161

Dynamic Host Configuration Protocol

zone properties, 171-177 zones, 159 dnscmd utility, 330-335 DNScmd.exe, 22 dnsstat utility, 330 domain controllers directory partitions, 224 locating, 297 name registration, 297 netlogon.dns file, 258-259 verifying DNS, 301-304 Domain Name System (DNS) Active Directory, 78-80 architecture, 4-5 BIND, 5 comparison of BIND and DNS file types, 247-248 configuration Active DirectoryIntegrated Server, 114-115 caching-only servers, 113 Configure DNS Server Wizard, 108-109 primary name servers, 112 root name servers, 110-111 secondary name servers, 112-113 standards, 270-271 verification, 272-277

hierarchy, 5-13 identifying problems, 297 installation instructions, 105-109 planning, 88-105 verification, 115

integration with BIND, 250-261 with WINS, 238-242

legacy DNS, 78 logging, 288-290 monitoring performance, 277-283 name servers, 14-15 naming restrictions, 18-19 performance, 277-283 redundancy, 271 replication, 224-227 resolvers, 17 resource records, 16-17, 20 RFCs, 17 security DNS Client Security, 219-221 DNS Service Security, 214 DNS Zone and Record Security, 214-217 Dynamic DNS Security, 217-218 overview, 214

specifications, 17 standards, 266-267 troubleshooting, 294-297 upgrading, 251 uses, 4 verifying configurations, 297-305 Windows Internet Name Service (WINS), 80-84 zone files, 16 zones, 15-16

Domain Name System (DNS) servers integration with DNS, 124-125 interoperability, 263-264 non-RFC compliant BIND data, 263 domain names primary DNS domain names, 158 registering, 89 troubleshooting, 317 domain namespace, 5, 7-8 domains Active Directory, 64 convergence, 105 costs, 101-102 DNS domains, 12-13 fully qualified domain names (FQDNs), 8-9 geographical domains, 10 hostnames, 13 legacy domains, 7 naming, 91-92 organizational domains, 9 reverse domain, 10 root domain, 6, 9 second-level domains, 11-12 subdomains, 7, 9, 71 top-level domains, 7, 9-10 zones, 15-16, 30 Dynamic Host Configuration Protocol (DHCP) benefits, 118 IP addresses, 118 reservation process, 118-119

359

360

dynamic update counters

dynamic update counters, 284 dynamic updates, 72-78, 217-218 DHCP servers, 145-146 troubleshooting, 305-307

E enterprise replication, 226-227 errors boot file errors, 314-315 database load errors, 313 Event Viewer, 295 file loading errors, 314 initialization errors, 309 Name not found errors, 298 NBSTAT errors, 309 Registry boot errors, 312-313 RPC initialization errors, 310 WINS errors, 309 Winsock/interface initialization errors, 310-312 Event Viewer, 295 events, 309

F fault tolerance, 130 file loading errors, 314 files cache hints file, 50 comparison of BIND and DNS file types, 247-248

netlogon.dns file, 258-259 root hints file, 50 zone files, 16 first-level domains. See top-level domains forests Active Directory, 63-64 integrating, 105 forward lookup zones, 274 forwarders, 27-28, 161-162 FQDNs (fully qualified domain names), 8-9 fully qualified domain names (FQDNs), 8-9

InterNIC, 18 IRTF (Internet Research Task Force), 18 ISOC (Internet Society), 18 Group Policy, 58, 204-214

H hierarchy of DNS, 5-13 HINFO resource records, 347-348 host information resource records, 347-348 hostnames, 13, 157 Hosts namespace, 7 hosts.txt file, 4

G general database load errors, 313 geographical domains, 10 Global Catalog, 58-59 glue records, 49-50 governing agencies IAB (Internet Architecture Board), 18 IANA (Internet Assigned Numbers Authority), 9, 18 ICANN (Internet Corporation for Assigned Names and Numbers), 10, 17 IESG (Internet Engineering Steering Group), 18 IETF (Internet Engineering Task Force), 18

I-J IAB (Internet Architecture Board), 18 IANA (Internet Assigned Numbers Authority), 9, 18 ICANN (Internet Corporation for Assigned Names and Numbers), 10, 17 identifying DNS problems, 297 IESG (Internet Engineering Steering Group), 18 IETF (Internet Engineering Task Force), 18 Incremental Zone Transfer (IXFR) counters, 285

mailbox resource records

informational events, 309 initialization errors, 309 installation Active Directory, 92-93, 107 DHCP servers, 130 DNS instructions, 105-109 planning, 88-105 verification, 115

Network Monitor, 319 WINS servers, 230-231 Integrated Services Digital Network (ISDN) resource records, 348 integrating forests, 105 interfaces (DNS servers), 160-161 Internet Architecture Board (IAB), 18 Internet Assigned Numbers Authority (IANA), 9, 18 Internet Corporation for Assigned Names and Numbers (ICANN), 10, 17 Internet DNS, 270 Internet Engineering Steering Group (IESG), 18 Internet Engineering Task Force (IETF), 18 Internet governing agencies IAB (Internet Architecture Board), 18 IANA (Internet Assigned Numbers Authority), 9, 18

ICANN (Internet Corporation for Assigned Names and Numbers), 10, 17 IESG (Internet Engineering Steering Group), 18 IETF (Internet Engineering Task Force), 18 InterNIC, 18 IRTF (Internet Research Task Force), 18 ISOC (Internet Society), 18 Internet Network Information Center (InterNIC), 18 Internet Research Task Force (IRTF), 18 Internet Society (ISOC), 18 Internet standards, 354 InterNIC, 18 interoperability, 61-65, 263-264 inverse queries, 49 IP addresses BOOTP, 143-145 DHCP, 118 DHCP servers, 140-142 DNS servers, 157-158 hosts.txt file, 4 ipconfig tool, 295-296 ipconfig utility, 324-325 IRTF (Internet Research Task Force), 18

ISDN resource records, 348 ISOC (Internet Society), 18 iterative queries, 47-49 IXFR (Incremental Zone Transfer) counters, 285

K-L Kerberos, 59, 194-196 legacy DNS, 78 legacy domains, 7 load balancing, 50-51 load errors, 313-314 locating domain controllers, 297 logging debug logging, 288 DNS servers, 168-169 overview, 288-290 trace logs, 282

M mail exchanger resource records, 349 mail group resource records, 348 mailbox mail list information resource records, 349 mailbox renamed resource records, 349 mailbox resource records, 348

361

362

managing

managing resource records, 178-184 secondary zones, 177-178 standard primary zones, 177-178 zone properties, 171-177 zone transfers, 230 MB resource records, 348 memory DNS requirements, 103 system memory counters, 284 MG resource records, 348 Microsoft standards for Windows 2000 DHCP, 267-269 standards for Windows 2000 DNS, 266-267 standards for WINS, 269-270 Microsoft Management Console (MMC), 57-58 adding, 154 customizing, 154-155 DNS servers adding, 156 advanced options, 162-168 configuring, 156 forwarders, 161-162 interfaces, 160-161 logging, 168-169 manual DNS updates, 171 modifying, 157-159 monitoring, 169-170 removing, 156 resource records, 178-190 security, 170

standard primary and secondary zones, 177-178 zone properties, 171-177

MINFO (mailbox mail list information) resource records, 349 MMC (Microsoft Management Console), 57-58 adding, 154 customizing, 154-155 DNS servers adding, 156 advanced options, 162-168 configuring, 156 forwarders, 161-162 interfaces, 160-161 logging, 168-169 manual DNS updates, 171 modifying, 157-159 monitoring, 169-170 removing, 156 resource records, 178-190 security, 170 standard primary and secondary zones, 177-178 zone properties, 171-177

modifying DNS servers, 157-159 resource records, 184 monitoring DHCP servers, 120, 125-126 DNS servers, 169-170, 277-283 MR resource records, 349 _msdcs suddomain, 71

multi-master replication (Active Directory), 59 MX resource records, 349

N name conflicts, 219-220 Name not found errors, 298 name resolution, 297 inverse queries, 49 iterative queries, 47-49 recursive queries, 47 name servers, 14-15 caching, 51-52 DNS Notify, 54 load balancing, 50-51 resource records, 35-44 roles assigning, 24 caching only, 29-30 forwarders, 27-28 master name server, 27 primary name server, 24-25 secondary name server, 25-27 slaves, 28-29

round robin, 50-51 zones, 30-34 names, registering, 297 namespaces Active Directory, 62-63 domain namespace, 5, 7-8 Hosts namespace, 7 NetBIOS namespace, 7 overlapping, 89-90 naming domains, 91-92

replication

naming restrictions, 18-19 naming standards, 44-46 NAT (Network Address Translation), 89-90 NBSTAT errors, 309 nbtstat utility, 335-337 NetBIOS namespace, 7 NetBIOS remote cache table, 336-337 NetDiag utility, 337-341 NetLogon A records, 71-72 SRV records, 68-70 netlogon.dns file, 258-259 netsh utility, 342-343 Network Address Translation (NAT), 89-90 Network Monitor, 319-321 Network Solutions, Inc., 89 New Delegation Wizard, 308 nodes, 12-13 North Rim, Inc., 99-100 notification counters, 285 notify lists, 176-177 nslookup tool, 301 nslookup utility, 326-328

O object-oriented security, 196-197 objects Active Directory security, 201-204 types, 202

Group Policy Objects (GPOs), 206-207, 211-214 organizational domains, 9 organizational unit, 64-65 OU, 64-65 overlapping namespaces, 89-90

P parameters, tuning, 291-292 parsing, 315-316 PathPing tool, 329 pausing DHCP servers, 130 Perfmon4.exe , 283 performance monitoring (DNS servers), 277-283 permissions, 128-129, 131-133, 199, 202-204 ping tool, 295-296 PKI (public key infrastructure), 60 placement of DNS servers, 103-104 planning DNS installation, 88-105 pointer (PTR) resource records, 350 policies, 58, 204-214 primary name servers, configuring, 112-113 PTR resource records, 275, 350 public key infrastructure (PKI), 60

Q-R queries inverse queries, 49 iterative queries, 47-49 recursive queries, 47, 303-304 verifying, 273-274 WINS, 81-83 record registration, 67-70 records delegation records, 49-50 glue records, 49-50 recovering WINS servers, 236-237 recursion counters, 285-286 recursive queries, 47, 303-304 redundancy, 271 registering domain names, 89 names, 297 records, 67-70 Registry boot errors, 312-313 removing DNS servers, 156, 159 replication Active Directory, 224-226 DNS replication, 224-227 enterprise replication, 226-227 topology, 228-229 WINS replication, 237 zone transfers, 224, 230 zones, 229

363

364

Requests for Comments

Requests for Comments (RFCs), 17 resolvers overview, 17 roles, 46-47 resolving name conflicts, 219-220 resource records A resource records, 37-38, 71-72, 346 AAAA resource records, 346 AFSDB resource records, 346 aging, 185-190 ATMA resource records, 347 CNAME resource records, 38-39, 347 experimental resource records, 41-43 fields, 35 HINFO resource records, 347-348 ISDN resource records, 348 mail exchange (MX) resource records, 39-40, 349 mail group resource records, 348 mailbox renamed resource records, 349 mailbox resource records, 348 managing, 178-184 MINFO (mailbox mail list information) resource records, 349

modifying, 184 name server (NS) resource records, 37 overview, 16-17, 35 pointer (PTR) resource records, 38, 275, 350 RP resource records, 350 RT resource records, 350 scavenging, 20, 185-190 service locator (SRV) resource records, 40-41, 66-70, 351 Start of Authority (SOA) resource records, 36-37 structure, 43-44 TKEY resource record, 78 troubleshooting, 318-319 TSIG resource records, 78 TXT resource records, 351 WINS resource records, 84, 242-244, 262 WINS-R resource records, 242-244, 262 WKS resource records, 351 X25 resource records, 352 responsible person resource records, 350 restoring WINS servers, 236-237 reverse domain, 10 reverse lookup zones, 178, 275 RFCs (Requests for Comments), 17 RFCs supporting Windows 2000 DNS server, 354 rights, 198-199

roles name servers assigning, 24 caching only, 29-30 forwarders, 27-28 master name server, 27 primary name server, 24-25 secondary name server, 25-27 slaves, 28-29

resolvers, 46-47 root domain, 6, 9 root hints, 167-168 root hints file, 50 root name servers configuring, 110-111 updating root hints, 111 round robin, 50-51 route through (RT) resource records, 350 RP resource records, 350 RPC initialization errors, 310 RT resource records, 350

S saving output from utilities, 344 scavenging resource records, 20, 185-190 WINS servers, 233-235 schemas (Active Directory), 62 searching Global Catalog, 58-59

servers

second-level domains, 11-12 secure dynamic update counters, 286 secure dynamic updates, 20 security Active Directory ACLs (Access Control Lists), 60, 197 authentication, 194-196 Kerberos, 59, 194-196 new features, 60-61 object security, 201-204 object-oriented security, 196-197 permissions, 199, 202-204 public key infrastructure (PKI), 60 rights, 198-199 security descriptors, 199-201 security identifier (SID), 198 security model, 194 x.509 certificates, 60

BIND, 249 DNS DNS Client Security, 219-221 DNS Service Security, 214 DNS Zone and Record Security, 214-217 Dynamic DNS Security, 217-218 overview, 214

DNS servers, 170 dynamic updates, 75-78

TSIG (transaction signatures), 249 zones, 176 security descriptors, 199-201 security identifier (SID), 198 server memory counters, 284 servers DHCP servers address pools, 120 Automatic Private IP Addressing (APIPA), 127-128 configuring, 120-123, 133-143 deployment, 129-130 DNS-DHCP integration, 264 dynamic updates, 145-146 exclusion ranges, 120, 135-136 installing, 130 integration with DNS, 124-125 IP addresses, 140-142 leases, 120, 146-148 monitoring, 120, 125-126 multicast address allocation, 127 new features, 123-125 options, 121-122, 138-142 pausing, 130 permissions, 128-129, 131-133 reservations, 121 scope, 120-121, 133-138

starting, 130 stopping, 130 superscopes, 122-123, 142-143 troubleshooting, 319 unauthorized DHCP server detection, 127 user class support, 125 vendor class support, 126

DNS servers adding, 156 advanced options, 162-168 configuring, 156 forwarders, 161-162 hostnames, 157 integration with DNS, 124-125 interfaces, 160-161 interoperability, 263-264 IP addresses, 157-158 logging, 168-169 manual DNS updates, 171 modifying, 157-159 monitoring, 169-170 non-RFC compliant BIND data, 263 primary DNS domain name, 158 removing, 156, 159 resource records, 178-190 root hints, 167-168 security, 170 standard primary and secondary zones, 177-178 starting, 161 stopping, 161 zone properties, 171-177 zones, 159

365

366

servers

name servers, 14-15 caching, 51-52 DNS Notify, 54 load balancing, 50-51 roles, 24-30 round robin, 50-51

WINS servers backups, 235-236 configuring, 231-237 installing, 230-231 recovering, 236-237 replication, 237 scavenging, 233-235

Service Locator (SRV) record, 66-70, 351 SID (security identifier), 198 slaves, 28-29 SLDs (second-level domains), 11-12 snap-in for Group Policy, 208-209 SRV (Service Locator) record, 66-70, 351 standards DHCP, 267-269 DNS, 266-267 Internet DNS, 270 Internet standards, 354 naming standards, 44-46 WINS, 269-270 starting DHCP servers, 130 DNS server, 161 stopping DHCP servers, 130 DNS server, 161 subdomains, 7, 9, 71

system counters. See counters System Monitor, 279-283

T tables BOOTP table, 144-145 NetBIOS remote cache table, 336-337 TCP counters, 286 text resource records, 351 time to live (TTL), 51 TKEY resource record, 78 TLDs (top-level domains), 7, 9-10 tools DNS console, 22 dnscmd, 330-335 DNScmd.exe , 22 dnsstat, 330 ipconfig, 295-296, 324-325 nbtstat, 335-337 NetDiag, 337-341 netsh, 342-343 Network Monitor, 319-321 nslookup, 301, 326-328 PathPing, 329 ping, 295-296 saving output, 344 WMI (Windows Management Instrumentation), 22 top-level domains, 7, 9-10 total counters, 286-287 trace logs, 282

transaction signatures, 249 trees (Active Directory), 63 troubleshooting Active Directory, 294-296 DHCP servers, 319 directives, 316 DNS, 294-297 domain names, 317 dynamic updates, 305-307 errors boot file errors, 314-315 database load errors, 313 file loading errors, 314 initialization errors, 309 NBSTAT errors, 309 Registry boot errors, 312-313 RPC initialization errors, 310 WINS errors, 309 Winsock/interface initialization errors, 310-312

events, 309 name resolution, 297 Network Monitor, 319-321 parsing problems, 315-316 process, 295-296 resource records, 318-319 tools. See tools, 344 zones, 307-308 TSIG (transaction signatures), 249 TSIG resource record, 78 TTL (time to live), 51

WMI

tuning advanced parameters, 291-292 parameters, 291-292 TXT resource records, 351

U UDP counters, 287 Unicode character support, 21 University of California at Berkeley, 246 Update Sequence Numbers (USNs), 228 updates, 171 upgrading DNS, 251 USNs (Update Sequence Numbers), 228 UTF-8 characters, 263 utilities dnscmd, 330-335 dnsstat, 330 ipconfig, 295-296, 324-325 nbtstat, 335-337 NetDiag, 337-341 netsh, 342-343 nslookup, 301, 326-328 PathPing, 329 Perfmon4.exe , 283 ping, 295-296 saving output, 344 System Monitor, 279-283

V verifying DNS configuration, 297-305 DNS installation, 115 forward lookup zones, 274 PTR resource records, 275 query responses, 273-274 reverse lookup zones, 275 server configuration, 272-273, 275-277 viewing counters, 282 Vixie Enterprises, 246 Vixie, Paul, 246

W WBEM (Web-Based Enterprise Management), 22 Web sites Internet Society, 18 Network Solutions, Inc., 89 Web-Based Enterprise Management (WBEM), 22 well-known service (WKS) resource records, 351 Windows 2000 DHCP, 267-269 Windows 2000 DNS new features, 19-21, 65-78 new tools, 21-22 standards, 266-267

Windows Internet Name Service. See WINS Windows Management Instrumentation (WMI), 22 WINS (Windows Internet Name Service), 80-84 errors, 309 integration with DNS, 238-239, 241-242 Lookup counters, 287-288 resource records, 242-244, 262 standards, 269-270 WINS servers backups, 235-236 configuring, 231-237 installing, 230-231 recovering , 236-237 replication, 237 scavenging, 233-235 WINS-R resource records, 242-244, 262 Winsock/interface initialization errors, 310-312 wizards Active Directory Installation Wizard, 107 Configure DNS Server Wizard, 108-109 New Delegation Wizard, 308 WKS resource records, 351 WMI (Windows Management Instrumentation), 22

367

368

x.509 certificates

X-Z x.509 certificates, 60 X25 resource records, 352 zone files, 16 zone transfer counters, 288 zone transfers, 52-54 AD and BIND, 260-261 incremental zone transfers, 230 managing, 230 replication, 224, 230 zones, 15-16 Active Directory integrated zones, 32-34 delegating, 216-217 delegation records, 49-50 domains, 30 forward lookup zones, 274 glue records, 49-50 information storage, 30-31 limits, 94 managing, 177-178 notify lists, 176-177 overview, 30 planning, 94 primary servers, 159 primary zones, 32 properties, 171-177 recommendations, 94 replication, 229 reverse lookup zones, 178, 275 secondary zones, 32, 177-178

security, 176 standard primary zones, 177-178 troubleshooting, 307-308

Microsoft Windows 2000 DNS: Implementation and Administration (White Book)

DNS on Windows 2000

DNS on Windows 2000

Служба DNS в Windows 2000

Microsoft Windows Vista Administration

Microsoft IIS 5 Administration (Sams White Book)

Inside Microsoft Windows 2000

Microsoft Windows 2000 Professional

Microsoft Windows 2000 Core Requirements, Exam 70-216: Microsoft Windows 2000 Network Infrastructure Administration

MCSE Training Kit, Microsoft Exchange 2000 Server : Microsoft Exchange 2000 Server Implementation and Administration

Microsoft Windows Server Administration Essentials

Mastering Microsoft Windows 7 Administration

Microsoft IIS 7 Implementation and Administration (Mastering)

Microsoft Windows Server 2008 Administration

Microsoft IIS 7 Implementation and Administration (Mastering)

Microsoft Windows Server 2008 Administration

Mastering Microsoft Windows 7 Administration

MCSE Training Kit Microsoft Windows 2000: Network Infrastructure Administration

Microsoft Windows 2000 Scripting Guide: Automating System Administration

Microsoft Windows 2000. Справочник администратора

Microsoft Windows 2000 Registry Handbook

DNS in Action: A detailed and practical guide to DNS implementation, configuration, and administration

Microsoft Windows Vista Management and Administration

DNS in Action: A Detailed And Practical Guide to DNS Implementation, Configuration, and Administration

Microsoft Active Directory Administration (Sams White Book Series)

Windows 2000 Server System Administration Handbook

Microsoft Windows Intune 2.0: Quickstart Administration

Windows 2000 Server System Administration Handbook

Microsoft Windows Intune 2.0: Quickstart Administration

Microsoft Windows 7 Administration Instant Reference

Concise Guide to Windows 2000 DNS (Concise Guide)

Microsoft Windows 2000 DNS: Implementation and Administration (White Book)

DNS on Windows 2000

DNS on Windows 2000

Служба DNS в Windows 2000

Microsoft Windows Vista Administration

Microsoft IIS 5 Administration (Sams White Book)

Inside Microsoft Windows 2000

Microsoft Windows 2000 Professional

Microsoft Windows 2000 Core Requirements, Exam 70-216: Microsoft Windows 2000 Network Infrastructure Administration

MCSE Training Kit, Microsoft Exchange 2000 Server : Microsoft Exchange 2000 Server Implementation and Administration

Microsoft Windows Server Administration Essentials

Mastering Microsoft Windows 7 Administration

Microsoft IIS 7 Implementation and Administration (Mastering)

Microsoft Windows Server 2008 Administration

Microsoft IIS 7 Implementation and Administration (Mastering)

Microsoft Windows Server 2008 Administration

Mastering Microsoft Windows 7 Administration

MCSE Training Kit Microsoft Windows 2000: Network Infrastructure Administration

Microsoft Windows 2000 Scripting Guide: Automating System Administration

Microsoft Windows 2000. Справочник администратора

Microsoft Windows 2000 Registry Handbook

DNS in Action: A detailed and practical guide to DNS implementation, configuration, and administration

Microsoft Windows Vista Management and Administration

DNS in Action: A Detailed And Practical Guide to DNS Implementation, Configuration, and Administration

Microsoft Active Directory Administration (Sams White Book Series)

Windows 2000 Server System Administration Handbook

Microsoft Windows Intune 2.0: Quickstart Administration

Windows 2000 Server System Administration Handbook

Microsoft Windows Intune 2.0: Quickstart Administration

Microsoft Windows 7 Administration Instant Reference

Concise Guide to Windows 2000 DNS (Concise Guide)

Recommend Documents