Chapter 8, Using the Windows 2000 DNS Server

Chapter 8, Lesson 1

Installing and Configuring Windows 2000 DNS

1. Installing DNS

|1| A. You can install the Windows 2000 DNS Server service in any one of the following ways:

1. Select it during the Windows 2000 operating system installation.

2. Allow the Active Directory Installation Wizard to install it along with the Active Directory service.

3. Manually install it, using Add/Remove Programs in Control Panel.

B. Active Directory relies on the DNS name space in the same way that Windows versions prior to Windows 2000 rely on the Network Basic Input/Output System (NetBIOS) name space.

1. To use Active Directory on your network, you must have a DNS server that supports the SRV resource record.

C. You must configure the computer running the Windows 2000 DNS Server service with a static Internet Protocol (IP) address, not one assigned by a Dynamic Host Configuration Protocol (DHCP) server.

1. You should also configure the server’s Transmission Control Protocol/Internet Protocol (TCP/IP) properties so that the Preferred DNS Server setting points back to the server.

|2| D. To install the Windows 2000 DNS Server service:

1. On a computer running Windows 2000 Server, log on as Administrator.

2. Click Start, point to Settings, and then click Control Panel.

3. Double-click the Add/Remove Programs icon, and then click Add/Remove Windows Components to display the Windows Components page of the Windows Components Wizard.

4. In the Components list, select Networking Services.

|3| 5. Click Details to display the Networking Services dialog box.

6. In the Subcomponents Of Networking Services list, select the Domain Name System (DNS) check box.

7. Click OK, and then click Next.

a. If prompted, type the full path to the Windows 2000 distribution files, and then click Continue. Windows 2000 copies the required files to your hard disk.

8. Click Finish to close the Windows Components Wizard.

E. Installing the DNS Server service creates the systemroot\System32\Dns folder (C:\Winnt\System32\Dns, by default), which contains the DNS database files.

1. Traditionally, DNS servers store their data in text files on the local drive.

a. The Windows 2000 DNS Server service implementation does not have to do this, but it can use text files that are compatible with other DNS server implementations, particularly one of the earliest server programs, Berkeley Internet Name Domain (BIND).

b. BIND reads server configuration parameters from a text file called BOOT whenever the server starts.

c. The primary function of the BOOT file is to specify the names of the other text files containing DNS data.

d. Windows 2000 DNS does not require a BOOT file, but it can use one, which facilitates migration from BIND.

2. The only active text file created by the DNS server is the Cache.dns file, which contains the names and addresses of the root name servers used to resolve names not located in a local zone.

|4| 2. Implementing a Caching-Only Server

A. A caching-only server is a DNS name server that only performs queries, caches the answers, and returns the results.

1. A caching-only server is not the authority for any domain and does not contain any zone information.

2. A caching-only server contains only the name resolution information that it has cached while resolving queries.

B. The primary benefit of a caching-only server is that it provides a local name resolution service for DNS clients, even when not hosting a domain.

C. When you complete the DNS installation, the computer is ready to function as a caching-only server, as long as it has access to the Internet.

D. To view or modify the list of root servers:

1. Click Start, and from the Administrative Tools program group, open the DNS console.

2. In the scope pane, select the server icon, and then select Properties from the Action menu to open the Properties dialog box.

|5| 3. Select the Root Hints tab to display the dialog box shown on Slide 5.

a. Use the Add, Edit, and Remove buttons to add root name servers to the list as well as to modify or delete existing entries.

Chapter 8, Lesson 2

Working with Zones

1. Creating a Zone

A. When you install a DNS server for the purpose of servicing a domain, you must always create at least one zone.

1. You can create a single zone that contains the entire area of the DNS space for which you are the authority, or you can divide your domain by creating multiple subdomains and placing them in different zones.

|6| B. You might want to divide your domain into multiple zones for the following reasons:

1. Administrative delegation. When you create multiple zones, you can grant different people permission to manage them, thereby dividing the DNS administration chores.

2. Performance enhancement. Creating multiple zones and storing them on different DNS servers can divide the name resolution traffic burden among your servers or networks.

3. Fault tolerance. Dividing your domain into zones stored on different servers enables DNS to continue servicing clients, even when a server fails.

4. Name space expansion. Creating subdomains in different zones is an easy way to accommodate the opening of a new branch office or site.

C. To create a zone in the Windows 2000 DNS server, you use the DNS console (which is installed by default with the DNS Server service) to perform the following procedure:

