If you have a Dynamic DNS hostname assigned to you by your DNS server admin, who ensures that everyone’s hostname is unique, (or if you run your own DNS server with Dynamic Update), you can enter it here and click Apply. The hostname must be fully qualified, so don’t enter a hostname like steve, enter a hostname like http://steve.bonjour.example.com. The yellow dot will turn green to confirm a successful registration with the DNS server, or red if a permanent error occurs, such as trying to update a name that you’re not authorized to update. If the dot remains yellow, that indicates lack of network connectivity; for example, your Ethernet cable may not be plugged in. Connect the cable or otherwise establish connectivity, and the dot should turn green or red as appropriate. Note that hostname registrations will not work if your computer is behind a NAT gateway, unless that NAT gateway supports a NAT port mapping protocol. If you have an Apple AirPort Extreme or AirPort Express base station, you can turn on NAT-PMP, described below, using the AirPort Admin Utility. Certain NAT gateways that support the UPnP Home Gateway Protocol may also work.

If the DNS server requires credentials to authenticate secure updates, click Password...and enter the key name and key data given to you by the DNS operator. The key name is most often the name of your DNS domain, for example, http://bonjour.example.com. The key data or “password” is most often a random-looking string of characters—for example, CnMMp/xdDomQZ4TelKIHeQ==.

If you’d like to advertise services on your machine that are discoverable anywhere on the Internet (or anywhere behind your firewall), click the checkbox and enter an appropriate DNS domain in the Registration panel. DNS-SD-advertised services such as Personal File Sharing, Personal Web Sharing, Remote Login, FTP Sharing, SubEthaEdit shared documents, iPhoto sharing, etc., will be visible from anywhere in the world. As with Dynamic DNS hostnames, if your computer is behind a NAT gateway, wide-area service registrations will only work if the NAT gateway supports NAT-PMP or the UPnP Home Gateway Protocol.

Just like your hostname registration, the DNS server for your DNS-SD domains may require you to enter a key name and password before it will accept service registrations. Simply click Password...and enter the key name and key data given to you by the DNS server operator.

If you don’t want to advertise services on your machine but do want to discover services advertised by others, enter a default browse domain in the Browsing panel.

For fun, try this on Mac OS X 10.4 Tiger or the equivalent steps on Windows using the Bonjour plug-in for Internet Explorer:

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.

