Redirector Design

Our redirector is much less complex than the Apache HTTP server. It consists of the following five parts (see Figure 3.4):

1. Replica database;
2. Redirection policy implementation;
3. DNS protocol implementation;
4. Configuration routines;
5. Communication routines.

Figure 3.4: The design of the redirector

Since the main purpose of the redirector is to provide its clients with replica addresses, a place to store them is needed: a replica database. It contains the list of service names, represented in our case by domain names. Each domain name is associated with a collection of replicas, described by their IP addresses and TTL values. Each replica can support many services. For each domain name it is possible to specify a different redirection policy. Therefore, a policy identifier is a part of the service description stored in the database.

The database is used by the heart of our redirector - the redirection policy component, which generates a list of (IP address, TTL value) pairs for the given domain. The way the list is generated is discussed in Chapter 4, where we present redirection policies.

The redirection policy component is called from and passes the results back to the DNS protocol implementation, which provides the basic functionality of a DNS server. It accepts a DNS packet and decodes it. All malformed or non-query packets are dropped. In case the packet is not a simple name-to-address query, an empty DNS response (containing an appropriate error code) is generated. Otherwise, the domain name found inside the query and the sender address are passed to the redirection policy implementation. The latter responds with a list of (IP address, TTL value) pairs, which is subsequently encoded into a DNS response packet and passed back to the caller.

The configuration routines enable the system administrator to change the default settings of redirector. These include, for instance, the number of IP addresses returned in a single DNS response and a default TTL value. They also allow to set the size limits of the replica database and its initial content. Finally, they let the administrator adjust policy-dependent configuration. The way in which all these routines are invoked depends on the software in which the redirector is going to be embedded.

The main duty of the communication layer is to receive DNS packets. Each DNS packet can be transmitted using either UDP or TCP. Therefore, the communication layer must support both of them. After a packet is received, it is passed on (in a format independent from the transport protocol) to the DNS protocol implementation. If the latter reacts with a response DNS packet, the communication layer sends it back to the sender of the original packet. Obviously, both packets use the same transport-level protocol.

Another duty of the communication layer is to support a networked maintenance interface. By means of a simple text-based protocol it enables the system administrator to modify the content of the replica database. In this way we enable the cooperation between the Apache-based DNS redirector and any external replica control program.