|7| 1. Click Start, and from the Administrative Tools program group, open the DNS console.

2. Expand the DNS server icon.

3. Select the Forward Lookup Zone folder, and then select New Zone from the Action menu to start the New Zone Wizard.

4. Click Next to bypass the Welcome page and proceed to the Zone Type page.

5. Select the type of zone you want to create, and then click Next to proceed to the Zone Name page. The available zone types are as follows:

a. Active Directory–Integrated. The master copy of a new zone. The zone uses the Active Directory database to store and replicate the zone files.

b. Standard Primary. The master copy of a new zone with its information stored in a standard text file, just like BIND and many other DNS server implementations

c. Standard Secondary. A replica of an existing zone

(1) Secondary zones are read-only and are stored in standard text files.

(2) You must create a primary zone before you can create a secondary zone.

(3) When creating a secondary zone, you specify the DNS server that will transfer the primary zone information to the secondary zone server.

|8| 6. In the Name text box, type the name you want to assign to the zone, and then click Next. Proceed to step a, b, or c below, as applicable.

a. If you chose to create an Active Directory–integrated zone, clicking Next takes you to the Completing The New Zone Wizard page. Proceed to step 7.

b. If you chose to create a standard primary zone, clicking Next takes you to the Zone File page, where you must specify the name of the text file in which you want to store the zone database. Click Next and proceed to step 7.

c. If you chose to create a standard secondary zone, clicking Next takes you to the Master DNS Servers page.

(1) Type the IP address of the DNS server containing the master zone database file for the zone in the IP Address text box, or click Browse to select a server, and then click Add.

(2) You can repeat this process to add more DNS servers to the list.

(3) Click Next to continue.

7. In the Completing The New Zone Wizard page, click Finish to close the wizard and create the zone, which will use the parameters you provided.

D. When you create a reverse lookup zone, the procedure is largely the same.

1. The exception is the addition of a Reverse Lookup Zone page, where you specify the network identifier for the reverse lookup zone you want to create.

2. When you type the network identifier part of an IP address, the New Zone Wizard automatically reverses the order of the bytes and adds the in‑addr.arpa domain name.

2. Creating Active Directory–Integrated Zones

|9| A. For networks deploying DNS to support Active Directory, directory-integrated primary zones are strongly recommended and provide the following benefits:

1. Multiple-master update and enhanced security based on the capabilities of Active Directory

a. In a standard zone storage model, DNS updates are performed using the single-master update model, in which a single authoritative DNS server for a zone is designated as the primary source for the zone.

(1) This server maintains the master copy of the zone database in a local text file.

(2) With this model, the primary server for the zone represents a single fixed point of failure.

b. With directory-integrated storage, dynamic updates to DNS are performed based on a multiple-master update model, in which any authoritative DNS server (such as a domain controller running the DNS Server service) can function as the primary source for the zone.

c. With the multiple-master update model, any of the primary servers for the directory-integrated zone can process requests from DNS clients to update the zone as long as a domain controller is available on the network.

2. Zones are replicated and synchronized to new domain controllers automatically whenever a new zone is added to an Active Directory domain.

3. Simplified planning and administration for both DNS and Active Directory

a. When name spaces are stored and replicated separately, an additional level of administrative complexity is added to the planning and design process for your network.

b. Integrating DNS storage into Active Directory unifies storage and replication management for both DNS and Active Directory into a single administrative entity.

4. Directory replication is faster and more efficient than standard DNS replication.

3. Delegating Zones

A. A zone starts as the storage database for a single DNS domain name.

1. If you add subdomains below the domain you specified when you created the zone, these subdomains can either be part of the same zone or part of another zone.

2. When you add a subdomain, you can configure it to be managed and included as part of the original zone records or delegated away to another zone created to support the subdomain.

|10| a. Slide 10 shows the microsoft.com domain. When you create a zone for the microsoft.com domain on a single DNS server, that one zone contains the entire microsoft.com name space.

b. If you later expand the microsoft.com domain by adding subdomains, those subdomains must either be included in the microsoft.com zone or delegated away to another zone.

c. In the figure on Slide 10, the example subdomain was added to the microsoft.com domain, and a new example.microsoft.com zone was created to support the example.microsoft.com subdomain.

B. When you delegate zones within a domain’s name space, you must also create Name Server (NS) resource records to point to the authoritative DNS server for the new zone.

