Managing DNS in a Small Domain
Now that the basics are covered, we are ready to configure a set of DNS servers. Figure 3.9 shows a simple network with two name servers, a mail server, and a Web server. The network connects to the Internet through a router. Until we discuss Active Directory-integrated DNS zones, Active Directory is not enabled in the examples being displayed, so no Service Location (SRV) resource records will appear in the screen shots.
){kind=link}
Figure 3.9 This simple network illustrates most basic DNS configuration tasks.
The network calls for the following resource records:
Name Server (NS) RRs for DC1 and DC2, indicating that these hosts are authoritative for the domain
Host Address (A) RRs for DC1, DC2, mail1, www, ftp, and router
A Mail Exchanger (MX) RRs for mail1
We are assigning DNS names only to devices that provide services. Because no user's PCs will be configured as servers, it is not mandatory to provide them with DNS names. In any case, the procedure for naming a user's computer is the same as that for naming a server, so you can easily extend the examples to cover non-servers should you desire to do so.
At first, we will configure DNS with standard primary zones on DC1 and standard secondary zones on DC2. We'll see how to configure Active Directory-integrated zones later in the chapter.
Installing the DNS Server Service
Like most Windows 2000 components, the DNS service is installed using the Add/Remove Programs applet in the Control Panel. The procedure is as follows:
Open the Add/Remove Programs applet.
Click Add/Remove Windows Components.
Select Networking Services in the Components list and click the Details button.
Check the checkbox for Domain Name System (DNS).
Click OK.
Click Next. The DNS service components will be installed and configured.
Click Finish.
Note
Windows 2000 DNS servers must be configured with static IP addresses. If you are installing the DNS service on a computer that is dynamically configured through DHCP, you will be prompted to specify a static IP address.
In addition to the DNS service, this procedure adds a DNS snap-in for the MMC. A DNS icon is added to the Start —> Program —> Administrative Tools menu. Figure 3.10 shows the DNS snap-in as it appears after creation of the zones and resource records necessary for the network in Figure 3.9.
){kind=link}
Figure 3.10 The DNS management console.
Managing Remote DNS Servers
As Figure 3.10 illustrates, you can manage DNS services on other Windows 2000 Servers by adding the DNS servers to the Microsoft Management Console object tree. To add a server to the object tree:
Right-click DNS at the top of the object tree.
Select Connect to Computer from the context menu to open the Select Target Computer dialog box, shown in Figure 3.11.
Click This computer to add the local computer to the object tree
or
Click The following computer and enter the FQDN of another server that is running the Windows 2000 DNS service.
Check Connect to the specified computer now to activate the connection immediately.
Click OK.
){kind=link}
Figure 3.11 Adding a DNS server to the MMC object tree.
Configuring the DNS Server
When the DNS service is installed, the server hosting the DNS server is automatically added to the object tree in the DNS console. Several properties of the DNS server can be configured. To open the server property pages, do the following:
Locate the server in the object tree of the DNS console.
Right-click the server name in the object tree.
Select Properties from the context menu to open the DNS Server Properties dialog box.
Select the desired property page.
After making desired changes, click OK to close the dialog box.
The next few sections examine the zone property pages.
Interfaces Properties
By default, the DNS server accepts queries on any of the interfaces installed in the server. You can, if desired, configure the server to accept queries from specific interfaces by selecting Only the following IP addresses on the Interfaces properties page, shown in Figure 3.12. The list will contain the IP addresses of all the interfaces that were active on the computer when the DNS service was installed. Use the Add and Remove buttons to change the IP addresses that appear in the list.
){kind=link}
Figure 3.12 Interfaces properties determine which interfaces on the DNS server will accept DNS queries.
Forwarders Properties
The DNS server can be configured to forward queries to designated forwarders. This technique is used to enable cache-only servers. As discussed previously, forwarding DNS servers function as focal points for name resolution requests outside an enterprise, resolving all outside queries so that they retain all query results in their cache.
Use of forwarders is enabled on the Forwarders properties page, shown in Figure 3.13. If Enable forwarders is checked, the server attempts to resolve the query, using the following steps:
){kind=link}
First, the server attempts to resolve the query using its local cache or data in zones that it is hosting.
If the server cannot resolve the request from cache or zone records, it sends the query to the DNS servers that appear in its list of forwarders. After querying a forwarder, the server waits for a timeout interval before trying to resolve the query using the next forwarder in its list.
If none of the forwarders responds with a query resolution, the server attempts to resolve the query itself.
Figure 3.13 Configuring forwarders for a zone.
By default, when the forwarders fail, the server will fall back on its normal mode of operation and initiate recursive queries for any queries not answered by the forwarders. In rare instances, you might want to prevent certain name servers from attempting to resolve queries by checking Do not use recursion.
Advanced Properties
Figure 3.14 shows the Advanced properties tab. You might never need to modify anything on this page and should be aware that most of the settings significantly alter the functionality of the DNS service.
){kind=link}
Figure 3.14 Configuring advanced properties for a zone.
Six check boxes appear under the heading Server Options:
Disable recursion. If you check this option, the server will no longer conduct recursive searches on behalf of DNS clients. If the DNS server cannot resolve a query from its local cache or zones, it can provide a referral to another name server that might be able to resolve the client's query. Typically, recursion is disabled on private networks wherein all DNS RRs exist as internal resources. Recursion is also disabled when a particular DNS server cannot conduct a recursive query. Because DNS clients seldom have the capability to conduct a recursive DNS query on their own, inappropriately disabling recursion can render clients incapable of resolving DNS queries.
BIND secondaries. Determines whether to use a fast transfer format when performing zone transfers to BIND servers. Fast transfer format uses compression and can include multiple RRs per message. Fast transfer format is used on all Windows DNS servers and is available on BIND versions 4.9.4 and later.
Fail on load if bad zone data. If checked, the DNS service requires strict adherence to file format conventions when loading a zone database file. Any errors will prevent the zone from loading. Normally, the Windows DNS service rejects records containing errors and logs the error, but continues to load the database.
Enable round robin. Round robin addressing is enabled by default. See the section "Supporting Round Robin Addressing" for an explanation of how the feature works.
Enable netmask ordering. If a name resolves to more than one IP address, the DNS service can use subnet mask information to prioritize the options. See the Windows 2000 Help for a more thorough explanation.
Secure cache against pollution. When enabled, this option prevents the DNS service from caching responses to queries that are unrelated to the original query. This is usually desirable behavior, and the option is enabled by default.
The value of the Name checking field determines the rules restricting the characters that can appear in DNS names. Three options are available:
Multibyte (UTF8). Permits 8-bit ASCII characters and Unicode. Multibyte characters are transformed using the Unicode Transformation Format (UTF-8) support of Windows 2000 Server. This is the default value.
Non RFC (ANSI). Permits names that do not strictly conform to RFC 1123. Permits most displayable ASCII characters.
Strict RFC (ANSI). Permits only names that strictly conform to RFC 1123. Permits ASCII characters a–z, 0–9, and - (hyphen) only. This setting ensures compatibility with all DNS servers and clients and should be selected if names will be resolved through the Internet DNS namespace.
By default, the Windows 2000 DNS server stores zone data in Active Directory (if Active Directory is enabled) and in the Registry. Particularly when importing data from other name servers, you might want to configure the DNS service so that the zone is initialized from another source. Three options are available:
From Active Directory and registry. Standard domains will be loaded from the Registry. Active Directory-integrated zones are loaded from Active Directory.
From registry. Zone data are stored in and loaded from the Registry.
From file. Zone data are loaded from a text database file. See the section "Importing and Exporting BIND Databases" for more about this option.
Automatic scavenging enables the DNS service to discard stale zone records. If you check Enable automatic scavenging of stale records, you can specify an interval at which scavenging will take place.
Note
You can initiate scavenging manually by right-clicking a DNS server in the DNS Management Console and selecting Scavenge stale resource records in the context menu.
Root Hints Properties
As we discussed earlier, when a name server cannot resolve a DNS query using information in its cache or local zone files, it will usually start searching the DNS namespace starting with the root domain. To do this, the server must know the identity of at least one of the servers that is authoritative for the root domain. That information takes the form of root hints, which are defined on the Root Hints properties tab, shown in Figure 3.15.
){kind=link}
The root hints are initialized with hints for the Internet root domain servers when the DNS service is installed. The identities of these servers seldom change, and it is unlikely that you will need to modify any of the default entries.
If you are running a private DNS namespace, however, you will need to remove records pertaining to the Internet root name servers. You'll insert hints that identify the servers which are authoritative for your private root domain. Use the Add and Remove buttons to modify the hints, as required for your network.
Figure 3.15 By default, the root hints identify the Internet root domain servers.
Note
Private networks often do not require root name servers because the DNS servers are typically aware of all the DNS domains used in the organization. When all queries are made to known domains, there is no need to send a query to the root domain. If it were not connected to the Internet, the sample network would not require a root domain because all queries are made in the pseudo-corp.com domain, and every name server has a copy of the zone containing that domain.
Chapter 4 describes the procedures required to configure private root name servers.
Note
On most DNS servers, RRs pertaining to root name servers are stored in a zone named CACHE. We will discuss the manner in which BIND handles root name servers later in the chapter.
Logging Properties
Figure 3.16 shows the Logging properties tab for the DNS server. You can configure the service to maintain logs about the following events:
){kind=link}
Query. Queries received from clients
Notify. Notifications received from other servers
Update. Dynamic updates received from other computers
Questions. The contents of the question sections of DNS queries received
Answers. The contents of the answer section of each response the server generates
Send. The number of queries sent by the DNS service to other DNS servers
Receive. The number of queries received
UDP. The number of DNS requests received over a UDP port
TCP. The number of DNS requests received over a TCP port
Full packets. The number of full packets written and sent by the service
Write through. The number of packets written through by the service and back to the zone
Figure 3.16 DNS server logging options are configured on the Logging properties page.
Logging is a resource-intensive process that should ordinarily be carried out only when testing and debugging operation of the DNS service. If logging is activated on a live server, performance can suffer, and log files might grow to consume significant amounts of disk space. Unlike with Windows 2000's own log files, there is no provision for configuring DNS logging to discard old records or set a maximum size on log files.
Monitoring Properties
The Monitoring properties tab, shown in Figure 3.17, is actually an interface to some tools used to test the DNS service. You can configure two types of tests:
){kind=link}
A simple query against this DNS server. This test determines whether the server can resolve queries to local zone databases.
A recursive query to other DNS servers. The DNS server will attempt to query other name servers using a recursive search.
The results of tests are reported in the Test results list box.
Figure 3.17 Tests on the Monitoring tab can be used to report proper operation of the DNS server.
You might want to schedule these tests so that they are performed automatically at specified intervals. If you check Perform automatic testing at the following interval, you can specify an interval in seconds, minutes, or hours.
If the most recent tests failed, an Information icon (a yellow warning triangle with an exclamation mark) appears beside the server's name in the DNS console.
Note
At the time I am writing this, I have been unable to get these tests to succeed with servers that are not integrated into Active Directory. However, servers that are hosting only standard zones and that are not configured as Active Directory domain controllers do resolve actual queries properly. So, don't panic if you run the tests, and they fail. You can also use the NSLOOKUP utility to test the servers. NSLOOKUP is covered near the end of this chapter.
Creating the Primary Forward Lookup Zone
The first step in configuring the server is to create the forward lookup zone. The following procedure must be performed on the computer that will host the primary zone database:
In the DNS console, expand the object tree to locate the DNS server that will host the new zone. Right-click the server name.
Note
You can also start creation of a forward lookup zone by right-clicking on the Forward Lookup Zones object. The Forward or Reverse Lookup Zone dialog box is omitted when you start the wizard in this manner.
Choose New Zone in the context menu to open the New Zone Wizard.
Click Next to open the Zone Type dialog box, shown in Figure 3.18. Because Active Directory is not installed on this server, the Active Directory-integrated option would not be active. The option is activated in the figure for clarity.
){kind=link}
Figure 3.18 Specifying the type of zone to be created.
Select Standard Primary.
Click Next to open the Forward or Reverse Lookup Zone dialog box, shown in Figure 3.19.
){kind=link}
Figure 3.19 Specifying whether a forward or reverse lookup zone will be created.
Select Forward lookup zone.
Click Next to open the Zone Name dialog box, shown in Figure 3.20.
To name the zone, enter the FQDN of the topmost domain that will occupy the zone being created.
){kind=link}
Figure 3.20 Zones are named with the FQDN of the topmost domain that will occupy the zone.
Click Next to open the Zone File dialog box, shown in Figure 3.21.
Data for a standard primary zone are stored in a file with the name you specify. To create a new zone database file, select Create a new file with this file name. I suggest that you use the default filename displayed, which consists of the zone's name with a dns filename extension.
If you want to initialize the zone using data in an existing database file, select Use this existing file and enter the filename in the text box. (This option can be used to import data from a BIND database file.)
){kind=link}
Figure 3.21 Specifying the name of the zone database file.
Click Next to view the closing dialog box (see Figure 3.22), which summarizes the characteristics of the zone you are about to create. Review the zone settings. You can use the Back button to return to any step in the wizard and make changes.
){kind=link}
Figure 3.22 At the end of the wizard, this box describes the zone settings.
Click Finish to create the zone.
The database for a new zone is automatically populated with a minimum set of resource records, consisting of
Start of Authority. This RR identifies the administrative contact for the zone and defines several operational parameters.
Name Server. This RR specifies that the server selected in Step 1 is a name server for the zone.
Host (Address). If the selected DNS server has more than one interface, a host address RR will be created for each interface.
The zone is operational as soon as it is created. It can resolve names, and new RRs can be added to the zone database. The next few sections discuss the various types of RRs with which you can expect to work.
Creating the Primary Reverse Lookup Zone
As mentioned earlier, reverse lookup zones are not required fare. If you choose to create them, the DNS console makes your life easier by creating a reverse lookup RR to match each forward lookup Address RR that you create. So it is a good idea to create your reverse lookup zones before you start populating your zones with host records. Reverse lookup primary zones are created as follows:
In the DNS Management Console, expand the object tree to locate the DNS server that will be hosting the new zone. Right-click the server name.
Choose New Zone in the context menu to open the New Zone Wizard.
Click Next to open the Zone Type dialog box.
Select Standard Primary.
Click Next to open the Forward or Reverse Lookup Zone dialog box.
Select Reverse lookup zone.
Click Next to open the Reverse Lookup Zone dialog box, shown in Figure 3.23.
){kind=link}
Figure 3.23 Specifying the identity of a reverse lookup zone.
You can name reverse lookup zones yourself, but the easiest approach is to enter the netid for the zone and let the DNS console name the zone for you.
To specify the zone using the netid, select Network ID and enter the netid only in the field provided. Any 0 octets that are entered will be included in the zone name. For example, if you enter 10.0, the DNS console will create a zone named 0.10. in-addr.arpa.
To specify the zone name, select Reverse lookup zone name and enter the name.
Click Next to open the Zone File dialog box, shown in Figure 3.24.
Data for a standard primary zone are stored in a file with the name that you specify. To create a new zone database file, select Create a new file with this file name. I suggest that you use the default filename suggested, which consists of the zone's name with a .dns filename extension.
If you want to initialize the zone using data in an existing database file, select Use this existing file and enter the filename. This technique enables you to initialize the zone from data in a BIND database file.
){kind=link}
Figure 3.24 Specifying the name of a reverse lookup zone database file.
Click Next to view the closing dialog box. Review the zone's settings. You can use the Back button to return to any step in the wizard and make changes.
Click Finish to create the zone.
Figure 3.25 shows the reverse lookup zone after it has been populated with a few RRs. Notice that a subdomain named 0 has been created in which to place hosts whose IP addresses begin with 10.1.0. The details about establishing subdomains within a parent zone will be covered later in the chapter.
){kind=link}
Figure 3.25 This reverse lookup zone has been populated with some Pointer resource records.
Note
The technique shown in this section assumes that the reverse lookup zone is based on a class-based IP address range wherein the length of the netid field is 8, 16, or 24 bits.
When classless IP addressing is employed, subnetting and supernetting often result in netids with lengths that are not multiples of 8 bits. The Windows 2000 DNS service supports reverse lookup for classless IP address ranges, but the technique requires an understanding of how to support subzones. We'll have to postpone that discussion until later in the chapter. See the section "Configuring Reverse Lookup Zones to Support Classless IP Addresses."
Creating a Secondary Forward Lookup Zone
It is good practice to have at least one secondary zone for each primary zone. Secondary zones require little maintenance beyond the initial effort required to set them up, but they significantly enhance the robustness and performance of a DNS service. The sample network calls for secondary zones running on server DC2.
Before creating the secondary zone, you must add the server to the Name Servers list for the primary zone. The procedure for adding name servers to a zone is described in the section "Name Servers Properties" later in this chapter. Unless this is done, the secondary zone cannot start after it is created.
Create a secondary forward lookup zone using the following procedure:
Expand the object tree to locate the DNS server that will be hosting the new zone. Right-click the server name.
Choose New Zone in the context menu to open the New Zone Wizard.
Click Next to open the Zone Type dialog box.
Select Standard secondary.
Click Next to open the Forward or Reverse Lookup Zone dialog box.
Select Forward lookup zone.
Click Next to open the Zone Name dialog box.
Enter the name of the zone.
Click Next to open the Master DNS Servers dialog box, shown in Figure 3.26.
Specify the IP address of at least one other DNS server that is authoritative for this zone to serve as a master DNS server for zone transfers. Enter the IP addresses of the DNS masters and click the Add button to move the addresses to the list.
The secondary zone will use the DNS masters in the order they appear in the list. To change the position of an IP address, select it and use the Up and Down buttons to reposition it.
){kind=link}
Figure 3.26 You must designate one or more DNS servers as masters for a secondary zone.
Click Next to view the closing dialog box. Review the settings for the zone that is about to be created. You can use the Back button to return to any step in the wizard and make changes.
Click Finish to create the zone.
You must add the server to the Name Servers list for the primary zone. The procedure for adding name servers to a zone is described in the section "Name Servers Properties" later in this chapter.
If everything has been configured properly, the secondary zone will be populated with RRs copied from the DNS master. The secondary server requests a zone transfer as soon as it is initialized.
Creating a Secondary Reverse Lookup Zone
Before creating the secondary zone, you must add the server to the Name Servers list for the primary zone. The procedure for adding name servers to a zone is described in the section "Name Servers Properties" later in this chapter.
A secondary reverse lookup zone is created much as a secondary forward lookup zone is created. The procedure is as follows:
Expand the object tree to locate the DNS server that will be hosting the new zone. Right-click the server name.
Choose New Zone in the context menu to open the New Zone Wizard.
Click Next to open the Zone Type dialog box.
Select Standard Secondary.
Click Next to open the Forward or Reverse Lookup Zone dialog box.
Select Reverse lookup zone.
Click Next to open the Reverse Lookup Zone dialog box (refer to Figure 3.23).
Select Network ID and enter the netid in the field that is provided
or
Select Reverse lookup zone name and enter the name of the zone.
Click Next to open the Master DNS Servers dialog box.
Specify the IP address of at least one other DNS server that is authoritative for this zone to serve as a master DNS server for zone transfers. Enter the IP addresses of the DNS masters and click the Add button to move the addresses to the list.
The secondary zone will use the DNS masters in the order they appear in the list. To change the location of an IP address, select it and use the Up and Down buttons to reposition it in the list.
Click Next to view the closing dialog box. Review the settings for the zone that is about to be created. You can use the Back button to return to any step in the wizard and make changes.
Click Finish to create the zone.
If everything has been configured properly, the secondary zone will be populated with RRs copied from the DNS master. The secondary server requests a zone transfer as soon as it is initialized.
Modifying Zone Properties
A number of zone settings are defined as properties, including two types of information that are defined as resource records on most other DNS server implementations: the Start of Authority and the zone name servers. To open the zone property pages, do the following:
Right-click the zone in the object tree.
Select Properties from the context menu to open the zone Properties dialog box.
Select the desired property page.
After making desired changes, click OK to close the dialog box.
The next few sections examine the zone property pages.
General Properties
The General properties tab appears in Figure 3.27 with options displayed for a standard primary zone. This page reports the status of the zone and enables you to configure several of the zone operational parameters.
){kind=link}
Figure 3.27 General properties for a standard primary zone.
General Properties Common to Primary and Secondary Zones
The Status field reports whether the zone is Running or Paused. You can pause a zone without stopping the entire DNS service by clicking the Pause button. The DNS server will not respond to queries while the zone is paused. Click the Start button to resume normal zone operation.
The Type field reports the current type of the zone, which can be Primary, Secondary, or Active Directory. You can change the zone type by clicking Change. You can convert a zone to the Active Directory-integrated type only if Active Directory is installed on the DNS server.
Note
Although it is nice to have the capability of modifying zone types on-the-fly, remember that when standard zone types are in use, every zone must have exactly one primary zone. All other copies of the zone must be configured as secondary zones. So if you change the type of the primary zone to secondary, be sure to designate a primary zone on another DNS server. Otherwise, the zone records cannot be modified, and the records on zone secondary name servers will become stale.
The Zone file name field reports the name of the file in which a primary or secondary server stores its copy of the zone database. You can change this filename, but I recommend that you use the default filename whenever possible.
General Properties of Primary Zones
Some of the properties on the General tab apply only to primary zones.
Allow dynamic updates determines whether a primary zone will accept dynamic updates from other services.
The Aging button opens the Zone Aging/Scavenging Properties dialog box, shown in Figure 3.28. Aging determines whether the DNS service will track the age of RRs created automatically by Dynamic DNS. To keep the DNS database from becoming cluttered, aging can be used to purge old RRs.
){kind=link}
Figure 3.28 Aging properties for a primary zone.
If you check Scavenge stale resource records, the DNS server maintains a time stamp for RRs defined through DNS and scavenges records that meet the aging criteria you define. In most cases, host records are created and refreshed by DHCP. Therefore, aging characteristics should coordinate with the DHCP lease renewal time. Typically, DHCP leases are configured to renew every few days. The default lease renewal for the Windows 2000 DHCP service is 8 days.
Note
Automatic scavenging will not take place on the server unless the option Enable automatic scavenging of stale records is enabled on the Advanced properties page for the server (refer to Figure 3.14). See the section "Advanced Properties" earlier in this chapter for more about this option.
Note
DHCP is discussed in Chapter 5, "Dynamic Host Configuration Protocol."
You can specify two aging parameters:
No-refresh interval. This value specifies the number of days that must elapse following the refresh of an RR and the time when the RR can be refreshed again. Microsoft is rather vague on the purpose of this parameter except to state that increasing the value can result in increased retention of stale RRs. I suggest that you set this parameter to a fairly short value, such as one day, because stale RRs will not be purged until the refresh interval expires.
Refresh interval. This value specifies the number of days that must elapse following the most recent refresh of an RR before the RR can be scavenged. This value should be greater than the maximum refresh interval, which is typically the DHCP lease renewal interval. For example, if your DHCP lease interval is 8 days, set this value to 9 days.
Secondary zones obtain all changes in RRs directly or indirectly from a primary zone. All aging is applied at the primary zone and affects records on secondary zones through zone transfers.
Note
Default aging parameters can be set as a property of the DNS server. These default properties apply to all newly created zones unless they are modified for a specific zone. To set default aging properties at the server level, right-click the server name in the object tree and choose Set Aging/Scavenging for all zones from the context menu.
General Properties of Secondary Zones
For a standard secondary zone, the General zone property tab appears as in Figure 3.29. The IP Address list is used to specify the IP address of one or more master DNS servers. You can add or remove IP addresses and change their order. The secondary zone will attempt to initiate zone transfers with master zones in the order that server IP addresses appear in the list.
){kind=link}
Figure 3.29 The General properties tab for a secondary zone.
Start of Authority Properties
Although the Start of Authority is technically a resource record, it is managed as a zone property. Figure 3.30 shows the Start of Authority properties tab on the zone property pages.
){kind=link}
Note
Secondary zones do not have Start of Authority settings. They use settings received from the primary zone.
The Serial number field triggers zone transfers. When a secondary zone server contacts its primary zone server, it checks the zone serial number. A zone transfer is initiated only if the value of the serial number has increased since the last successful zone transfer. After making manual modifications to the zone, click the Increment button to add 1 to the current serial number. The serial number is incremented automatically when the zone is modified through Dynamic DNS (DDNS).
Figure 3.30 The Start of Authority properties for a zone.
Note
Remember, no zone transfer takes place unless the serial number is incremented! DDNS increments the serial number dynamically, but you must increment it when you make manual changes to the DNS database.
The Primary server field specifies the DNS name of the primary master for the zone. This value is defined when the zone is created and seldom requires modification.
By convention, the Responsible person field contains the email address of the primary contact person for the zone. There is a catch because the @ character has a special meaning in DNS database files and cannot appear in the email address. A period is entered in place of the @ character, so drew@pseudo-corp.com would be entered as drew.pseudo-corp.com.
The following three parameters determine how any secondary zones should handle data obtained from this primary zone:
Refresh interval. This time specifies the intervals at which the secondary zone server will contact the primary zone server to determine whether its database is current.
Retry interval. If the host of a secondary zone fails to contact a master zone server when it is time to refresh the zone, this parameter specifies the intervals between repeated attempts to contact the zone master server.
Expires after. This value specifies the lifetime of a secondary zone. If the secondary zone host is unable to contact the master zone server before the end of the expiration interval, the secondary zone is to be considered stale, and data should be discarded. Essentially, this value says that after a certain period of time it is better to provide no data at all than to provide data that might be obsolete.
Note
The default refresh interval for the Windows 2000 DNS server is a very aggressive 15 minutes, reflecting, I suspect, Microsoft's expectation that Active Directory and DHCP will be making frequent changes to the zone. It is particularly critical to expedite replication of service data to secondaries; otherwise, some clients will be unable to access the services.
The addition of service data changes the nature of DNS significantly. The servers on a network are a fairly stable commodity, and don't come and go. But services can be added, started, stopped, or removed fairly frequently. For example, a print server might be stopped for maintenance and restarted after a few minutes; both changes would need to be available to users with reasonable dispatch.
The primary/secondary approach to providing DNS server redundancy has limitations when frequent changes are made to zones because a zone transfer involves transfer of the complete zone database. With large zones, this can result in significant levels of network traffic.
When zones are integrated with Active Directory, zone replication involves transfer of changes only, with a significant savings in the network traffic generated. For that reason, if for no other, I suggest that you consider using Active Directory–integrated zones whenever possible.
Two parameters affect the TTL value that is returned with the results of each query. The TTL specifies the period of time that the results of a query should be retained in a local cache. You can increase the TTL to reduce the frequency of DNS queries while also increasing the risk that clients will use stale data that have been held in cache. There are two TTL parameters:
Minimum (default) TTL. This parameter specifies the minimum TTL for any RRs that are added to the zone.
TTL for this record. This parameter specifies a TTL for the SOA RR only.
Name Servers Properties
The Name Server properties tab (see Figure 3.31) is used to specify the name servers that service a zone. Name servers are listed in Name Server (NS) RRs in the zone database, but you cannot directly edit the RRs. All changes to name servers are made on this properties page.
){kind=link}
Figure 3.31 Name servers assigned to service a zone.
To add a name server to the zone:
Create a Host Address resource record for the name server in the appropriate zone. See the section "Adding Host Address Resource Records" for the procedure.
Open the properties pages for the name server hosting the primary copy of the zone and select the Name Servers page.
Click Add to open the Name Server (NS) dialog box, shown in Figure 3.32.
Enter the FQDN for the name server in the Server name field. There are a couple of shortcuts you can use in this field:
If a Host Address RR already exists, you should be able to browse DNS to find it. Click the Browse button to open a browser and browse a zone that contains the Host Address RR. When you select the RR, the Server name field will be completed, and the IP address will be inserted into the IP address list.
If a Host Address RR already exists and you choose to enter the FQDN of the name server, click the Resolve button to look up the name server's IP address and stuff it into the IP address list.
If the IP address has not been specified by browsing or by resolving a name, enter the IP address for the name server in the IP address field and click Add to copy the IP address to the list.
Repeat Step 5 if the name server has additional IP addresses that were not found by browsing or resolving.
Click OK to add the record to the zone database.
){kind=link}
Figure 3.32 Creating a new Name Server resource record.
Note
Adding a name server to the Name Servers properties page does not make it a functioning name server. You must also create a secondary zone on the name server as described in the sections "Creating a Secondary Forward Lookup Zone" and "Creating a Secondary Reverse Lookup Zone."
WINS Properties
Windows 2000 supports WINS for legacy Windows clients. You can configure DNS zones so that the name server will consult WINS if it is unable to resolve a name query using RRs in a zone database. A restriction is that NetBIOS names constitute a flat namespace, and there is no way to allocate NetBIOS names to specific DNS domains. Therefore, you should enable only one zone for WINS lookup so that WINS name resolution reports all NetBIOS names in the same DNS domain.
Forward lookup zones support standard, forward WINS lookup, which is configured in the property page shown in Figure 3.33. Check Use WINS forward lookup to enable this feature. You must add the IP address of one or more WINS servers to the list provided.
){kind=link}
Reverse lookup zones support reverse WINS lookup, also called WINS-R, which is configured in the property page shown in Figure 3.34. Check Use WINS-R lookup to enable this feature. You must add the IP address of one or more WINS servers to the list provided. Because NetBIOS names do not incorporate a domain name, DNS must supply a domain name. All names resolved using WINS-R are reported in the domain you specify in the field Domain to append to returned name.
){kind=link}
Figure 3.33 Configuring forward WINS lookup.
Figure 3.34 Configuring reverse WINS lookup.
When you enable WINS lookup, a WINS Lookup RR is added to the zone. This resource record is visible in Figure 3.10.
Zone Transfer Properties
As you have learned, both primary and secondary zones can function as master zones for zone transfers. Use the Zone Transfers properties tab, shown in Figure 3.35, to authorize zone transfers. Options on this page can be configured on servers hosting both primary and secondary copies of the zone.
){kind=link}
The zone will function as a master zone only if Allow zone transfers is checked. This box is checked by default on primary zones and is not checked by default on secondary zones.
If zone transfers are permitted, you can authorize them to all DNS servers or to specified name servers by selecting one of the following options:
To any server. Any server can request a zone transfer.
Only to servers listed on the Name Servers tab. The server permits zone transfers only to name servers that are officially recognized as authoritative for the zone.
Only to the following servers. Use this option if you want to specifically designate secondary zone servers by their IP addresses. Add the IP addresses of authorized servers to the list.
Figure 3.35 The zone transfer properties specify which secondary servers can initiate zone transfers for the zone.
Ordinarily, secondary servers wait for the expiration of their refresh timers before checking their masters to determine if a zone transfer is warranted. You can enable the DNS master to notify secondary servers of changes to zone data by clicking the Notify button in the Zone Transfers property tab. This opens the Notify property page, shown in Figure 3.36.
){kind=link}
Figure 3.36 The Notify properties enable a server to notify secondary servers that zone records have been modified.
Managing Resource Records
At this point, we have a DNS service that works but cannot provide much in the way of useful information. That information must be added in the form of resource records that describe the hosts on the network. We're still doing things the hard way, defining everything by hand. But, even if most of the RRs in your zones will be added by Dynamic DNS, you will often need to manually add, remove, and modify RRs. Some things—such as mail exchangers, round robin addressing, and aliases—just have to be set up manually.
Name Server and Start of Authority RRs are manipulated using the Properties pages for the zone with which they are associated and require no further discussion. There are dozens of types of RRs that are simply beyond the scope of this book. For our purposes, we need to consider three types of RRs for manual entry:
Address (A) RRs, which identify hosts
Mail Exchanger (MX) RRs, which identify mail servers
CNAME RRs, which provide aliases for hosts that already have hostnames
Adding Host Address Resource Records
Address RRs that match a hostname to an IP address will probably be the most populous RRs in your DNS namespace. Every Active Directory domain controller will be identified in DNS with an Address RR. Additionally, if you are configuring your TCP/IP clients using DHCP, you will probably use DDNS to create an Address RR for each DHCP client.
Note
If you're used to another implementation of DNS, you might be a bit confused because Microsoft refers to Address RRs as Host RRs. But, when you create a Host record in the Windows 2000 DNS console, an Address resource record is added to the zone database.
To support Microsoft's convention along with everybody else's, I will call them Host Address resource records.
From time to time, however, you will find it necessary to add static Host Address resource records. Many devices cannot or should not be assigned dynamic IP addresses, such as routers and DNS servers. To assign names to these devices, you must create a static Host Address record.
Another reason for creating static Host Address RRs is that RRs created with DDNS are subject to aging and might be scavenged. RRs that you define manually are static and are not subject to scavenging.
The sample network has two servers that might be accessed by outside users: http://www.pseudo-corp.com and ftp.pseudo-corp.com. Additionally, it will be useful to assign a name to the internal router interface to make it easier to manage the router. Host Address records must be manually created for these devices.
To create a Host Address resource record:
Open the DNS console and browse the object tree to select the zone that will contain the Host Address RR.
Right-click the zone, or right-click in the Resource Record pane.
Select New Host in the context menu to open the New Host dialog box, shown in Figure 3.37.
Because the resource record is created in the zone that was selected in Step 2, it is unnecessary to specify the host's FQDN. Enter the host's name in the Name field.
){kind=link}
Note
An FQDN can be optionally specified in the Name field. See the section "Supporting Subdomains" later in the chapter to see one reason why you might do so.
Figure 3.37 Creating a new Host Address resource record.
Enter the host's IP address in the IP address field.
Check Create associated pointer (PTR) record if you have created a reverse lookup zone and want the DNS Management Console to create an appropriate PTR record. For automatic creation of PTR RRs to work, the primary for the reverse lookup zone must reside on the computer on which the Host Address RR is being created.
Click Add Host to create the RR.
Adding Mail Exchanger Resource Records
The sample network incorporates a single SMTP mail server. Mail servers that need to deliver mail to any of the domains on our network will query DNS for Mail Exchanger RRs that identify mail servers for the domains. Therefore, a Mail Exchanger RR must be created for mail1.pseudo-corp.com.
To create a Mail Exchanger RR, do the following:
Create a Host Address RR that identifies the mail exchanger. The Host Address RR can be in any domain, but the Mail Exchanger RR refers to the computer by name, so the Address RR has to exist or the Mail Exchanger RR won't work properly.
Open the DNS console and browse the object tree to select the zone that will contain the Mail Exchanger RR.
Right-click the zone, or right-click in the Resource Record pane.
Select New Mail Exchanger in the context menu to open the New Resource Record dialog box, shown in Figure 3.38.
In the Host or domain field, enter the name of a host or domain that is a recipient of mail delivered by this mail exchanger. In most cases, this field is left blank, in which case the delivery domain is the same as the domain in which the RR is created.
){kind=link}
Figure 3.38 Creating a new Mail Exchanger resource record.
Note
Periods are not allowed in the Host or domain field. If you need to create a Mail Exchanger RR for a child domain, add the child domain as described later in the chapter and create the Mail Exchanger RR in the child domain.
In the Mail server field, specify the FQDN of the mail exchanger. This is a rare instance when you must enter a FQDN, but it makes sense because the mail exchanger could be a machine that handles mail for several domains.
If the Host Address RR for the mail exchanger was created previously, you can click the Browse button and browse the domain database and select the host by its resource record.
Note
I wish Microsoft would standardize on terminology. It's bad enough that they use the term Host to refer to an RR that everyone else calls an Address RR. But in the same procedure they use the terms mail server and mail exchanger to refer to the same thing. Well, they are the same thing, so don't let the changes in terms throw you.
In the Mail server priority field, enter a number in the range of 0 through 65535. (Mail exchanger priorities are discussed following this step-by-step procedure.)
Click OK to create the resource record.
To enable mail delivery to continue when a mail exchanger is shut down, it is common to configure two or more mail exchangers to service a domain. The Mail server priority value determines the order in which various mail exchangers will be used.
Note
The mail server priority parameter is referred to as a mail server preference in many DNS references. The function is the same regardless of the name being used.
Suppose that a domain is serviced by the following three mail exchangers:
mail1.pseudo-corp.com with a priority of 1
mail2.pseudo-corp.com with a priority of 25
mail3.pseudo-corp.com with a priority of 10
An outside mail program will attempt to send mail addressed to this domain to mail exchangers mail1, mail3, mail2 in that order.
Alternatively, suppose that these three mail exchanger records are defined for the domain:
mail1.pseudo-corp.com with a priority of 10
mail2.pseudo-corp.com with a priority of 5
mail3.pseudo-corp.com with a priority of 10
First, the outside mail program tries to deliver mail to mail2. If mail2 is unavailable, it arbitrarily selects mail1 or mail3. If that server is unavailable, the outside program attempts to contact the remaining priority 10 mail exchanger.
Priority values are purely relative. Priorities of 1 and 10 have exactly the same effect as priorities of 1 and 2. It is common practice to leave gaps in the priorities that are selected to make it easy to insert a new mail exchanger in the middle of the priority sequence.
Supporting Aliases
In the previous section, notice that each of the Web servers has a dual identity. You can add as many Host Address RRs as you want for a given IP address.
In some cases, however, you might want to provide additional names by configuring aliases for existing names. Suppose, for example, that you have set up Microsoft's Internet Information Server on a computer. IIS can provide a wide variety of services, including World Wide Web and FTP. You want to offer the domain names http://www.pseudo-corp.com and ftp.pseudo-corp.com. In fact, that is the situation on the sample network.
Yes, you could define each name with a Host Address resource record. But then, what happens if the IIS server is moved to a different subnet and receives a new IP address? You would need to remember to modify every Host Address RR that points to the server.
But aliases point to a hostname, not to an IP address. So one approach would be to create the following RRs:
A Host Address RR that relates the name iis.pseudo-corp.com to the IP address 10.1.0.200
An alias that associates the name http://www.pseudo-corp.com with iis.pseudo-corp.com
An alias that associates the name ftp.pseudo-corp.com with iis.pseudo-corp.com
Now, if the IP address for iis.pseudo-corp.com is changed, the aliases will still point to the correct host.
In DNS terminology, an alias is called a canonical name and is defined in a CNAME resource record. The procedure for creating an alias is as follows:
Create a Host Address RR for the device.
Browse the object tree in the DNS console to locate the domain in which the alias will be created.
Right-click the name of the domain and select Alias from the context menu to open the New Resource Record dialog box, shown in Figure 3.39.
Enter the alias name in the Alias name field. Omit a domain name to create the alias in the domain selected in Step 2. Or include the name of a subdomain to create an alias in a child domain.
Enter the FQDN of the target host in the Fully qualified name for target host field. You can click the Browse button to select the target host by browsing the DNS database.
Click OK to create the resource record.
){kind=link}
Aliases make it easier to change host IP addresses. That's the primary reason for using them. But aliases cannot be used to configure round robin addressing. If you require round robin addressing, you will need to create Host Address resource records.
Figure 3.39 Creating an alias resource record.
DNS Management: What's Happened So Far
It has taken a lot of steps to get us this far. At this point, the DNS service supports the simple network shown in Figure 3.9. Although it looks like a lot of work is required to establish the basic configuration, the work goes very quickly, particularly after you have a bit of experience. To summarize, the basic sequence of events is as follows:
Create the desired primary forward lookup zones.
Create the desired primary reverse lookup zones.
Review the Start of Authority records in the primary zones. Verify the root name servers and operational parameters. Add the mail address of the primary zone contact.
Add PTR resource records to the reverse lookup zones that enable reverse lookups to the zone name servers declared in Steps 1 and 2.
Create Host Address resource records for any name servers that will host secondary zones.
Create the desired secondary zones anytime after the primary zones are established.
Create any other required resource records.
Testing the Name Server
Windows 2000 includes the NSLOOKUP utility, which can be used to query DNS servers and verify their correct operation. But a simple test is simply to ping a host by its domain name. ping will attempt to resolve the hostname to an IP address through DNS before attempting to communicate with the target host.
Chapter 2, "TCP/IP Protocol Concepts," introduced ping, which generates ICMP Echo Request messages and attempts to solicit Echo Reply messages from a target host. Figure 3.40 illustrates the result of pinging a host by name. If the DNS lookup succeeds, the resulting IP address is reported in the resulting dialog.
){kind=link}
Figure 3.40 Pinging a host by name to test DNS operation.
Scaling DNS for Large Networks
Until now we have looked at the most rudimentary of DNS features, features that are essential on all networks. Now we will examine some more advanced features that enable DNS to support larger and busier networks. We will look at two techniques for scaling DNS:
Methods of supporting subdomains
Using round robin addressing to distribute access to multiple servers
Figure 3.41 shows a more elaborate network than that in Figure 3.9. In this case, Pseudo Corporation has two sites. The hosts at those sites will be placed in subzones that will be managed locally. For the purposes of this exercise, server dc2 has been relocated to Paris and now has the IP address 192.168.25.2. The following domains are required:
){kind=link}
pseudo-corp.com. This zone will contain RRs for all publicly accessed hosts, such as the Web, mail, and FTP servers. The primary for this zone will be in Chicago.
chicago.pseudo-corp.com. This zone will contain RRs for all hosts based in Chicago. The primary for this zone will be hosted by a server in Chicago. A secondary zone will be hosted by a name server in Paris.
paris.pseudo-corp.com. This zone will contain RRs for all hosts based in Paris. The primary for this zone will be hosted by a server in Chicago. A secondary zone will be hosted by a name server in Chicago.
1.10.in-addr.arpa. This is the reverse-naming zone for hosts in Chicago. The primary for this zone will be hosted by a server in Chicago. A secondary zone will be hosted by a name server in Paris.
25.168.192.in-addr.arpa. This is the reverse-naming zone for hosts in Paris. The primary for this zone will be hosted by a server in Paris. A secondary zone will be hosted by a name server in Chicago.
Figure 3.41 This DNS namespace has two subdomains and two sites.
All mail will be addressed to the pseudo-corp.com domain, for example, drew@pseudo-corp.com. Multiple mail servers will be located in Chicago.
The corporation has installed three World Wide Web servers to keep up with demand. All Web servers contain the same information, and we want to balance usage across the three servers. The required technique is called round robin addressing.
Alias names will be assigned to select hosts. Aliases enable the same host to have more than one DNS name.
The first order of business is to establish support for the subdomains. Then we can populate the namespace with records.
Supporting Subdomains
There are two ways to support hosts in a DNS subdomain:
Include the child domain in the same zone as the parent domain. This approach separates the domains but requires them to be hosted by the same name server. This is the technique that will be used to establish the chicago.pseudo-corp.com subdomain.
Create the child domain in a separate zone. This approach separates the domains and enables them to be hosted by separate DNS servers. This technique will be used to support paris.pseudo-corp.com.
Creating a Child Domain in the Parent Domain's Zone
This technique is more commonly employed when the same server will host the primary copies of both the parent and child zones. It is very simple to create the child domain:
Open the DNS console and browse the object tree to select the zone that will contain the child domain.
Right-click the parent zone.
Select New Domain in the context menu to open the New Domain.
Enter the new domain name.
Click OK.
Figure 3.42 shows the chicago subdomain, hosted in the pseudo-corp.com zone. Notice that the subdomain does not have Start of Authority or Name Server resource records. Those records are assigned at the zone level.
){kind=link}
It is also unnecessary to delegate authority for this child domain, as is required when the child domain will be hosted by another name server, as described in the next section.
Figure 3.42 The chicago child domain is hosted in the pseudo-corp.com zone.
Note
A zone can contain the records for one or more domains. This is the reason DNS terminology distinguishes between domains and zones. The zone is named after the topmost domain in the hierarchy.
Creating a Child Domain in a Separate Zone
If the same DNS server will not host the primary databases for the child domain, it is necessary to add resource records to the parent domain that delegate control to the zone containing the child domain. The procedure for doing so gets a bit involved because appropriate hints must be placed in the parent domain. First, the zone is created to host the child domain. Then the parent domain is configured with the delegation resource records.
Creating the Zone for the Child Domain
The procedure for creating the zone is the same one that we followed earlier in the section "Creating the Primary Forward Lookup Zone." On a name server in Paris, we use the New Domain Wizard to create a zone named paris.pseudo-corp.com. Then we add the resource records for the paris subdomain. The results are shown in Figure 3.43.
){kind=link}
Figure 3.43 The paris.pseudo-corp.com primary zone on server dc2.
Also create at least one secondary zone. A secondary zone can be created on any name server. For our purposes, it will be created on the name server dc1 in Chicago.
Delegating Authority to the Child Zone
Next, the zone delegation records must be added to the pseudo-corp.com zone. Here is the procedure:
Expand the object tree to locate the parent domain and right-click the parent domain name.
Choose New Delegation in the context menu to open the New Delegation Wizard.
Click Next to open the Delegated Domain Name dialog box, shown in Figure 3.44.
){kind=link}
Figure 3.44 Delegating authority to a domain.
Enter the name of the subdomain in the Delegated domain field. The resulting FQDN will be completed for you in the Fully qualified domain name field.
Click Next to open the Name Servers dialog box, shown in Figure 3.45.
){kind=link}
Figure 3.45 Specifying name servers that are authoritative for a delegated domain.
Use the Add, Edit, and Remove buttons to designate the names and IP addresses of name servers that are authoritative for the delegated zone.
Click Next and review the delegation settings.
Click Finish to complete the wizard and add the delegation hints to the domain.
Figure 3.46 shows the pseudo-corp.com zone after hints have been added for the paris subdomain. The hints consist of two types of entries:
){kind=link}
A subdomain folder, which in the present example is named paris
Within the subdomain folder, Name Server RRs that identify name servers authoritative for the subdomain
Figure 3.46 Domain records showing a delegation of authority.
Notice that delegated name servers are identified by their FQDNs. Consequently, a matching Host Address RR must exist for each name server.
Supporting Round Robin Addressing
As mentioned earlier, the expanded Pseudo Corp network has three Web servers that will share the load of servicing user requests. All three Web servers have identical copies of the Web site, and it's up to DNS to enable users to access them.
The required mechanism is amazingly simple: Create a Host Address resource record for each Web server. Use the same domain name in each Host Address resource record, but point each RR at the IP address of a different computer. Figure 3.47 shows the resource records that are required.
){kind=link}
Figure 3.47 Resource records providing round robin name support.
Notice that each Web server has an individual name (www1, www2, and www3). These are necessary so that the administrators of the Web servers can access the hosts individually to manage the computers and to upload copies of the Web files.
But there are also three Host Address RRs for the hostname www, each with a different IP address. When clients ask DNS to resolve http://www.pseudo-corp.com, the name servers for pseudo-corp.com will respond by cycling through the RRs that match the hostname. Thus some clients will be sent to host 10.1.0.200, some to 10.1.0.201, and some to 10.1.0.202.
Note
Round robin addressing is enabled by default. It can be disabled on the Advanced Properties page for the zone. See the section "Advanced Properties" earlier in this chapter for an explanation.