Zero Configuration Networking: The Definitive Guide

5.4. Dynamic DNS Updates

Think back to the days before mobile phones. If you wanted to remain in contact while you traveled around, you had to leave detailed directions on how you could be reached. Someone might say, "I have a 10 o'clock meeting with Stan, so you can call me over on the main campus between 9 and 11 at xxx-xxxx. Then, I have lunch with Betty, so you can call me at Sushi Sally's from around noon to 1 at yyy-yyyy. Then, I need to head in to the city. I should be at Dana's around 3, so call me at zzz-zzzz if you need me." Now you just say, "I'll be running around all day, just call me on my mobile." One number follows you around all day, one number that can be used to access the device you carry all day long as you move from one local cell area to another. The person trying to reach you does not need to be aware of your physical location.

Consider the same fun-packed day, but this time you are taking your laptop with you from place to place. If, at each location, you are able to connect to the Internet, then, in the absence of firewalls, you can check your email and use instant messaging with your usual group of friends. For email, you are logging in to a mail server somewhere and initiating a request that conveys your current location. No one sending you email has to track where you are. They sent the mail to an address that is handled by a mail server, and you connect to that same server to download your mail. Similarly, with the chat program, you log in to a server at a well-known DNS name or address to announce your availability and to determine which of your other friends are currently available. No one needs to know the physical location of your laptop. While these solutions work, they are heavyweight and awkward. People don't need to know your location to send you email, but you need to keep polling the mail server to find out if new mail has arrived. The mail server can't tell you when mail arrives if it doesn't know where you are or how to reach you. Instant messaging gives the illusion of direct peer-to-peer communication but requires some organization to run the big "server in the sky" that's actually the intermediary for all communication. The need for a big, expensive server in the sky can be a serious impediment to the creation of new network applications and new uses for the Internet.

Dynamic DNS Update provides part of the answer to this problem. By having a fixed DNS name and using Dynamic DNS Update to update your DNS address record every time your IP address changes, people can now find your current IP address at any time by looking up the current DNS address record for your fixed DNS name.

Wide-area DNS-SD builds on standard Secure DNS Dynamic Update as defined in RFC 2136 "Dynamic Updates in the Domain Name System (DNS UPDATE)" (http://www.ietf.org/rfc/rfc2136.txt) and RFC 3007 "Secure Domain Name System (DNS) Dynamic Update" (http://www.ietf.org/rfc/rfc3007.txt).

The abstract for RFC 3007 explained the need for Dynamic DNS Update as follows.

The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File.

Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone.

5.4.1. Dynamic DNS Update Leases (DNS-UL)

Secure DNS Dynamic Update provides almost all the solution we need, but not quite. It allows a client to create and update records on a DNS server but makes no provision for garbage-collecting stale records. When your laptop arrives on a new network, it can create or update its address records, but what happens if your laptop crashes, or runs out of battery power, or you unceremoniously disconnect its Ethernet cable or shut off the wireless interface without giving it a chance to delete the address record? The IP address you got from the DHCP server has a lease time associated with it, and if the laptop fails to renew the lease, when the time expires the DHCP server will reclaim that address. RFC 2136 provides no such lease time on DNS record creation. Once created, a DNS record remains valid until someone comes along and decides to delete it.

Dynamic DNS Update Leases (see http://files.dns-sd.org/draft-sekar-dns-ul.txt) remedies this omission.

5.4.1.1. Changes to the message format

The requests and responses for DNS-UL use the same format as those described in RFC 2136 for Dynamic DNS Update, with the addition of a single OPT-RR as the last record in the Additionals section. The new EDNS0 Option Code, UPDATE-LEASE, has been assigned the number 2. The advantages of using an OPT-RR to encode the update lease are that (1) minimal modifications to a name server's frontend are required and (2) servers that do not implement this extension will automatically return NOTIMPL.

The fixed part of the OPT-RR is described in RFC 2671 (http://www.ietf.org/rfc/rfc2671.txt), and is shown in Table 5-1.

The variable part of the data is contained in the RDATA and consists of one or more sets of the three fields OPTION-CODE, OPTION-LENGTH, and OPTION-DATA. In the DNS-UL requests and responses, there will be one set of these fields, and the OPTION-CODE will have the value UPDATE-LEASE (i.e., 2), the OPTION-LENGTH will indicate the size in octets of the OPTION-DATA (i.e., 4), and the OPTION-DATA will have desired lease (request) or granted lease (response), in seconds.

In the request, the value of the lease is a signed 32-bit number with the requested lease life in seconds. This value must be chosen to balance between the desire to have accurate information and the need to not burden the network or the server. The current recommended minimum lease is 1,800 seconds, which is 30 minutes. In the response, the value of the lease is the time granted by the server. This value is not restricted to be less than or equal to the value requested and could also be greater.

5.4.1.2. Refresh messages

In order to keep resource records from being deleted by the server, clients should send a refresh message when 75% of the current lease has elapsed. If the client uses UDP and does not receive a response from the server within two seconds, the client can either retry with TCP or continue to retry with UDP, doubling the length of time between successive attempts. If, for any reason, the lease of a resource record expires without being refreshed, the server must not respond to queries with this record and is allowed to delete the record from its database.

Refresh messages are nearly identical to those used for DNS-UL requests. The change is that the resource records to be refreshed are contained in the Update section and in the Prerequisites section as an "RRSet exists (value dependent)" pre-requisite. The requested and granted lease times do not need to be the same as in the original request. If a client has sent more than one update to a single server, the client may coalesce the refresh messages into a single message. The client can include all existing updates to the server as long as at least one of the included resource records has elapsed at least 75% of its original lease.

A server sends an acknowledgment to a valid refresh request. This response is identical to the previously described DNS-UL response and contains the new lease of those records being refreshed. If no records in the refresh request have completed 75% of their leases, the updates are not refreshed and the response will contain the smallest remaining lease of all the records in the refresh message.