1. This is necessary both to transfer authority and to correctly refer other DNS servers and clients to the servers being made authoritative for the new zone.

C. Before you can delegate a zone, you must first create the new subdomains that will be in the new zone within the existing zone, using the following procedure:

1. Click Start, and from the Administrative Tools program group, open the DNS console.

2. Select an existing zone in the DNS console, and then select New Domain from the Action menu to open the New Domain dialog box.

3. In the Type The New Domain Name box, type the name you want to use for the subdomain, and then click OK.

a. The new subdomain appears in the console beneath the existing domain.

D. To create a zone delegation:

|11| 1. Click Start, and from the Administrative Tools program group, open the DNS console.

4. In the DNS console’s scope pane, select the parent domain for the subdomain you want to delegate, and then select New Delegation from the Action menu to start the New Delegation Wizard.

a. The New Delegation Wizard appears.

5. Click Next to bypass the Welcome page and display the Delegated Domain Name page.

6. Type the name of the subdomain you want to delegate.

a. The wizard automatically displays the fully qualified domain name (FQDN) for the name you specify.

5. Click Next to proceed to the Name Servers page.

6. Click Add to display the New Resource Record dialog box with a Name Server (NS) tab.

|12| 7. In the Server Name text box, type the name of the server to host the delegated zone, and then click Resolve to obtain the server’s IP address, or click Browse to select a server. Click OK to close the dialog box.

8. In the Name Servers page, click Next, and then click Finish.

a. The wizard creates the delegated zone in the DNS scope pane and populates it with an NS resource record identifying the name server that will be the authority for the new zone.

b. If you specified the name and address of the same server that hosts the original zone, you can proceed to create other resource records in the subdomain you added before the delegation.

c. If you specified the name and address of a different name server, you must create the zone on that server before you can create resource records in it.

4. Configuring Dynamic Updates

A. The Windows 2000 DNS Server service includes a dynamic update capability, as defined in Request for Comments (RFC) 2136, “Dynamic Updates in the Domain Name System (DNS UPDATE).”

|13| 1. Until dynamic updates were developed, name registration on DNS servers was strictly manual; an administrator had to manually update the zone database file on the primary name server by creating new resource records or modifying existing ones.

2. With dynamic updates, name servers and clients within a network can automatically update the zone database files.

B. Dynamic updates interact with the Windows 2000 DHCP Server service to maintain synchronized name–to–IP-address mappings for network hosts.

C. You can configure a list of authorized servers to initiate dynamic updates.

D. To configure a zone to use dynamic updates:

1. Click Start, and from the Administrative Tools program group, open the DHCP console.

2. Select the forward or reverse lookup zone that you want to configure, and then select Properties in the Action menu.

3. In the General tab, in the Allow Dynamic Updates list, choose one of the following options:

a. No. Prevents all dynamic updates for this zone from occurring

b. Yes. Permits all dynamic updates for this zone to occur

c. Only Secure Updates. Permits only the dynamic updates that use secure DNS to occur for this zone. This is the preferred option.

4. Click OK to close the Properties dialog box.

Chapter 8, Lesson 3

Working with Resource Records

1. Introduction

A. Resource records are entries in the zone database file that associate DNS names to related data for a given network resource, such as an IP address.

|14| 2. Understanding Resource Record Types

A. Start of Authority (SOA) resource record

1. Identifies which name server is the authoritative source of information for data within this domain

2. The first record in the zone database file must be an SOA resource record.

a. In the Windows 2000 DNS Server service, SOA resource records are created automatically with default values when you create a new zone.

3. Unlike most resource records, the RDATA field of the SOA resource record contains a variety of subfields, most of which are used for name server maintenance operations.

4. RDATA subfields

a. Serial number (SERIAL). Contains a version number for the original copy of the zone

b. Primary Server (MNAME). Contains the FQDN of the DNS name server that is the primary source of data for the zone

c. Responsible Person (RNAME). Contains the name of the mailbox belonging to the person responsible for the administration of the zone

d. Refresh Interval (REFRESH). Specifies the time interval (in seconds) at which secondary master name servers must verify the accuracy of their data

e. Retry Interval (RETRY). Specifies the time interval (in seconds) at which secondary master name servers retry their zone transfer operations after an initial transfer failure

f. Expires After (EXPIRE). Specifies the time interval after which a secondary master name server removes records from its zone database file when they are not successfully refreshed by a zone transfer

