Network Computingwww.networkcomputing.com

Despite the advantages of dynamic registration, NOS naming services have had major problems in large-scale environments. Anyone who ran a multiserver Novell NetWare shop during the WAN boom of the 1990s probably still feels the pain of implementing SAP filters. Problems with distributed WINS installations are legendary, too. Conversely, DNS has worked remarkably well on the world's largest and most distributed networks, and has done so for nearly two decades. So, though DNS may be high-maintenance in terms of data-loading, it has proven to be scalable and functional in complex networks, which none of the other naming services can claim.

As Internet technologies continue moving ever closer to center stage as the key elements of the corporate NOS platform, however, the need for a dynamic name-registration service is proving to be more pressing. This is particularly true as technologies such as DHCP become increasingly popular for automated address management. When addresses change daily, the host names linked to those addresses also must be changed daily if the names are to be relevant.

Updating DNS

The solution to this challenge was provided in RFC 2136 (ftp.is.co.za/rfc/rfc2136.txt), which describes a mechanism for adding and deleting data from DNS zone tables using an extension of the DNS protocol called dynamic DNS. Over the past few years, work on this front has progressed to the point where multiple DNS servers now support the protocol (the bulk of the supporting products are integrated DNS-DHCP servers) and where client operating systems also are starting to implement it as centerpiece technology.

Unfortunately, however, the technology is complex and difficult to implement securely--two factors that have slowed the rate of deployment dramatically. They not only have hindered development work significantly, but have slowed the adoption of the technology within the end-user community as administrators have had a hard time grappling with the issues surrounding the protocol. However, now that popular desktop clients are aggressively embracing the protocol, it's no longer an avoidable technology.

Using the protocol in some form--at least in conjunction with a DHCP server--will make the average network manager's life much easier.

The Message Structure

Dynamic DNS reuses the existing DNS message structure, so if you're familiar with DNS messages you've cleared the biggest hurdle. If you haven't worked with DNS messages, RFC 1035 (www.faqs.org/rfcs/rfc1034.html) outlines this structure. The key distinctions between normal DNS query/ response messages and dynamic DNS messages are different operation codes in the headers (dynamic DNS uses an "update" message with an operation code of "5" instead of the "0" used with standard query messages), extended response codes and interpretations of the existing message sections. Update messages reuse enough of the standard-query-message structure to pass through the infrastructure unmolested, and existing code can be made to work with it more easily than if an entirely new message structure were required.

Sections of Update Messages

The three main sections of an update message are the zone section, which defines the domain to which the update applies; the prerequisites section, which defines the conditions that must be met before the update is applied; and the update section, which defines the changes that need to be made. In addition, update messages also can reuse the additional-data section to provide ancillary information--such as the target domain name for an alias--that may be required for the update operation to succeed.

Update messages can consist of multiple updates, and the only restriction on these messages is that all updates must apply to the same zone. For this reason, the zone section always specifies the control domain for the zone to which the update or updates apply (see screen, page 221). Because this section is normally used to relay a "question" in a standard query, this entry also requires that a resource-record type be provided. With dynamic DNS, the resource-record type must be specified as the start-of-authority resource-record type (this isn't used for anything in particular -- it's just there as place-holder data).

Sometimes update operations will be conditional on pre-existing data or the lack thereof. For example, you may not want to add an IP address to a host if that host is defined with another address or if another host already has registered the IP address in question. The prerequisite section allows the query to identify the conditions that must (or must not) exist before the query can be processed. It's important to note that these preconditions will be tested at the server during update processing, with the update message succeeding or failing depending on the prerequisites. If the conditional check fails, the entire operation will fail, and it will be up to the client to deal with the total failure error.

There is a variety of prerequisite actions that can be specified; they are summarized in "Prerequisite Processing".

Because prerequisite data is provided in the space normally reserved for "answers" in standard query responses, the prerequisite data is formatted in traditional answer format and is provided with as much detail as necessary. For example, if a prerequisite needs to verify that an entry exists with a specific resource-record type associated with it--regardless of the resource record's data--no resource-record data will be provided in the prerequisite section. Conversely, tests that need to verify whether specific data exists will provide that data.

