Name Registration and Resolution in Windows NT

Windows IT Pro

- Advertise

Name Registration and Resolution in Windows NT
View the book table of contents

Author:	Emmett Dulaney Vijay Sankar Sharon E. Sankar
Published:	June 1999
Copyright:	1999
Publisher:	29th Street Press

Dynamic DNS: Theory
At the time of this writing, the mechanism for dynamic DNS was to follow the mechanism described in RFC 2136 and RFC 2137; therefore, we include here a brief synopsis of this mechanism. These RFCs may be found at the following sites: ftp://ftp.isi.edu/in-notes/rfc2136.txt
ftp://ftp.isi.edu/in-notes/rfc2137.txt In summary, a requestor (slave) whose zone files have been altered sends a DNS update message to either a primary master server or a server configured as a forwarder. The format of the update message is

Header — contains the Opcode, the ID, various other codes such as number of resource records, and whether the message is a response or request. The initial update message is a request.
Zone — contains information about the zone name, the type, and the zone class.
Prerequisite — describes which resource records and resource record sets should currently exist in the zone.
Update — specifies which resource records and resource record sets should be added, updated, or deleted.
Additional Data – reserved for future use.

The DNS message is distinguished as type “update” when the Opcode field within the Header section has a value of 5.

The responder (master server or forwarder) examines the Opcode field and responds with Rcode=4 (or NotImp if it does not recognize the Opcode or if Dynamic DNS has not been implemented).

The responder then examines the Zone section of the message; this section consists of three subsections: Zname, Ztype, and Zclass. Because only one zone can be updated per DNS update message, there must be only one Zname, and the Ztype must be SOA. Otherwise an error is returned to the requestor. The Zclass denotes the zone class — which could describe either Internet class or the class of network or the type of software the record supports. The responder then checks to see whether the Zname corresponds to the names of zones for which it has authority and responds with an error if it doesn’t. If the server is a zone master, it processes the update itself; if it is a slave, it forwards the request to the primary master.

Within the Prerequisite section of the original DNS Update message, a set of conditions are prescribed for the current state of the responder’s zone (so identified by Zname). The following are the five conditions that can be checked:

The resource record set of the specified name and type exists within the zone and has the class specified by Zclass. Resource record set may be either a single record or the name of a group of records (value independent).
The resource record set exists within the zone, has the class specified by Zclass, and contains the same members with the same Rdatas as that specified within the Prerequisite section (value dependent).
The resource record set doesn’t exist.
The name is in use. At least one resource record with this name exists within the Zone and Class specified in the zone section and it can’t be empty.
The name is not in use. No resource records have this name; however, an empty record may have this name.

If any of the tests within the prerequisite section fails, the update doesn’t continue and an error is returned.

If the prerequisites are satisfied, the responder checks the requestor’s permissions to update the resource records. Permissions are checked using either secure DNS as described in RFC 2137 or another mechanism as implemented by the administrator. If this test is passed, the update process begins. Four possible update procedures may take place:

Resource records may be added to a resource record set.
A resource record set may be deleted.
All resource record sets may be deleted from a name.
A resource record may be deleted from a record set.

The resource records and resource record sets that are to be updated are included in the original DNS update message of the requestor.

The update process begins with a prescan of the resource records located within the update section of the original DNS update message. Each resource record is parsed and its class checked to see whether it is Any, None, or the same as the zone class specified in Zname. If it is none of these, an error is returned to the requestor. If the resource records pass this test, the update continues according to the four update procedures listed above.

If the update procedure completes successfully, the server commits the changes to nonvolatile storage and sends back a positive acknowledgement to the requestor.

It is important to note that Dynamic DNS as described in RFC 2136 comes with the following limitations and specifications:

Only one zone at a time may be processed.
Only one SOA is allowed per zone, which is consistent with static DNS. An attempt to add a new SOA resource record will overwrite the old SOA resource record.
If a WKS (workstation) resource record is to be updated, only Name, Class, Type, Address, and Protocol will be compared. If all of these are the same, the new WKS resource record will replace the old record even if the service masks differ.
If a CNAME resource record is to be updated, only Name, Class, and Type are compared. Only one CNAME resource record is allowed.
Two resource records are considered equal if their Name, Class, Type, Rdlength, and Rdata fields are equal.
A zone must exist to be updated. New zones can’t be created dynamically.

Using Dynamic DNS opens up a whole new set of considerations that weren’t applicable to static DNS.