g. Minimum (default) TTL (MINIMUM). Specifies the lower end of the range of Time to Live (TTL) values supplied with every resource record furnished by the zone

B. Name Server (NS) resource record

1. Identifies the name server that is the authority for the particular zone or domain

2. The RDATA field for this resource record consists of a single DNSNAME subfield containing the name of a DNS name server.

3. The Windows 2000 DNS Server service creates an NS resource record by default in every new zone.

C. Host (A) resource record

1. The A (for Address) resource record is the fundamental data unit of DNS.

2. This resource record has a single ADDRESS subfield in the RDATA field, which contains the IP address associated with the system identified in the NAME field.

3. Host resource records provide the name–to–IP-address mappings that DNS name servers use to perform their primary function, which is name resolution.

D. Alias (CNAME) resource record

1. The CNAME (for Canonical Name) resource record specifies an alias, or alternative name, for the system specified in the NAME field.

2. The RDATA field contains a single CNAME subfield that holds another name, in the standard DNS naming format.

3. You create CNAME resource records so you can use more than one name to point to a single IP address.

E. Host Information (HINFO) resource record

1. Contains two subfields in the RDATA field, called CPU and OS, that contain values identifying the processor type and operating system used by the computer specified in the NAME field

2. You can use this record type as a low-cost resource-tracking tool.

F. Mail Exchanger (MX) resource record

1. A secondary, but crucial, function of DNS is that it directs e-mail messages to the appropriate mail server.

2. The RDATA field in this resource record contains two subfields, called PREFERENCE and EXCHANGE.

a. The PREFERENCE subfield contains an integer value that indicates the relative priority of this resource record as compared with others of the same type and class in the same domain.

(1) Lower values indicate higher priorities.

b. The EXCHANGE subfield contains the name of a computer that can act as an e-mail server for the domain specified in the NAME field.

G. Pointer (PTR) resource record

1. Provides an IP-address–to–name mapping for the system identified in the NAME field

a. The PTR resource record is the functional opposite of the A resource record.

2. The RDATA field consists of a single PTRDNAME subfield, containing the FQDN of the system identified by the IP address in the NAME field.

3. When you create the appropriate reverse lookup zone on your Windows 2000 DNS server, you can create PTR resource records automatically with your A resource records.

H. Service (SRV) resource record

1. The SRV resource record, which enables clients to locate servers that are providing a particular service, is a relatively new addition to the DNS defined in RFC 2052.

2. Windows 2000 Active Directory clients rely on the SRV resource record to locate the domain controllers they need to validate logon requests.

3. Viewing Resource Records

A. To view the information in a resource record:

1. Click Start, and from the Administrative Tools program group, open the DNS console.

2. In the DNS console’s scope pane, select the zone for which you want to view a resource record.

3. In the detail pane, select the record you want to view, and then select Properties from the Action menu to display the Properties dialog box.

4. When you have finished viewing the record, click OK.

4. Creating Resource Records

A. The process of creating a resource record varies, depending on the type of record you want to create.

1. Creating an A resource record is simply a matter of supplying a host name and an IP address, whereas other record types contain much more data.

|15| B. To create a new resource record:

1. In the DNS console, right-click the zone in which you want to locate the record and select the appropriate command from the pop-up menu.

a. The pop-up menu commands vary, depending on whether you have selected a forward lookup zone or a reverse lookup zone.

2. When you select Other New Records from the pop-up menu, the DNS console opens the Resource Record Type dialog box, which contains a list of all the resource records.

3. When you select a record type, you see the New Resource Record dialog box, which contains fields for the information carried by that type of record.

4. After supplying the requested information, click OK to create the record.

a. The record appears in the detail pane of the DNS console under the appropriate zone.

Chapter 8, Lesson 4

Configuring Zone Transfers

1. Zone Replication and Zone Transfers

A. Zone transfer is the process by which DNS servers interact to maintain and synchronize authoritative name data.

B. To host a zone, additional servers must have identical zone data.

1. DNS uses zone transfers to synchronize all the copies of the zone.

C. When structuring your zones, there are several good reasons to use additional DNS servers for zone replication.

1. Adding DNS servers provides zone redundancy, enabling DNS clients to resolve names in the zone even if the primary server for the zone stops responding.

2. Adding DNS servers can reduce DNS network traffic.

3. Adding secondary servers can reduce the processing load on the primary server for a zone.

D. Full zone transfers