The last critical section of the update message is the update section, which defines the specific course of action to be taken if the prerequisites succeed. Because the update section uses the traditional "authority" section, this data is provided in complete-answer format, with as much data as is necessary to complete the task. There are four kinds of update actions available (listed in "Update Operations"), though they fall into only two general categories: add and delete. There is no modify operation; if a specific resource record must be changed, it must first be deleted and then added with the new data. Because dynamic DNS allows multiple operations in a single message, all this can be performed in a single task if necessary, though cautious clients may perform multiple operations in multiple messages.

In cases where operations and events are specified (the prerequisite and update sections of the DNS message), the operation to be performed is alluded to using pattern-matching and comparison rules. There are no "verbs" in dynamic DNS, because there's nowhere in the message to provide these hints. Instead, this data has to be inferred from the data format. See our related stories online at http://www.nwc.com/1119/1119ws1side1.html and http://www.nwc.com/1119/1119ws1side2.html for information on the operations and their pattern-matching rules.

The Update Process

Before any update messages can be sent, the dynamic DNS client has to locate a server that is authoritative for the domain name in question to ensure that the request is sent to a server that can make the change. In addition, to provide this data in the zone section of the update message, the client must find out which zone table controls the domain name being modified. Both of these goals usually can be achieved by issuing a lookup query for the start-of-authority resource record associated with the target domain name. Data from the resulting response is then used to determine the controlling zone for the domain name and the primary master server for the zone.

For example, if a dynamic DNS client needed to update the bacteria.win2k.ntrg.com. host entry with a new IP address, it would first try to locate the primary master server for the bacteria.win2k.ntrg.com. domain name by issuing a query for the start-of-authority resource record associated with that domain name.

If a start-of-authority resource record already exists for that domain name (which it would if bacteria were a subdomain of win2k.ntrg.com.), it would be returned as an answer. The mname field from the start-of-authority response then could be used to determine the primary master server for that domain. However, if the resource record doesn't exist (it wouldn't since bacteria is a host in the win2k.ntrg.com. domain), the resulting error message would contain a start-of-authority resource record for the controlling zone, and the mname data would point to the controlling server for the parent domain.

Once the controlling zone and primary master server are located, the update message can be sent. If the server is inaccessible to the client--perhaps because of firewall rules or some other condition--the client may also choose to query for the name server resource records associated with the controlling zone and send the message to one of those servers, with the expectation that the other server or servers will forward the message to the primary master for processing. In those cases where multiple servers can act as the primary master server for a zone, such as when multiple servers interface with a shared back-end database, the message may not even need to be forwarded.

Security Concerns

RFC 2137 (www.faqs.org/rfcs/rfc2137.html) -- a sister document to RFC 2136 -- defines a mechanism and framework for implementing secure DNS updates, though it is not actively supported and is likely to be retired soon. Instead, the key transaction security mechanisms defined in RFC 2845 are gaining favor, though variations are already present. Microsoft Windows 2000 uses a GSS (generic security service)-based derivative for its secure updates. BIND 9 (Berkeley Internet Name Daemon version 9) will use HMAC- MD5 keys. And because the authentication mechanisms used for secure DNS are not entirely consistent yet, it's unlikely that this problem will be resolved until implementations settle on a standard methodology.

An Imperfect Solution

The typical solution to this problem is specified in RFC 2136, which states that servers should be able to limit updates to specific networks, though this can also be touchy. Since many large networks provide direct access to their internal DNS servers, disabling access controls on updates is a bad idea unless you're blocking outside DNS traffic (you don't want your Web server pointing to somebody else's site, do you?).

Some firewall vendors are talking about adding filters that block dynamic DNS updates explicitly, though nothing is currently shipping in this sector.

Eric A. Hall is president of EHS Co., a network technology research and testing company in San Mateo, Calif. Send your comments on this article to him at ehall@ehsc.com.