• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Overview of DNS Domain Structure

    Before getting too far into DNS domains, let's deal with the ongoing confusion between Microsoft's use of the word domain and the way the term is used in DNS.

    Prior to introducing Active Directory, a Microsoft "domain" was completely different than a DNS domain. A DNS domain defines a namespace, such as Company.com. Resource records for hosts within this namespace are stored in a zone file, often simply called a zone. In classic Windows, a domain defines a security structure. Account records for users, groups, and computers within this security structure are stored in the SAM hive in the Registry.

    With the advent of Active Directory, the two territories described by the term domain became synonymous. The security structure defined by the account records in Active Directory conforms to a namespace defined by DNS.

    The namespace of a DNS domain describes a relationship between hosts. If a host named Srv1 is in the domain Company.com, its fully qualified domain name, or FQDN, would be srv1.company.com. Another host, Srv2, in the same domain would have an FQDN of srv2.company.com.

    Domains can be joined into a hierarchy based on a contiguous namespace. A DNS domain named branch.company.com would be a child of the domain company.com. Figure 5.1 shows an example DNS hierarchy with several child domains.

    Figure 5.1. Example DNS namespace.


    The top domain, or root, in a DNS hierarchy is identified by a trailing dot (.) at the end of the FQDN. This dot serves the same purpose as the leading slash in a file system path. It defines the top of the tree. A DNS resolver parses the FQDN starting at the leftmost element of the name and ending at the root next to the dot at the right side of the FQDN.

    The trailing dot at the end of a FQDN is not generally shown in DNS documentation, and Windows DNS tools add it automatically, so it's easy to forget it's there. When troubleshooting, though, it's a good idea to add the trailing dot just to be on the safe side.

    Public DNS Namespace

    The domain at the top of a DNS namespace is the root domain. For public DNS domains, the root domain is also called the top-level domain, or TLD.

    The organization responsible for registering names in the public Internet namespace is the Internet Corporation for Assigned Names and Numbers, or ICANN. Its web site is www.icann.org.

    ICANN has contracted with Network Solutions, doing business as Verisign Global Registry Services, to manage the name servers for the largest of the top-level domains: com, net, and org. The Verisign web site is www.verisign-grs.com.

    Table 5.1. New Top Level Domains and Their Sponsors

    TLD Name




    Societe Internationale de Telecommunications Aeronautiques SC (SITA)



    Neulevel, Inc.



    National Cooperative Business Association



    Afilias, LLC



    Museum Domain Management Assoc



    Global Name Registry



    RegistryPro, Ltd


    In early 2001, Verisign migrated the name servers for its three TLDs to 64-bit servers located at key nodes in the Internet, both in the continental U.S. and overseas. As of this writing, there are 12 Verisign TLD servers, named a.gtld-servers.net through m.gtld-servers.net.

    The remaining standard TLDsЧmil, gov, and eduЧare hosted on servers managed by Network Solutions but the zones are controlled by other ICANN designees. The TLD servers for these zones are a.root-servers.net through m.root-servers.net plus a few additional servers for the .mil namespace. The a.root-servers.net server gives referrals to the new Verisign TLD servers.

    ICANN has approved seven new TLDs to help differentiate the crowded com and org namespace. Table 5.1 lists the TLD names and the agencies or companies that sponsor them:

    ICANN is also responsible for country code TLDs, abbreviated ccTLDs. For example, a web site in Norway would have an FQDN ending in NO, such as www.sol.no. The two-letter country designations follow the ISO 3166 standards. For information about the registrar for a particular ccTLD, see www.iana.org/cctld/cctld-whois.htm.

    Private DNS Namespace

    You are not constrained to using a public TLD as a root domain in your private network. You can define your own root domain for internal use. For a while, a proposal circulated around the Internet to designate the .local designator as the reserved root domain for private DNS namespaces. This recommendation did not catch on.

    In general, you are free to use virtually any combination of letters for the root of your private namespace that have not already been taken by ICANN. Many organizations maintain a private DNS namespace with the same root domain name as their public namespace. This requires maintaining two DNS servers with different zones.

    Hosts File

    Before a client goes to the trouble to make a DNS query to resolve a host name into an IP address, it first consults a local file called Hosts. Here is an example Hosts file. The pound sign (#) denotes a comment:    dc01.company.com            #domain controller in Company    dc02.company.com            #another domain controller in Company   srv1.branch1.company.com     #general purpose server in branch office   web7.subsidiary.com            #web server in affiliate domain

    The host name specified by a TCP/IP application must exactly match the entry in the Hosts file to get a successful lookup. For example, using the preceding Hosts file, a ping to dc01 would not succeed, but a ping to dc01.company.com would succeed. If the name is not in the Hosts file, the client then uses DNS to resolve the name.

    Primary and Secondary Name Servers

    A conventional DNS server stores its resource records in a zone file. Windows-based DNS servers give zone files a .DNS extension. For example, the zone file for the company.com zone would be company.com.dns. The zone files are stored in the \Windows\System32\DNS folder. A zone can also be integrated into Active Directory, in which case the resource records are stored as objects in the AD database.

    Refer to Figure 5.2. In a standard DNS architecture, only one name server has a read/write copy of a zone file. That server is called the primary name server. All zone changes must be funneled to this server.

    Figure 5.2. Example DNS Server Architecture.


    For fault tolerance and performance, it is a good idea to install one or more secondary name servers. A secondary name server hosts a read-only copy of the zone file. The secondary servers pull copies of the zone from primary name servers or from other secondary servers.

    A name server that simply caches the results of queries so it can pass the information along to its clients is called a caching-only name server.

    This reliance on a single primary name server is a weakness of classic DNS. As we'll see, Active Directory Integrated zones overcome this weakness by making any domain controller running DNS a primary name server for its zones.

    Registry Tip: Hosts File Location

    The Hosts file is located in \Windows\System32\Drivers\Etc folder along with other TCP/IP-related files such as Lmhosts, Protocols, Networks, and Services. This directory is specified by the following Registry value:


    HKLM | SYSTEM | CurrentControlSet | Services | TCPIP | Parameters





    Resource Records

    A zone file contains a set of resource records. Each record contains specific information about a host or service in the DNS domain. RFC 1183, "New DNS RR Definitions," defines more than a dozen DNS record types. Only a few are used with any frequency.

    When a DNS client needs information from a name server, it queries for a resource record. For example, if a client needs the IP address corresponding to a server named srv1.company.com, it sends the DNS server a request for the A, or Host, record for that server. The DNS server responds by finding the A record in the zone and then copying the contents of the record into a DNS reply, which it sends back to the client.

    So, DNS is nothing more than an exchange of resource records between clients and servers. The trick to making your DNS structure work correctly is making sure that the clients can find the right DNS servers and the servers have the right information in their zone files.

    Authoritative Query Responses

    When a DNS server is presented with a query for a resource record, it responds differently depending on whether or not it hosts a copy of the zone containing that resource record.

    A DNS server that hosts a copy of a zone file is said to be authoritative for that zone. When tracing a DNS query, the buck always stops at an authoritative server for the zone specified in the query.

    When a query arrives for a resource record within a name server's zone of authority, the server performs an authoritative lookup. Here is how it handles that lookup:

    • If the server finds the requested record in its zone file, it responds with a copy of the record contents.

    • If the server has recently done a lookup on the same record, it responds with a cached copy of the record. This is much faster than doing a file lookup from disk.

    • If the server cannot find the requested record, it returns a Record Not Found response to the client.

    Non-Authoritative Query Responses

    If a DNS server does not have a copy of the zone file for a requested zone, it has three alternatives when handling the query:

    • Query other name servers until the record is found, then return a copy to the requestor.

    • Respond with a referral to a name server further up the tree that might have a copy of the record.

    • Respond with a cached copy of the record that was stored following a previous lookup.

    All three methods result in a non-authoritative reply. The choice of which method to use, #1 or #2, is based in large part on a search type flag included in the client query. The flag has two possible states:

    • Recursive. This tells the DNS server to respond with a copy of the requested resource record no matter what. If the server has to consult with other DNS servers to find the record, so be it. A recursive query is like a Spartan mother sending her son into battle saying, "Come back carrying your shield or lying on it."

    • Iterative. This request permits the DNS server to return a referral to another DNS server that is likely to have a copy of the record rather than chase down the referral itself. An iterative search puts the workload on the client to follow up on the referral.

    DNS clients typically set the recursive flag in their queries on the assumption that the DNS server has more capacity for handling the search. Recursive queries from thousands of clients can put a great deal of load on a DNS server, so it is not uncommon to find servers configured to reject recursive queries. For example, the Verisign TLD servers are configured to reject recursive queries. See "Configuring Advanced DNS Server Parameters" for the steps to disable recursive queries on a Windows Server 2003 running DNS.

    If your ISP maintains a name server that permits recursive queries, or you find an open name server at another ISP, it is good etiquette to get permission prior to sending recursive queries to the server.

    DNS servers typically use iterative queries when they search on behalf of their clients. The server has the resources to handle referrals, so it doesn't make sense to put unnecessary burden on upstream DNS servers. Windows Server 2003 running DNS will default to iterative queries. There are no adjustment parameters to change this default.

    Root Hints

    DNS servers within a contiguous namespace can use a simple referral mechanism to find entries in each other's zones. For example, a DNS server in branch.region.company.com that gets a request for an A record for srv1.company.com can go right to a name server at the root of the company.com namespace to begin its iterative search if it knows the identity of the name servers at the root domain. An administrator can include these names in the configuration for the name server.

    When a DNS server gets a query for a resource record for a server on the Internet, it needs a way to find the TLD servers that host the root of the public domains. The DNS server finds these TLD servers using a special file called root hints. Figure 5.3 shows the root hints stored on a Windows Server 2003 running DNS.

    Figure 5.3. Standard root hints for a Windows Server 2003 running DNS.


    Root hints are contained in a text file that lists the names and IP addresses of the name servers at the root of the DNS namespace. Windows DNS servers store their root hints in a file called Cache.dns located in \Windows\System32\DNS. This root hints file contains the older TLD servers, not the new Verisign TLD servers. For an interim period, the a.root-servers.net TLD server will give referrals to the new TLD servers.

    DNS Client Resolvers

    The client service responsible for querying DNS and handling the responses is called a resolver. In Windows, the DNS resolver is part of the main TCP/IP driver.

    When an application first specifies the name of a particular server, the resolver first looks in its Hosts file. If the resolver does not find an entry in the Hosts file, it then goes to DNS. Like a good Jeopardy contestant, the resolver always submits its DNS requests in the form of a question, a DNS Query.

    When the resolver gets a response to its query, it caches the results in memory to speed up subsequent queries for the same record. DNS servers that search out records on behalf of their clients also cache the results.

    A name cache can get very large if the entries are never removed. Also, an entry might change but the server would not find out because it only looks in its cache. To prevent these problems, a DNS resource record contains a Time-To-Live (TTL) setting that specifies how long to cache the entry.

    Negative Caching

    Starting with Windows 2000, Microsoft included support for RFC 2308, "Negative Caching of DNS Queries." This permits a client to cache negative responses along with the resource records it receives. The idea behind negative caching is to prevent sending repeated queries to a name server that has already admitted that it cannot find the record. If you're the parent of a two-year-old, you can understand the value of negative caching.

    Unfortunately, negative caching can interfere with troubleshooting. For instance, let's say you forgot to put a host record for a new server into DNS. You start getting calls that folks cannot find the new server. You realize your mistake and create the host record. The phone calls continue to come in from those who have already tried to contact the server because their DNS client cached the negative response.

    Root Server Selection

    Root hints include multiple servers, so the local DNS server must decide which one to use for root queries. It does this by trying each root server in turn during the normal course of handling queries.

    When the DNS server sends these queries, it measures the round-trip time (RTT) of the responses. After it has collected RTT data on all the root servers, it picks the one with the shortest RTT and uses it for subsequent queries. This is done on the assumption that the TLD server with the shortest RTT is closest to the DNS server.

    If the RTT for the selected server degrades, the DNS server polls again to reevaluate the RTTs and may select a new root server based on the result of the evaluation.

    You can clear these negative responses out of the local DNS cache using the IPCONFIG utility as follows:

    ipconfig /flushdns

    Unfortunately, this command must be issued at the client.

    Servers also cache query results, including negative responses. If you want to clear out the DNS cache of a server, use the DNSCMD utility with this syntax:

    dnscmd /clearcache

    When you clear the cache, the client or server must accumulate entries again. This may hurt performance for a short while.

    NetBIOS Resolution Versus DNS Resolution

    A modern Windows client (Windows Server 2003, XP, or Windows 2000) uses NetBIOS name resolution to support SMB-based network application such as LanMan Workstation and LanMan Server. (SMB stands for Server Message Block, the command language used in Windows networking.)

    For example, if you map a drive to a share point on a server, the flat server name in the UNC path is resolved to an IP address using NetBIOS name resolution. If the name contains a dot (.) or is longer than 16 characters, the client uses DNS name resolution. With the default h-node configuration, a modern Windows client uses the following sequence for NetBIOS name resolution:

    1. NetBIOS name cache

    2. WINS query

    3. Lmhosts file

    4. Broadcast

    5. Hosts file

    6. DNS

    For Windows Sockets-based applications, all Windows clients use DNS name resolution (Hosts then DNS) as the primary means of resolving names to IP addresses. A modern Windows client will initiate NetBIOS name resolution in parallel, so if there is a disparity between the flat name in WINS and the hierarchical name in DNS, you can end up with a tricky problem to troubleshoot.

    Flat names cannot be submitted to a DNS server. If you ping a flat host name, such as svr1, the DNS resolver takes the following action:

    • If the name does not have an embedded dot and is shorter than 16 characters (a flat name), the client appends the DNS suffix for the computer onto the name and sends it to DNS.

    • If the name has an embedded dot and does not have a trailing dot, the resolver appends a trailing dot and sends the result to DNS. If the query fails to return a host record, the resolver appends the entire domain suffix and tries again.

    • If the first DNS suffix fails to get a host record from DNS, the resolver appends any alternative DNS suffixes that have been configured for the interface.

    • If all secondary suffixes fail, the resolver gives up.

      Previous Section Next Section