1. When you add a new DNS server to the network and configure it as a new secondary master name server for an existing zone, the server performs a full zone transfer (AXFR) to obtain a full copy of all resource records for the zone.

|16| E. Incremental zone transfers

1. The Windows 2000 DNS Server service supports incremental zone transfer (IXFR), a revised DNS zone transfer process for intermediate changes.

2. In earlier DNS implementations, any request for an update of zone data required a full transfer of the entire zone database, using an AXFR query.

3. With incremental transfers, DNS servers use an IXFR query instead.

a. IFXR enables the secondary master name server to pull only those zone changes it needs to synchronize its copy of the zone with its source.

4. With IXFR zone transfers, the servers first determine the differences between the source and replicated versions of the zone.

a. If the zones are the same version—as indicated by the SERIAL field in the SOA resource record of each zone—no transfer occurs.

b. If the serial number for the zone at the primary master server is greater than the serial number at the requesting secondary master server, the primary master server transfers only those changes made for each incremental version of the zone.

c. For an IXFR query to succeed and a transfer to occur, the primary master name server for the zone must keep a history of incremental zone changes to use when answering these queries.

5. The incremental transfer process requires substantially less traffic on a network, and zone transfers are completed much faster.

F. In addition to a manual initiation, a zone transfer also occurs during any of the following scenarios:

1. When starting the DNS Server service on the secondary master name server for a zone

2. When the refresh interval time expires for the zone

3. When changes are made to a primary master name server that is configured with a notify list

|17| G. As shown in the figure on slide 17, zone transfers are always initiated by the secondary master server (the destination server) for a zone and sent to the DNS server configured as its master server (the source server).

2. Example of a Zone Transfer

|18| A. The following sequence illustrates the process for a zone transfer between a requesting secondary master name server for a zone—the destination server—and its master server, another DNS server that hosts the zone.

1. During its initial configuration, the destination server sends an initial (AXFR) transfer request for the zone to the DNS server configured as its source for the zone.

2. The source server responds and transfers the entire zone database to the destination server.

a. The zone is delivered to the destination server with its version established by use of the SERIAL field in the properties of the SOA resource record.

b. The SOA resource record also contains a refresh interval that indicates when the destination server should next request renewal of the zone with the source server.

|19| 3. When the refresh interval expires, the destination server requests renewal of the zone from the source server with a query for the source server’s SOA resource record.

4. The source server responds to the query for its SOA resource record.

a. This response contains the serial number for the zone in its current state at the source server.

5. The destination server checks the serial number of the SOA resource record in the response and determines how to renew the zone.

|20| a. If the value of the serial number in the SOA response is equal to its current local serial number, the destination server concludes that the zone is the same at both servers and a zone transfer is not needed.

b. The destination server then renews the zone by resetting its refresh interval based on the value of the field in the SOA response from its source server.

c. If the serial number in the SOA response is higher than the current local serial number, the destination server concludes that the zone has been updated and that a transfer is needed.

6. If the destination server concludes that the zone has changed, it sends an IXFR query to the source server containing its current local value for the serial number in the SOA resource record for the zone.

7. The source server responds with either an incremental or full transfer of the zone.

a. If the source server supports incremental transfer by maintaining a history of recent and incremental zone changes for modified resource records, it can answer with an incremental (IXFR) transfer of the zone.

b. If the source server does not support incremental transfer or does not have a history of zone changes, it can, alternatively, answer with a full (AXFR) transfer of the zone instead.

3. Zone Transfer Security

A. The DNS console enables you to specify the servers allowed to participate in zone transfers.

1. This can help prevent an unknown or unapproved DNS server from attempting to pull, or request, zone updates.

|21| B. To specify the servers allowed to participate in zone transfers:

1. Click Start, point to Programs, point to Administrative Tools, and then click DNS.

2. In the DNS console’s scope pane, select the zone for which you want to set up zone transfers, and then select Properties from the Action menu to open the Properties dialog box.

3. Select the Zone Transfers tab.

4. Specify the servers for which you want to allow zone transfers by clicking the appropriate option button.

a. If necessary, type the servers’ IP addresses in the IP Address box and click Add for each one.

5. Click OK to close the Properties dialog box.

4. DNS Notification

A. The DNS Server service supports DNS notification, which notifies a select set of secondary master name servers for a zone when that zone is updated.

1. The notified servers can then initiate the zone transfer process and pull changes from the notifying server to update the zone.

B. Use DNS notification only to notify DNS servers that are operating as secondary master servers for a zone.

