DDNS links network services with application resources
DNS is the Internet’s naming service. DNS maps the names of hosts to their IP addresses, letting users locate Web sites and mail servers. Traditionally, network administrators manually updated DNS databases.
Enter Dynamic Host Configuration Protocol (DHCP ), which automates the assignment of IP addresses in a network. DHCP might assign a host only a temporary address, requiring many different addresses in succession. Hundreds or thousands of computers at a site may receive IP addresses in this way. As a result, the number and frequency of IP address changes makes manual DNS administration impractical.
To solve the problem, the IETF extended DNS to accommodate these dynamic networking environments. The IETF developed what is now referred to as Dynamic DNS (DDNS), a standard mechanism for managing the identity of dynamic networks created through DHCP. DDNS is an umbrella term for three related DNS protocol extensions: Dynamic Update, Notify and Incremental Zone Transfer (IXFR). The three DDNS protocol extensions are closely related.
Easing administration
Name servers, typically implemented as software, provide DNS information to computers on the network. The information is divided into administrative units called zones.
Before DDNS came along, network administrators typically administered zone data by editing text files called zone data files. To add information about a new host, an administrator would add an A (address) record to the host’s name, specifying its IP address, and add a PTR (pointer) record to the host’s IP address, specifying the name of the host at that address.
Dynamic Update is the basic DDNS operation, letting software such as DHCP clients or servers send special messages to name servers to update zone data. A DHCP server, for example, can send an update message to the primary name server for a particular zone to request that a record be added to that zone to map a DHCP client’s name to its new, DHCP-issued IP address. The DHCP server might send a subsequent update message to the primary name server for a reverse-mapping zone to add a PTR record for the DHCP client.
A dynamically updated zone can change much more quickly than a zone administered by manually editing a zone data file. Unfortunately, DNS traditionally uses a mechanism that reports those changes in intervals of about 15 minutes. That can be an eternity in dynamic-update time scales.
Enter Notify. Notify lets the primary name server for a zone tell the secondary name servers that the contents of a particular zone have changed. The name server sends a message to the secondary name servers for a zone to say, “The new serial number for foo.com is 10.” Secondary name servers that receive these messages verify that the zone has changed and request a zone transfer. This permits rapid convergence of all a zone’s authoritative name servers.
A name server determines which other name servers to notify by looking at the name server records for the zone that has been changed. (The name server records list the set of primary and secondary name servers for the zone.) This creates a new problem – much more frequent zone transfers by secondary servers. Because zone transfers entail sending the complete zone data set, this is a waste of bandwidth when only one or a few changes have occurred.
To make these zone transfers more efficient, the IETF developed IXFR, which lets a secondary name server request only the changes between the version of zone data it has and the current version. The secondary might say, “I have serial number 10 of zone foo.com. Please send me the changes necessary to bring me up to date.” The primary name server examines a journal to determine which changes correspond to which versions of the zone, then sends a record of these changes – a series of additions and deletions – to the secondary.
Together, these mechanisms meet the basic requirement of letting programs update zone data without administrator intervention and then deal with that capability’s consequent complications.
Liu is vice president of architecture for Infoblox. He can be reached at cricket@infoblox.com.
