• 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

    Active Directory Integration

    In addition to the two RFC-compliant zone transfer methods, Windows Server 2003 DNS zone can be integrated into Active Directory. This eliminates the need for conventional zone transfers because Active Directory is replicated using its own multiple-master replication scheme.

    Active Directory integration also makes it possible for any Windows Server 2003 or Windows 2000 domain controller that is running DNS to update the zone.

    The DNS service requires very little overhead, so you can easily deploy DNS on every domain controller. In terms of performance, bandwidth utilization, and manageability, integrating DNS into Active Directory is a win. There are a few caveats, however:

    • No ASCII zone files. Resource records are stored in Active Directory as objects. If you want a text file to use as a fallback, you can maintain at least one standard secondary name server. Windows Server 2003 and Windows 2000 DNS will provide zone updates to the secondary and the secondary can save these in a regular text file.

    • Relies on Active Directory availability. Clients need DNS to find domain controllers. Hosting DNS on the same server that hosts Active Directory means you have multiple failures if the server goes down or is otherwise unavailable. You can minimize this risk by including at least two DNS servers in the TCP/IP configuration for the clients. Also, remember that the domain controller is also a DNS client, so make sure it points at itself for DNS lookups.

    • A Windows DNS server must be the primary name server. This may cause discomfort for DNS administrators who currently run UNIX or NetWare DNS and are hesitant about cutting over to Windows.

    Using Forwarders

    When a DNS server gets a query for a record in another zone that it does not have in cache, it checks its root hints to find a root server and then uses iterative queries to "walk the tree" until it finds a name server that has the record. This process is detailed in the earlier section in this chapter, "Functional Description of DNS Query Handling."

    There is an alternative to doing all that grunt work, and that is to check with another server that might have already done the grunt work first. This is called forwarding. The server being referenced by your DNS server is called a forwarder. Figure 5.7 shows an example DNS configuration that incorporates forwarders.

    Figure 5.7. DNS configuration using standard forwarding and conditional forwarding.


    The primary name server in the figure is configured to use a forwarder in two situations:

    • When the server receives queries for hosts in the subsidiary.com zone, it forwards those queries to one or more name servers in the subsidiary.com DNS domain. This is called conditional forwarding and is a new feature in Windows Server 2003.

    • When the server receives queries for hosts outside its own zone and not in subsidiary.com, it forwards those queries to a name server maintained by an ISP.

    In the second case, if the primary name server also has a functional set of root hints for the Internet top-level domain servers, it waits a while and then sends a query to one of those servers as well. It's betting that the forwarder will come through with the requested record before it has to do an iterative walk through the Internet to find a name server for the requested domain.

    A server configured to use a forwarder exclusively for out-of-zone lookups is called a slave server. A slave server depends completely on its forwarder. If the forwarder cannot find the record, the slave sends a No Record response back to the client. A Windows Server 2003 or Windows 2000 DNS server can be made into a slave server by selecting the Do Not Use Recursion for This Domain option in the Forwarders configuration in the server properties window.

    Conditional Forwarding

    Windows Server 2003 introduces a new feature that simplifies integrating DNS with name servers in other domains. Rather than designating a single server to use as a forwarder, you can designate separate forwarders for individual domains. This is configured as part of the DNS server properties in the DNS console. Figure 5.8 shows the configuration.

    Figure 5.8. DNS server properties showing conditional forwarder configuration.


    Here's an example of how to use conditional forwarding. Let's say that you have an extranet connection to a vendor that is used for sharing database access and the occasional file transfer. The vendor's DNS domain name is vendor.com. The IP address of the vendor's DNS server is Your clients have access to this server for purposes of submitting DNS queries.

    Windows 2000 and Root Zones

    Windows 2000 caused a bit of grief for administrators trying to configure forwarders and root hints for their DNS servers. In Windows 2000, a newly installed DNS server was automatically configured with a root domain, indicated by a folder with a dot (.) at the top of the namespace. This root domain tells a DNS server that it sits at the top of the entire DNS namespace and whatever domains it hosts are top-level domains.

    This is absurd, of course. No private server can be a TLD server. At best, it can be the root server for its own domain. But as long as that root zone exists, a Windows server cannot be convinced it is anything other than the once and future king, wielder of the sacred sword, master of the Elvish rings, and so on. This means the server will not accept root hints and cannot be configured to use forwarders.

    This "feature" of Windows 2000 forced administrators to delete the root zone so that they could correctly configure their DNS infrastructure. In Windows Server 2003, the root zone is not installed by default.

    You can configure conditional forwarding at your DNS server so that all requests for resource records in the vendor.com domain are sent to Your DNS server sends an iterative request to the target DNS server and forwards the response back to the clients.

    Stub Zones

    Windows Server 2003 supports a special type of zone configuration called a stub zone. A stub zone is used in place of delegation records when configuring a parent DNS server to send referrals to delegated DNS servers in a child domain.

    A stub zone contains the SOA record and NS (Name Server) records for a child zone along with the A records (also called glue records) corresponding to the name servers in the child zone. The stub zone server periodically updates its copy of the resource records. This simplifies delegation management.

    Here's an example. Let's say you are the administrator of the company.com zone. You want to delegate the branch.company.com zone to another DNS server in your organization that is managed by another administrator.

    Ordinarily, you would accomplish this by creating delegation records in the company.com zone that point at the name servers in branch.company.com. If the administrator responsible for branch.company.com adds or removes a name server, you would need to add and remove delegation records in company.com.

    With stub zones, instead of creating delegation records, you create a stub zone on the company.com DNS server that points at branch.company.com. When you initially create the stub zone, it copies the SOA, NS, and glue records from the DNS server in branch.company.com.

    When the company.com DNS server gets requests for resource records in branch.company.com, it uses name servers in the target domain to resolve the requests recursively. This speeds up subsequent requests because the stub zone server builds up a cache of resource records from the target zone.

    If the administrator for branch.company.com adds or removes a name server, the stub zone on your DNS server picks up the changes automatically. This relieves you of the responsibility for manually updating your delegation records.

    Deploying Windows DNS into an Existing Infrastructure

    Many DNS administrators tend to be leery about trusting Windows DNS. If you currently use BIND or Lucent QIP or NetWare 5.x for your DNS services, you do not need to change to Windows Server 2003 simply to accommodate Active Directory. The non-Windows DNS server must support RFC 2052, "A DNS RR for Specifying the Location of Services (DNS SRV)." In addition, it should support RFC 2136, "Dynamic DNS."

    As we'll see when we get to Active Directory design, Windows Server 2003 depends on DNS to provide the structure for the new generation of Windows domains. You may find it difficult to combine the namespace you want for Active Directory with your existing DNS namespace. You may need to create a separate namespace for Active Directory that is hosted on Windows DNS servers rather than BIND servers. Figure 5.9 shows an example of how such a split namespace can be achieved.

    Figure 5.9. DNS configuration showing a split namespace for private and public zones with same name.


    The example contains the following configuration features:

    • The zone for the Active Directory domain is hosted on a Windows Server 2003 running DNS to take advantage of secure dynamic updates.

    • The main corporate zone is hosted on a BIND server, which has a stub to the Windows zone rather than delegation records. UNIX clients in the organization obtain resource records from the Active Directory domain via referrals through the stub zone.

    • The Windows Server 2003 running DNS uses the BIND server as a forwarder. This permits Windows clients to obtain resource records from the main corporate zone.

    • The BIND server forwards out-of-zone traffic to a DNS server at an ISP. This permits both UNIX and Windows clients to resolve Internet names.

    • The BIND server is configured as a slave to the ISP forwarder so that it does not use root hints to get records directly from the Internet TLDs. This minimizes traffic through the firewall.

    • The ISP name server hosts the primary zone for the public corporate domain. This permits Internet users to resolve addresses for servers in the corporate DMZ without giving access through the firewall to the internal DNS server.

    Most organizations use a hybrid of this basic configuration. For instance, an organization might want to maintain its own public DNS server in the DMZ. Or, the administrators might want the Windows DNS server to forward directly to the ISP name server and eliminate a potential single point of failure at the BIND server.

    Whatever configuration you choose, if you use Windows DNS servers, make sure that Windows clients (this includes member servers and domain controllers) point at Windows DNS servers. This ensures that they see the SRV records they need to support access to vital domain controller services such as LDAP and Kerberos.

    WINS Forwarding

    While we're on the subject of forwarding, let's take a look at a form of forwarder that has been around since NT4 DNS.

    Windows servers occupy a special place because they are both TCP/IP hosts with hierarchical host name and SMB-based servers with flat NetBIOS names. In the SMB world, the servers happily register their names and services with WINS with little or no administrative intervention. In the DNS world, someone must create records for the servers in the correct zone so non-Windows clients can find them.

    Rather than maintain two databases, NT4 introduced a couple of proprietary resource records, the WINS record and the WINS-R record. These records pointed a Windows DNS server at one or more WINS servers. This enabled the server to forward DNS requests for Windows servers to WINS.

    Dynamic Updates

    Properly configured secondary servers improve reliability and reduce WAN traffic—two of the major goals for your DNS design. Another goal is to reduce administrative work, and that's where dynamic updates come into play.

    Windows 2000 and Windows Server 2003 support dynamic zone updates as described in RFC 2136, "Dynamic Updates in the Domain Name System." This RFC defines a new opcode called DNS Update that can be used to add records to a zone automatically. A DNS Update message contains the type of record to add (for example, an A record for a host name or an SRV record for a domain controller service), the name of the zone where the record should be added, and any prerequisite records that must or must not be present. As a minimum, modern Windows clients register an A (host) record and a PTR (reverse lookup pointer) record with their DNS server.

    Dynamic DNS clients (Windows Server 2003, XP, and Windows 2000) register their A and PTR records at boot time then refresh them every 24 hours. These dynamic updates are performed by the DHCP Client service. Do not disable this service, even if you use static IP addressing on your servers. Domain controllers refresh their DNS records every hour. This is controlled by the Netlogon service.

    Non-RFC 2136 clients such as downlevel Windows clients can register their A and PTR records by proxy through Dynamic Host Configuration Protocol (DHCP). See "Configuring DHCP to Support DNS," near the end of this chapter for details.

    You can force dynamic registration at Windows Server 2003, XP, and Windows 2000 clients using IPCONFIG as follows:

    ipconfig /registerdns

    Certain stipulations apply when dynamically registering a resource record:

    • When a client attempts to register a record that does not already exist, the DNS server adds the new record updates to the zone.

    • If a record exists with a different name but the same IP address, the new record is added and the old record is left in place.

    • If a record exists with the same host name but different IP address, the original record is overwritten with the new address value.

    Although the primary DNS server has the only read/write copy of the zone file, the DNS client can be configured to point at any authoritative server for the zone. The secondary servers pass the DNS Update messages from the clients up to the primary master. The primary name server notifies its secondaries of the change, and the secondaries pull an incremental zone transfer.

    If the client is configured to point at a non-authoritative server such as a caching-only server, the dynamic updates are not passed on to the authoritative server and the client is not registered.

    Dynamic Updates and Domain Controllers

    An Active Directory domain controller (Windows Server 2003 or Windows 2000) automatically registers its A and PTR records along with its service locator (SRV) records via the Netlogon service. The records are refreshed each time the service starts (usually at boot time) and hourly thereafter.

    If you make a change to a domain controller and you want to update DNS immediately, stop and start the Netlogon service. The domain controller continues to perform Kerberos authentications with Netlogon turned off but downlevel clients (Windows 9x and NT) cannot authenticate.

    If a domain controller cannot find its DNS server or the DNS server does not accept dynamic updates, you will see errors in the Event log. These errors are common in a BIND Domain Name System (DNS) infrastructure where dynamic updates have been disabled at the name server.

    If you want to avoid Event log errors and a constant drone of invalid request traffic to your BIND servers, you can disable automatic SRV record renewal by making a Registry change:






    0x0 (REG.DWORD)

    You will also need to delete the Netlogon.dnb file from the C:\Windows\System32\Config folder. This file contains records for automatic updating.

    You can also control automatic DNS updates from clients and domain controllers using group policies. It is still necessary to delete the Netlogon.dnb file manually.

    Record Scavenging

    Dynamic registration carries the risk that your nice, clean DNS zone might start to look like something best described as an aftermath. To avoid this, use scavenging to clean out old and unused records.

    Scavenging is not enabled by default. It can be enabled for a particular zone or for every zone on a DNS server. Scavenging only applies to primary zones and Active Directory Integrated zones. Secondary zones are read-only. If you scavenge the master zone, the secondary zones get cleaned up during the zone transfers.

    Because scavenging works by including an aging value in the dynamically registered resource records, it changes the format of the zone file, making it incompatible with non-Windows name servers. Zone transfers are unaffected because the DNS service filters out the aging value, but you cannot take a copy of the .DNS file for the zone and load it onto an NT4 or BIND name server.

    Scavenging uses two intervals, the non-refresh interval and the refresh interval, to determine when a particular record should be removed from the zone file. Both intervals are set for seven days by default. Here is how they work.

    When a resource record is first dynamically created, DNS assigns an aging value based on the seven-day non-refresh interval. During this seven-day interval, DNS does not accept refreshes to the record. This prevents the system from being overwhelmed every morning with refreshes from thousands of machines as they are turned on.

    After the initial, seven-day non-refresh interval, the record is free to be refreshed. DNS clients refresh their records at boot time and every 24 hours, if they are left on. The refresh interval lasts for another seven days. At the end of the seven-day refresh interval, if the aging value has not been refreshed, the record will be removed during scavenging.

    Scavenging can be initiated manually from the PROPERTIES menu of the zone icon or by scheduling it to run periodically as part of the DNS server properties (see "Configuring Scavenging" later in this chapter).

    If a user goes on vacation for more than two weeks and leaves her machine off, the DNS registration for her A and PTR records will age out and periodic scavenging will remove them from the zone. This is not a catastrophe. The user does not lose any security privileges or functionality. When the user starts up the machine after coming back from vacation and logs on, the system will re-register with DNS and build a new resource record.

    DNS Security

    A primary goal of DNS design is security. DNS security has several facets:

    • Limit the number of administrators who can make changes to the zone.

    • Prevent exposing the contents of your zones to unauthorized individuals.

    • Avoid potential abuse of the dynamic record registration mechanism.

    Limit Administrative Access

    You can control the security settings for accessing a DNS server. By default, Domain Admins, Enterprise Admins, DNS Admins, and the Administrators groups have full control. You can remove some of these groups to limit access to just members of the DNS Admins group or you can create another group for this purpose.

    The DNS Admins group is created in Active Directory by default when you install DNS. The Administrator account is a member of the group. The group is given Full Control rights over any DNS server in the domain as well as Full Control rights over the DNS zone information in Active Directory for Active Directory Integrated zones.

    If you define a separate group for DNS administration, be sure that you don't put the group in an OU where someone with administrator privileges can change the group membership. This defeats the purpose of the security group. Also remove the DNS Admins group from the access control list, because anyone with administrator rights in Active Directory can control the membership of this group.

    When setting security configuration for a DNS server, be sure to leave the Authenticated Users group on the access control list with the special rights they are assigned by default. This permits DNS clients to read the contents of a DNS server.

    Prevent Unauthorized Zone Transfers

    DNS servers make particularly enticing targets for intruders. They hold the IP address of every host in your network, and that kind of information can be damaging in the wrong hands. For instructions on adding or removing a server from the list of authorized servers, see the upcoming section, "Enabling Zone Transfers and Update Notifications."

    One consequence of locking down zone transfers is that you cannot use tools like Nslookup to view the contents of the zone file. This is because these tools use the same zone file transfer opcodes that a secondary server uses. This is not true for the DNSCMD utility that is installed when you install DNS on a server. If you have administrative privileges for a DNS server, you can use DNSCMD to dump the contents of a zone file.

    Secure Dynamic Updates

    One of the most important security measures you can take regarding dynamic updates is to control the computers that are permitted to register resource records. Without adequate controls, someone could accidentally or maliciously poison your zone file with false or misleading records. Or, they could stage a denial of service attack by registering thousands and thousands of bogus resource records.

    The current Standards Track documents for controlling DNS Update security are RFC 2535, "Domain Name System Security Extensions," and RFC 2930, "Secret Key Establishment for DNS." These and other supporting RFCs combine to form the DNSSec documentation. Windows Server 2003 does not implement DNSSec transactions, but it does support the new resource record types involved in those transactions.

    Windows Server 2003 permits you to restrict dynamic DNS Updates so that only authenticated computers in a domain can update their DNS information. To get this security, you must integrate the zone into Active Directory. A default group, DNS Admins, has read/write access to these DNS objects. Figure 5.10 shows an example access control list.

    Figure 5.10. Access control list for Active Directory Integrated DNS zone showing DNS Admins group.


    For instructions on configuring a secure update zone, see the "Managing Dynamic DNS" section later in this chapter.

      Previous Section Next Section