C. The typical DNS notify process begins when the local zone on a DNS server acting as a source for the zone to other servers is updated.

1. When the zone is updated at the source, the SERIAL field value in the SOA resource record is also updated, indicating a new local version of the zone.

2. The source server then sends a notify message to the other servers specified in the Notify dialog box.

3. All secondary master servers that receive the notification message respond by initiating a zone transfer request back to the notifying server.

|22| D. To specify the servers to be notified:

1. Click Start, point to Programs, point to Administrative Tools, and then click DNS.

2. In the DNS console’s scope pane, select the zone for which you want to set up zone transfers, and then select Properties from the Action menu to open the Properties dialog box.

3. Select the Zone Transfers tab, and then click Notify.

4. In the Notify dialog box, click the appropriate option button to specify the secondary servers to be notified when the zone changes.

a. If necessary, type the servers’ IP addresses in the IP Address box and click Add for each one.

5. Click OK to close the Properties dialog box.

Chapter 8, Lesson 5

Monitoring and Troubleshooting DNS

1. Monitoring DNS Servers

|23| A. Windows 2000 Server includes four options for monitoring DNS server activities:

1. Submitting queries to the server

2. Default logging of DNS server event messages to the DNS server log

3. Performance counters

4. Optional debug options for trace logging to a text file on the DNS server

B. Querying the DNS server

1. The DNS console enables you to monitor the DNS Server service by performing both simple and recursive queries.

2. To query the DNS server:

|24| a. Click Start, point to Programs, point to Administrative Tools, and then click DNS.

b. In the DNS console’s scope pane, select the name server on which you want to perform the test, and then select Properties from the Action menu to open the Properties dialog box.

c. Select the Monitoring tab, and then select one of the following check boxes to specify the type of query you want to use:

(1) Simple Query. Select this type of query to perform a simple query test of the DNS server.

(2) Recursive Query. Select this type of query to perform a more complex, recursive query test of the name server.

d. Select Test Now to perform a test immediately.

(1) You can also select the Perform Automatic Testing At The Following Interval check box and specify a time interval to trigger regular tests.

e. Click OK to close the Properties dialog box.

C. DNS server event logging

1. For Windows 2000 Server, DNS server event messages are kept separate from events generated by other applications and services in the DNS Server log, which you can examine using the Event Viewer console.

D. Monitoring DNS server performance

1. Because DNS servers are of critical importance in most environments, monitoring their performance can provide a useful benchmark for evaluating DNS server performance.

2. Windows 2000 Server provides a set of DNS server performance counters that you can use with System Monitor to measure various aspects of server activity, including:

a. Overall DNS server performance statistics, such as the number of overall queries and responses processed by a DNS server

b. User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) counters, for measuring DNS queries and responses that are processed using either of these transport protocols, respectively

c. Dynamic update and secure dynamic update counters, for measuring registration and update activity generated by dynamic clients

d. Memory usage counters, for measuring system memory usage and memory allocation patterns created by operating the server computer as a Windows 2000 DNS server

e. Recursive lookup counters, for when the DNS Server service uses recursion to look up and fully resolve DNS names on behalf of requesting clients

f. Windows Internet Name Service (WINS) lookup counters, for measuring queries and responses made to WINS servers when using the WINS lookup integration features of the DNS Server service

g. Zone transfer counters, including specific counters for measuring all-zone transfer (AXFR), incremental zone transfer (IXFR), and DNS zone update notification activity

E. Debug options

1. The DNS console also enables you to set additional logging options to create a temporary trace log as a text-based file of DNS server activity for debugging purposes.

|25| 2. To configure the DNS debugging logging options:

a. Click Start, point to Programs, point to Administrative Tools, and then click DNS.

b. In the DNS console’s scope pane, select the name server on which you want to perform the test, and then select Properties from the Action menu to open the Properties dialog box.

c. Select the Logging tab.

d. Select the check boxes for the types of events you want to log.

e. Click OK to close the Properties dialog box.

(1) The information for the options you selected is stored in the Dns.log file in the systemroot\System32\Dns folder (C:\Winnt\System32\Dns, by default).

3. By default, all debug logging options are disabled.

a. 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.

b. Debug logging can be resource-intensive, affecting overall server performance and consuming disk space.

(1) You should use it only temporarily when you need more detailed information about server performance.

2. DNS Troubleshooting Scenarios