LLQ messages extend the standard DNS message format described in RFC 1035 (http://www.ietf.org/rfc/rfc1035.txt) with a new OPT-RR and RDATA format, similar to the way that Dynamic DNS Update was extended as described earlier. This time, the RDATA triples are of the form OPTION-CODE, OPTION-LENGTH, and LLQ-Metadata. The OPTION-CODE is filled with the value of the EDNS0 Option Code for LLQ, which is 1.

The LLQ-Metadata consists of a VERSION field used to identify the version of the LLQ protocol implemented and an LLQ Opcode field that consists of one of the following codes: LLQ-SETUP (1), LLQ-Refresh (2), or LLQ-EVENT (3). The ERROR field is next and contains one of the following error codes: NO-ERROR (0), SERV-FULL (1), STATIC (2), FORMAT-ERR (3), NO-SUCH-LLQ (4), BAD-VERS (5), and UNKNOWN-ERR (6). The remaining two fields are LLQ-ID, which is a unique identifier for a particular LLQ, and LEASE-LIFE, which indicates how long the LLQ will remain in effect.

The setup of long-lived queries is a four-way handshake consisting of the following steps.

In order to extend the LLQ beyond the granted LEASE-LIFE, the client sends a Refresh request when 80% of its lease life has elapsed. This request is identical to the LLQ Challenge Response, with the exception that the LLQ-OPCODE is set to LLQ-REFRESH instead of LLQ-SETUP. The client should coalesce refresh methods for all LLQs established with a given server as long as one of them has elapsed at least 80% of its LEASE-LIFE. If including all of the LLQs causes the message to no longer fit in a single packet, the client should include all that will fit, preferring those closest to expiration . The requested LEASE-LIFE for a single LLQ should equal the original granted LEASE-LIFE. For multiple LLQs, the client should request the same LEASE-LIFE for all of them as the one granted for the soonest to expire.

The server responds to an LLQ refresh message with a response similar to the ACK described in step 4 above with the LLQ-OPCODE set to LLQ-REFRESH. If the client attempts to refresh an expired or nonexistent LLQ, the server returns an ERROR value of NO-SUCH-LLQ. If the client fails to extend the LLQ beyond the granted LEASE-LIFE, or if the client terminates a lease by sending a request with LEASE-LIFE equal to 0, the lease expires.

Once the LLQ has been successfully set up, the server delivers change notifications to the client. There are two kinds of change notification that can occur and require action:

The format of the OPT-RR RDATA begins with the OPTION-CODE with value LLQ and the OPTION-LENGTH field. The VERSION is the version of the LLQ protocol implemented in the server, and the LLQ-OPCODE is set to LLQ-EVENT. The ERROR field has value 0, the LLQ-ID is as above, and the LEASE-LIFE is set to 0.

Upon receiving a change notification from the server, the client sends an acknowledgment back to the server. This acknowledgment is a DNS response echoing the OPT-RR contained in the change notification, with the message ID of the notification echoed in the message header.

A client can first try to issue its LLQ request to the local DNS caching server, just like normal DNS queries. However, most DNS caches today don’t implement LLQ and will return a NOTIMPL or FORMERR error.

In this case, the client should contact the authoritative server directly to issue its LLQ request. The client first uses an SOA query to determine the zone and authoritative server responsible for the name it’s querying. It then does an SRV query for the name _dns-llq._udp. zone to find the target host and port number where LLQ service is offered for this zone. Usually, it will be the same host as the master DNS server but on a port number other than the normal DNS port 53. If the client receives an NXDOMAIN response to its SRV query, the client concludes that the zone does not support LLQs and instead resorts to low-rate polling to keep its data reasonably up to date.

The success of web browsing, email, and instant messaging is due, in large part, to the extent to which the end user has been shielded from the underlying protocols. When casual users click on a link in a web browser, they probably do not stop to consider that they have just issued a request and that the server responding to that request must know where to send the response. They almost certainly don’t consider how this works when they have a private IP address, and all the packets are being modified by the NAT gateway before being sent out to the rest of the Internet.

Figure 5-3 shows the configuration page for a typical NAT gateway. Its real public Internet IP address is 69.3.204.77, but on the local network it uses the private address 192.168.1.1. The public IP address 69.3.204.77 is globally unique—at any moment in time, only one computer on the Internet on the entire planet has that address. On the other hand, at any moment in time, there are thousands, maybe millions, of devices all thinking they have the IP address 192.168.1.1.

Figure 5-3. LAN and WAN settings for a NAT gateway

A computer on the local area network (LAN) connected to this NAT gateway may have an IP address such as 192.168.1.151. As with the address 192.168.1.1, there are probably thousands of computers around the world using the address 192.168.1.151 on their own LANs. If you or I were to send a packet addressed to 192.168.1.151, it would certainly not arrive at any machine outside of the LAN we were currently connected to.

When computer 192.168.1.151 sends out an outgoing TCP request to some machine on the Internet, the NAT gateway rewrites the source address in the packet from private address 192.168.1.151 to public address 69.3.204.77 (which is the IP address of the NAT gateway in this example). So that it can make sense of the replies that come back, it also rewrites the port number to a unique one that it’s not already using. Now, the outgoing packet has a globally meaningful source address, and when the machine on the Internet replies, the replies will successfully make it back to the NAT gateway. When the NAT gateway gets the reply, it looks up the destination port number in its table to see which LAN client this packet belongs to. It then rewrites the destination address and port number back to what the local client is expecting, corrects the packet checksum, and forwards it on.

The reason this works is because when a local client contacts an external server, it sends out an outgoing TCP connection request. The NAT gateway gets to see that outgoing TCP packet, and from the data in the packet header, the NAT gateway can glean the information it needs to make an entry in its mapping table.

In contrast, when a local machine listens for incoming connections, it is a passive operation. It doesn’t generate any packets or otherwise cause any activity that could allow the NAT gateway to work out what it was required to do. Even supposing the NAT gateway was able somehow to make the required mapping, external clients still couldn’t connect to that service without knowing the correct public IP address and port number to use.

Accordingly, we have two problems to solve. The local machine has to inform the NAT gateway of its desire to receive incoming connections, and then, having made a port mapping, it has to place that information somewhere external clients can get at it, so that they know which address and port number they should use to access the service.

The public place to store the service information, you should not be surprised to hear, is the global DNS system, using DNS-UL. The public address is stored in an address record, and the port number is stored in an SRV record describing the service.

Before the local machine can perform a Secure DNS Dynamic Update to update its address record to give the NAT’s public IP address, it first has to find out what that address is. It does this by—simply enough—asking the NAT gateway. The local machine sends a UDP request packet to port 5351 of its default gateway address. This protocol is only designed for the usual case where the NAT gateway is the one-and-only gateway on a small, single-subnet home network. The UDP packet contains two bytes of data. The first byte is the protocol version (currently 0) and the second byte is the opcode. Opcode 0 requests the public IP address.

Every packet used in the NAT Port Mapping Protocol starts with an eight-bit version followed by an eight-bit operation code. Opcodes 0-127 are used for client requests and opcodes 128-255 are used for the respective corresponding responses from the gateway. Responses also always contain two additional fields: a 16-bit result code in network byte order with success represented by a response code of 0, and a “seconds since reboot” field. Clients use the “seconds since reboot” field to detect if the gateway crashes, is power-cycled, or otherwise restarted. If this happens, your typical NAT gateway will completely forget any mappings it may have created (yet another of the many shortcomings of NAT gateways), so this is a valuable hint to tell clients that they should reissue all their mapping requests to recreate their mappings.

If, after 250 ms, the client has not received a response from the gateway device, it should reissue its request. In the absence of a response, this process is repeated, with the interval doubling each time until either a response is received or two minutes have passed. If two minutes passes without a response, then the client can conclude that this gateway does not support NAT port mapping protocol.

The first byte of the response is again 0 for the version and, this time, the second byte is 128, the response code corresponding to request code 0. The next two bytes contain the result code and the final four bytes contain the public IP address. The possible result codes are:

If the result code is nonzero, the value stored in the public IP address field is undefined and must be disregarded by the client. In the future, other error codes may be added; any unknown nonzero result must be treated by the client as a permanent error.

NAT gateways often obtain their public IP address through DHCP or some other method that does not guarantee it will remain the same. If the public IP address changes, local machines will need to know to update their DNS records to show the new address. To let them know this, when its public IP address changes, the NAT gateway alerts devices on the local network by sending a series of gratuitous opcode 128 response packets to the all-hosts link-local multicast address 224.0.0.1 on port 5351, giving the new public IP address. This notification is sent 10 times, with an interval between the first two notifications of 250 ms and, as before, the interval between subsequent notifications doubling.

Once the client has determined its public IP address, the next step is to request a public port number at this public address, to be used to receive inbound connection requests. The client initiates a request for a mapping by sending a UDP request packet to port 5351 on the default gateway, with the following format:

As before, the client sends the request and waits for a response. If no response is received within 250 ms, the request is sent again. The client repeats this process with the interval between attempts doubling each time until either a response is received or until two minutes after the first request was sent. If no response is received in two minutes, an error message should be logged and the client should stop issuing requests.

The response from the NAT device looks very similar to the request sent by the client behind the NAT.

The client should begin trying to renew the mapping halfway through the actual lifetime. The renewal packet is identical to the initial request packet, except that the fifth field, which contains the requested public port, is set to the actual port number that was allocated, rather than the port number the client may have originally requested (if different). Making the renewal packet identical to a request packet has a couple of useful properties. If the NAT gateway response to the first request packet is lost, then the client’s retransmission of the request packet looks, to the NAT gateway, just like a renewal and is handled correctly. Conversely, if the NAT gateway crashes or is rebooted, then the client’s renewal packet looks, to the NAT gateway, just like a brand new request. Since the client is requesting the same previously assigned public port number, the NAT gateway ends up re-creating the lost mapping. This makes the protocol self-healing in the face of packet loss and gateway reboots.

If the request to destroy a mapping is unsuccessful, the result code in the response is not zero. One example might be that the client attempts to delete a permanent port mapping manually configured by the human operator. In this case, the response code is 2 to indicate the request is not authorized.

If a mapping is successfully destroyed, the response packet has a result code of 0, contains the private and public ports of the destroyed mapping, and has a lifetime of 0. In the event that a NAT device receives a request to destroy a mapping that does not exist, it issues a response as if an actual mapping were successfully destroyed. This also is to guard against packet loss. For example, suppose the NAT gateway receives a mapping deletion request and successfully deletes the mapping, but the response packet is lost. When the client retransmits its request, not knowing the mapping was actually successfully deleted already, the NAT gateway needs to send it a “no error” successful response to assure it that the mapping was, as it requested, successfully deleted.