Eric A. Hall

NOTE: This article is an archived copy for portfolio purposes only, and may refer to obsolete products or technologies. Old articles are not maintained for continued relevance and accuracy.

October 2, 2000

Dynamic DNS: Big Gain, Big Pain

NOS platforms traditionally implement some form of dynamic name registration for affiliated hosts and applications. This allows their member systems to register system names, network addresses and hosted applications automatically with the NOS as they come online. Other systems and their users could then query the registration system for this dynamic information, thereby facilitating simple lookups for the member hosts and resources—regardless of the network addresses of those resources.

Apple Computer AppleTalk's NBP (Name Binding Protocol), Novell NetWare's SAP (Service Advertising Protocol) and Microsoft Windows' WINS (Windows Internet Naming Service) are examples of this type of dynamic name-and-address registration service. The notable exception among the name-registration services has been DNS, which has relied on the manual maintenance of static configuration files for names and addresses to be registered with the network.

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.

The solution to this challenge was provided in RFC 2136, 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 however —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 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.

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.

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, 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 the sidebars for details on the pattern-matching rules).

Figure 1

The Update Section

RFC 2136 defines four operations that are possible with dynamic DNS. They're indicated using data provided with each operational entry. Note there are no verbs or commands with dynamic DNS. The operations and their hint patterns are:

Add a Resource Record. If a resource record needs to be inserted into a zone table, all the information for the new resource record must be provided in the update section entry. This includes data that identifies the target domain name, a resource record code, the resource record data, a network class code and a time-to-live value. If the resource record exists, the server will ignore the operation. If the domain name doesn't exist, it will be created with its only resource record consisting of the data provided in this entry. If the domain name exists but with some other data, the resource record data will be added to the existing entry.
Delete a Specific Resource Record. If a specific resource record needs to be removed from the zone table, all the information that describes the resource record must be provided in the update section entry, with the exception of the time-to-live value and the network class code. To distinguish "add" operations from "delete" operations, a domain name that is to be deleted must have the network class code set to "none" (code value 254) as opposed to indicating a specific class. If the domain name does not exist in the zone table, the server will silently ignore the specific operation and return a response that indicates general success. If the resource record specified in the operation is the last resource record associated with the specified domain name, the entire domain name entry will be deleted from the zone table.
Delete All Resource Records of a Specific Type. If all resource records of a specific type need to be removed from a specific domain name, (such as deleting all of the IPv4 Address resource records that are associated with a specific host), only the necessary information will be specified. This specific operation is identified by the update section entry containing a domain name, a resource record code (the group to be deleted), a network class code of "any" (code value 255), zero-length resource record data and a time-to-live value of 0. Note that the use of the "any" network class distinguishes this operation from the operation that deletes a specific resource record (the latter uses a network class of "none"). Also note that since all the matching resource records are to be deleted, no resource record data is provided.
Delete All Resource Records. If a domain name needs to be entirely removed from the zone table, the update section must contain an entry which only describes that domain name. This specific operation is identified by the entry containing the domain name to be deleted, a resource record code of "all" (code value 255), a network class code of "any," zero-length resource record data, and a time-to-live value of 0.

Figure 2

The Prerequisites Section

A key part of prerequisite processing is reporting on failures. Towards this end, multiple responses are defined, any of which may be generated during prerequisite processing. The prerequisite-processing responses are provided in the "response-code" field of the message headers, just as in normal queries. In fact, many of the response codes from the standard query also are used with dynamic DNS responses, though many new responses are defined explicitly for reporting on the success of prerequisite processing.

Although it may seem that a normal lookup query issued by the client prior to update processing could serve the same purpose of detecting existing entries, this isn't entirely true since standard queries are not guaranteed to have access to valid data. For example, the lookup query may be received by a local caching server that answers the query with invalid data. Conversely, an Update Message will eventually have to be processed by a server that is authoritative for the zone in question, so sending prerequisites as part of the Update message practically guarantees that conditions will be tested against accurate and current data.

The five prerequisite comparisons and response codes defined in RFC 2136 are:

Domain Name Must Not Exist. If an update operation needs to verify that a domain name does not already exist in the zone table (regardless of the resource records that may be associated with the domain name), the client provides the domain name to be tested along with a resource record code for "all" (code value 255), and a network class code of "none" (code value 254). Because there is no comparison of the domain name's resource records or their values, the data is set to null and the time-to-live value is set to 0 in these entries. If this prerequisite fails, the name exists error (code value 6) must be returned in the response code of the response message.
Domain Name Must Exist. If an update operation needs to verify that a domain name does exist in the current zone, it provides the domain name to be tested along with a resource code of "all" and a network class code of "any." The use of "any" instead of "none" identifies this prerequisite separately from the Name Must Not Exist prerequisite. Because there is no comparison of the domain name's resource records or their values, the data is set to null and the time-to-live value is set to 0 in these entries. If this prerequisite fails, the nonexistent domain name error (code value 3) must be returned in the response code of the response message.
Resource Record Must Not Exist. If an update operation needs to verify that a domain name exists and does not have a particular type of resource record associated with it, the domain name of the leaf node will be provided along with the specific resource code that needs to be tested. However, the network class code must be "none," and no data should be provided with the resource record, while the time-to-live value should be 0. If the prerequisite fails, the resource record exists error (code value 7) must be returned in the response code of the response message.
Resource Record of Any Value Must Exist. If an update operation needs to verify that a domain name exists and has a specific type of resource record attached to it (regardless of that resource record's data), the domain name of the leaf node will be provided along with the specific resource code that needs to be tested. However, the network class code must be "*" (distinguishing this prerequisite from the Resource Record Must Not Exist prerequisite which uses a network class of "none"), and no data should be provided with the resource record, while the time-to-live value should be 0. If the prerequisite fails, the Resource Record Does Not Exist error (code value 8) must be returned in the Response Code of the response message.
Resource Record of a Specific Value Must Exist. If an update operation needs to verify that a domain name exists with a specific type of resource record with specific data, the domain name of the leaf node will be provided along with the specific resource code that needs to be tested, a network class code that is equal to the data being tested, and the resource record data which must be present. The time-to-live value must be zero, but all other elements of the comparison must be provided. If the prerequisite fails, the resource record does not exist error (code value 8) must be returned in the response code of the response message.

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.

Security Concerns

RFC 2137—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-based derivative for its secure updates, while BIND 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.

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.

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.