A. Symptom: A zone transfer fails to occur.

1. Possible cause: The DNS Server service is stopped or the zone is paused.

a. Solution: Verify that the master (source) and secondary master (destination) DNS servers involved in the zone transfer are both started and that the zone is not paused at either server.

2. Possible cause: The DNS servers used during a transfer do not have network connectivity with each other.

a. Solution: Eliminate the possibility of a basic network connectivity problem between the two servers.

(1) Use the Ping command to ping each DNS server by its IP address from its remote counterpart. Both ping tests should succeed.

(2) If the ping tests fail, investigate and resolve intermediate network connectivity issues.

3. Possible cause: The SOA serial number is the same at both the source and destination servers. Because the value is the same at both servers, no zone transfer occurs between the servers.

a. Solution: Using the DNS console, perform the following tasks:

(1) In the Start Of Authority (SOA) tab, increase the value of the serial number for the zone at the master server (source) to a number greater than the value at the applicable secondary server (destination).

(2) Initiate zone transfer at the secondary server.

4. Possible cause: The master server (source) and its targeted secondary server (destination) are having interoperability-related problems.

a. Solution: Investigate possible causes for any problems related to interoperability between Windows 2000 DNS servers and other DNS servers running different implementations, such as an earlier version of the BIND distribution.

5. Possible cause: The zone has resource records or other data that the DNS server cannot interpret.

a. Solution: Perform the following tasks:

(1) Verify that the zone does not contain incompatible data, such as unsupported resource record types or data errors.

(2) Verify that the server has not been configured in advance to prevent loading a zone when bad data is found, and investigate its method for checking names. You can configure the zone loading behavior using the DNS console.

6. Possible cause: Authoritative zone data is incorrect.

a. Solution: If a zone transfer continues to fail, ensure that the zone does not contain nonstandard data.

(1) To determine if erroneous zone data is a likely source for a failed zone transfer, look in the DNS event log for messages.

B. Symptom: Zone delegation does not function properly.

1. Possible cause: Zone delegations are not configured correctly.

a. Solution: Review how to use zone delegations and revise your zone configurations as needed.

C. Symptom: The client is not performing dynamic updates.

1. Possible cause: The client (or its DHCP server) does not support the use of dynamic updates.

a. Solution: Verify that your clients or servers support dynamic updates using the options for dynamic update support provided in Windows 2000.

(1) To register and update client computers dynamically with a DNS server, either install or upgrade client computers to Windows 2000 or install and use a Windows 2000 DHCP server on your network to lease addresses to client computers.

2. Possible cause: The client was not able to register and update with the DNS server because of missing or incomplete DNS configuration.

a. Solution: Verify that the client is fully and correctly configured for DNS, and update its configuration as needed.

(1) To update the DNS configuration for a client, either configure a primary DNS suffix at the client computer for static TCP/IP clients or configure a connection-specific DNS suffix for use at one of the installed network connections at the client computer.

3. Possible cause: The DNS client attempted to update its information with the DNS server but failed because of a problem related to the server.

a. Solution: If a client can reach its preferred and alternate DNS servers as configured, it is likely that the cause of its failed updates can be found elsewhere.

(1) At Windows 2000 client computers, use Event Viewer to check the System log for any event messages that explain why attempts by the client to dynamically update its host (A) or pointer (PTR) resource records failed.

4. Possible cause: The DNS server does not support dynamic updates.

a. Solution: Verify that the DNS server used by the client can support the dynamic update standard.

(1) For Windows servers, only the version of DNS included with Windows 2000 supports dynamic updates; earlier versions, such as the one provided with Microsoft Windows NT 4.0 Server, do not.

5. Possible cause: The DNS server supports dynamic updates but is not configured to accept them.

a. Solution: Perform the following tasks:

(1) Verify that the primary zone where clients require updates is configured to allow dynamic updates. For Windows 2000 DNS servers, the default for a new primary zone is to not accept dynamic updates.

(2) At the DNS server that loads the applicable primary zone, modify zone properties to allow updates.

6. Possible cause: The zone database is not available.

a. Solution: Perform the following tasks:

(4) Verify that the zone exists.

(5) Verify that the zone is available for update.

(a) For a standard primary zone, verify that the zone file exists at the server and that the zone is not paused.

(b) Secondary zones do not support dynamic updates.

(1) For Active Directory–integrated zones, verify that the DNS server is running as a domain controller and has access to the Active Directory database where zone data is stored.