What happens if simultaneous requests for updates come from various slaves? Who is authoritative? What happens if one update request negates or changes another update request? Unfortunately, these situations are still unclear. RFC 2136 describes a mechanism for using marker resource records with different Rdata fields, which will ensure the correct sequential processing of updates. According to this mechanism, marker records are explicitly added to and deleted from record sets, then the prerequisite section checks for the existence of a previous marker resource record before proceeding with the update.
How does the server know that the requestor is who it says it is? This issue is covered extensively in RFC 2137.
What happens if a primary zone master crashes before completing the update? How are the zone files rebuilt? RFC 2136 specifies that the zone returns to its previous state if an update operation fails at any point. Moreover, the server must commit the changes to nonvolatile storage (a hard disk) before sending a positive update response to the requestor.

So much for the theory. In the next section, we look at how dynamic DNS is implemented in Windows 2000 Server.

DIFFERENCES BETWEEN NT 4.0 AND 2000 SERVER

As we’ve mentioned, DNS is an integral part of Windows 2000 Server’s Active Directory Service. For a Windows 2000 Server domain controller to use Active Directory, DNS must be installed. If, during setup, the computer that is being configured as a domain controller does not detect DNS, the setup wizard asks if you wish to install and start DNS. If you select no, Active Directory will not work properly. (For more information, see Chapter 7.)

In Windows 2000 Server, DNS is accessed and configured using the DNS Manager snap-in of the MMC. Figure 6.20 is the first screen presented when DNS Manager is selected on a Windows 2000 Server machine configured as a domain controller. To get to this screen, click Start, then Programs, Administrative Tools, DNS Management.

In this case, the unixntbook.com domain was created automatically when we elected to install a DNS server during Active Directory installation and configuration.

Special Note: Configuring a Windows 2000 Server machine as a domain controller is a two-step process. First, you install Windows 2000 Server, then you promote the machine to a domain controller by running dcpromo from the Run dialog box. Running dcpromo starts the Active Directory wizard, and at a certain point during installation, the machine searches for a DNS server. If it doesn’t find one, it prompts you to install DNS. If you select yes, DNS is installed on the machine and the domain name (in this case, unixntbook.com) becomes a forward lookup zone.

To enable a zone for dynamic update, right-click a zone, then select Properties from the drop-down menu. At the bottom of the screen is a check box to enable this zone to be updated dynamically. However, there appears to be no provision, as yet, for specifying which servers are allowed to perform dynamic updates on this zone.

Once a zone has been enabled for dynamic DNS, you can right-click the zone and the first selection in the drop-down menu will be Update Server Data File.

Table 6.5 summarizes some of the differences, both cosmetic and functional, between DNS Manager 4.0 and DNS Manager 2000.

Besides dynamic DNS, several other features are slated to be added to Microsoft Windows 2000 Server’s new version of DNS, including

An improved DNS Notify — Currently, updated zone information is propagated from a primary to secondary server using a pull method, whereby the secondaries request updates at set intervals. Understandably, this method could lead to conflicts if zone information is changing rapidly and the secondaries are not updated quickly enough. The new DNS Notify lets the primary server push the new zone information to the secondary as soon as it’s updated. To register a secondary as a push client, access the zone properties page and click Notify. Type the IP addresses of all secondary DNS servers that must receive updated zone information. If these servers are the only secondary servers that should receive updated information, either via push or pull, select “Only allow access from secondaries included in notify list.”
Incremental Zone Transfer — Currently, all zone information is copied during zone transfers, which leads to unnecessary traffic on the network. In Windows 2000 Server, incremental zone transfer will be enabled, whereby the secondary server checks the version number of the primary against its own version number and makes only the changes that have occurred since the last update. If the version number is greater than or equal to the primary server’s version number, no changes will occur.
SRV Records — As described in RFC 2052, this new resource record type provides for the identification of and automatic connection to computers within a network that provide certain services, such as FTP, telnet, or HTTP. For example, if a user wanted to Telnet to an organization’s Telnet server, a resource record could be added that would identify the Telnet server within the zone, the protocol used, the port, and the Telnet host’s priority and weight. The latter two parameters are used when there is more than one computer in a zone that performs a certain service. Priority indicates which server should be contacted first (a lower number means higher priority). The weight parameter is used when servers have equal priority but load balancing is required.

In the next chapter, we examine the new Active Directory feature of Windows 2000 Server in detail.

Page: 1, 2, 3, 4

ADS BY GOOGLE