• 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

    Functional Description of DNS Query Handling

    It's important to have a fairly good idea of how DNS queries are handled before starting to architect your name resolution system (or change an existing system that is functioning properly). This topic contains step-by-step descriptions of DNS queries using several scenarios:

    • A query handled by an authoritative server

    • A query handled by a non-authoritative server

    • A reverse-lookup query

    Knowing how DNS queries are handled helps when designing a DNS system and when integrating Windows Server 2003 name services into an existing DNS infrastructure.

    Queries Handled by Authoritative Servers

    Assume, for example, that a user at a Windows Server 2003 computer in the company.com domain pings a server called srv1. Procedure 5.1 shows what happens from the point of view of DNS.

    Procedure 5.1 Functional Description of Query Handling by an Authoritative Name Server

    1. Tcpip.sys needs the IP address of srv1 so it can build an ICMP packet. To get this address, Tcpip.sys uses its internal DNS resolver. The remainder of this discussion refers to this resolver as if it were a separate service.

    2. The resolver fires off a query to its associated DNS server. The query contains the following:

      • The fully qualified DNS name of the target computerЧin this case, srv1.company.com.

      • The resource record type being requested. It's doing a simple host name lookup, so the query is for an A record.

      • The resource record class being requested. This is nearly always the IN, or Internet, class. Other classes are used only in very limited circumstances.

      DNS Packet Contents

      It can be instructive to view the contents of the DNS messages involved in a name query transaction. The Network Monitor service that comes with Windows Server 2003 is a great tool for capturing and examining packets going to and from the local network interface. Figure 5.4 shows a captured packet containing the response to a Host query (A record) from an authoritative DNS server. The following are the key items to examine:

      • UDP entry. Indicates that DNS query uses UDP port 53. This is the well-known port for DNS.

      • DNS flags. The server indicates that it is authoritative for the domain, it supports recursive queries, and there was no error in the response.

      • DNS question section. This contains a copy of the original DNS query asking for a host record for dc01.company.com.

      • DNS answer section. The response contains the A record information for dc01.company.com, including its IP address and the default TTL value from the SOA record.

      Figure 5.4. Captured packet showing DNS standard query response.

      graphics/05fig04.jpg

      If you have a DNS server inside a firewall and you need to send queries to a TLD root server or some other public name server, you must either enable UDP port 53 at the firewall or configure your DNS server to use Network Address Translation (NAT) or a proxy to access the Internet. Windows Server 2003 running DNS answers a DNS query on the same interface that receives the query, so enabling UDP port 53 is adequate to support DNS queries and their responses.

    3. When the DNS server receives the query, it parses the host name to find the DNS domain, company.com. In this instance, the DNS server is authoritative for the requested zone, so it does a zone lookup to find the requested resource record.

    4. When the DNS server finds the A record for srv1, it sends the entire contents of the record back to the client in the form of a DNS Query Response. If the A record does not contain a TTL value, the DNS server inserts the minimum TTL value from the SOA record for the zone. The default TTL is one hour, or 3,600 seconds.

      If the DNS server cannot find the requested record, it returns a Record Not Found response. An authoritative DNS server does not consult another DNS server when it cannot resolve a query within its zone of authority. When the resolver gets a Record Not Found response from an authoritative name server, it returns an error to the application without attempting further lookups.

    5. Now that the resolver has obtained the IP address, Tcpip.sys has some work to do. It uses the IP address from the A record to build an IP packet, then it uses Address Resolution Protocol (ARP) to find the MAC address associated with the IP address. Tcpip.sys then hands over the packet and the MAC address to the NDIS (Network Driver Interface Specification) driver, which works with the adapter driver to build a transmission frame that is sent to the target server.

    6. Tcpip.sys also hands the A record over to the DNS Resolver Cache service. The Resolver Cache holds onto the A record for the time period specified in the TTL.

    Queries Handled by Non-Authoritative Servers

    Consider the situation if the user, instead of trying to access a file on a server on the internal network, tries to access a file on an external network such as the Internet. For example, the user opens a browser and points it at www.roswellnm.org. (I was born in Roswell. My friends say that explains a lot about me.) In this trace, let's skip the OSI Layer 7 details and get right to the DNS query (see Procedure 5.2).

    Procedure 5.2 Functional Description of Query Handling by Non-Authoritative Name Server

    1. The DNS resolver sends off a recursive query to its DNS server asking for an A record for www.roswellnm.org. A recursive query tells the DNS server to do all the work in resolving the address.

    2. The local DNS server in the company.com DNS domain has no zone file for roswellnm.org. The recursive query tells the server to refer the request to another DNS server, but which one? This is where the root hints in the Cache.dns file come into play.

    3. After consulting the root hints file, the DNS server fires off an iterative query to a top-level domain (TLD) server saying, in effect, "Give me an A record for www.roswellnm.org or tell me the name of a server that can help me."

    4. In every likelihood, the TLD root server does not have an A record for www.roswellnm.org. However, the TLD server is authoritative for the domain .org. That means it has name server (NS) records pointing at servers that host the zone for .org.

    5. The root server consults its NS records and discovers several name servers for roswellnm.org. It returns the NS and A records for each of these name servers. Here's one example: dns1.interland.net at IP address 64.224.20.132.

      Trace Names

      If you're wondering where I got the specific names and addresses in this trace, skip ahead to the section in this chapter on Nslookup, "Examining Zones with Nslookup."

    6. The company.com DNS server now sends an iterative query to dns1.interland.net asking for an A record for www.roswellnm.org. The resolver at the client is still waiting patiently.

    7. The DNS service on dns1.interland.net is authoritative for roswellnm.org. It does a zone file lookup and finds an A record for www with the IP address 209.35.62.148.

    8. When the company.com DNS server receives the A record for www.roswellnm.org in answer to its query, it forwards the record to the client that originally sent the query. It also caches a copy in case another client sends a similar query. The aging time is determined by the TTL value in the A record.

    The key point to remember about the actions of the non-authoritative server is that the root hints file is used to find the name and IP address of a root server. Without root hints or a forwarder, the query would have failed.

    Reverse Lookup Queries

    A standard DNS zone is called a forward lookup zone because it searches by the name of the record until it either finds the entry or reaches the end of the zone. But what if a user knows the IP address of a host and wants the associated name? An example of this kind of reverse lookup occurs when you use ping with the Цa switch. This tells ping to display the host name along with the ICMP Echo Reply, like this:

    E:\>ping -a 10.1.1.254
    Pinging router.company.com [10.1.1.254] with 32 bytes of data:
    Reply from 10.1.1.254: bytes=32 time<10ms TTL=128
    

    This seems simple enough, but it turns out to be something of an exercise. DNS forward lookup zones are structured around host names, not IP addresses. Extracting a host name based on an IP address from a forward lookup zone would require an incredibly expensive scan that could encompass all the millions of zones scattered on DNS servers all over the planet.

    DNS avoids this impossible situation by creating a separate zone file based on IP addresses. This is called a reverse lookup zone. Figure 5.5 shows an example reverse lookup zone displayed in the Windows Server 2003 DNS console.

    Figure 5.5. DNS console showing a reverse lookup zone.

    graphics/05fig05.gif

    Structure of a Reverse Lookup Zone

    A reverse lookup zone is built using one record type, the PTR record. A PTR record contains the octets from the host ID in reverse order. The following listing contains examples of zone entries from a reverse lookup zone for the 10.1.0.0 network:

    ; Database file 1.10.in-addr.arpa.dns for 1.10.in-addr.arpa zone.
    ; Zone version:  8
    ;  Zone records
    1.1        PTR    dc01
    21.1       PTR    srv12
    254.1       PTR    router01
    

    Note that the network address 10.1.0.0 is reversed to make 1.10. If the network address were 222.100.93.0, the start of the zone file name would be 93.100.222.

    This reversal is necessary because the dotted-decimal notation used by IP addresses puts the most significant octet to the far left, whereas the referral mechanism used by DNS assumes that the most significant field is at the far right. Following the DNS referral method to its logical conclusion, if the inverted IP addresses form a contiguous tree, there would need to be 255 root domains with 255 separate primary name servers, one each for the 255 available addresses in the upper octet of the dotted-decimal IP address format.

    The top of this reverse lookup namespace needs a root, so the Advanced Research Project Administration (ARPA), which was in charge of the Internet at the time DNS was devised, created an artificial root with the name in-addr.arpa. With the in-addr.arpa root in place, a single TLD server can own the whole reverse lookup zone with 255 nodes at the second level, a paltry number compared to the kazillions of second-level domains in the .com namespace.

    What this means to you as a DNS administrator is that you must build a reverse lookup zone rooted at in-addr.arpa for every IP network in your organization. The name for each of these zones would start with the reverse of its network ID followed by the suffix in-addr.arpa. For example, the network ID 209.12.73.0 would have a reverse lookup zone of 73.12.209.in-addr.arpa. Typically, you would use the primary name server for the root domain of your organization as the primary server for the reverse lookup zones.

    Reverse Lookup Process

    Procedure 5.3 shows how DNS handles a reverse lookup request. Assume, for example, that a user in the company.com domain, address 10.1.0.0, uses ping Цa to find the host name for 209.12.73.4.

    Procedure 5.3 Functional Description of Reverse Lookup Query

    1. The resolver sends its DNS server a reverse lookup query, called a Domain Name Pointer request, for 4.73.12.209.in-addr.arpa.

    2. The DNS server is not authoritative for the 73.12.209.in-addr.arpa zone, so it refers the query to one of the TLD servers.

    3. The TLD server does not have a zone file for 73.12.209.in-addr.arpa, but it has an NS record for the name server that holds the zone for 209.in-addr.arpa. It returns a referral containing the NS and A records for that name server.

    4. The company.com DNS server now sends its PTR query to the name server in the referral. This server does not have a zone file for 73.12.209.in-addr.arpa either, but it returns the NS and A records for a name server holding the zone for 12.209.in-addr.arpa.

    5. The company.com DNS server now sends the PTR query to the name server in the referral. This server does hold the zone file for 73.12.209.in-addr.arpa. It returns the contents of the PTR record for 4 along with the associated A record, which contains the host name, www.newmexico.com.

    Many DNS administrators don't create reverse lookup zones on the theory that they aren't used often enough to make them worth the trouble. I recommend creating reverse lookup zones so you have all DNS tools at your disposal.

      Previous Section Next Section