Load Balancing DNS at Layer 7

The final Layer 7 load-balancing example we'll consider is DNS. In Chapter 2, we saw that DNS can be either TCP or UDP based, although for the purposes of this discussion we will look at the UDP-based model more typically used for the request-response mechanism of resolving domain names within the Internet. While the primary reason for implementing a load balancing solution for DNS is the resilience of having more than one server, for some instances, such as ISP infrastructures and the root name servers for the Internet, sheer volume of traffic can also represent a problem. The UK-based root name server, "K" ( http://k.root-servers.org ) handles somewhere in the region of 4000 DNS requests every second at peak periods. At the time of writing, this is handled by three physical servers operating as a single cluster. Adding the intelligence to be able to deal with DNS requests based on the host or domain information means increased flexibility for large-scale DNS infrastructures.

The other advantage of using Layer 7 based DNS load balancing is that it offers the ability to deal with a problem known as "Split DNS."

Before we look at some deployment examples for DNS load balancing at Layer 7, let's look again at the nature of a DNS request. The following code shows a standard DNS request, in this case for www.foocorp.com, sent by a client machine. When we refer to DNS load balancing at Layer 7 it is specifically the parsing of the Name field in the Query section of the request. Using this information, the content switch can match the variables in this field against the regular expressions and text strings assigned to each real server and forward the UDP-based request to the correct server.

 Domain Name System (query)     Transaction ID: 0x0b84     Flags: 0x0100 (Standard query)         0... .... .... .... = Response: Message is a query         .000 0... .... .... = Opcode: Standard query (0)         .... ..0. .... .... = Truncated: Message is not truncated         .... ...1 .... .... = Recursion desired: Do query recursively         .... .... ...0 .... = Non-authenticated data OK:     Questions: 1     Answer RRs: 0     Authority RRs: 0     Additional RRs: 0     Queries         www.foocorp.com: type A, class inet             Name: www.foocorp.com             Type: Host address             Class: inet 

The main difference from the other Layer 7 examples we've seen so far for things like HTTP and FTP is that DNS request/response traffic for resolving Internet names is typically UDP rather than TCP based. This effectively reduces some of the overhead on the content switch, as it removes the need to perform a delayed binding between the client and the server in order to parse for the Layer 7 information. In a UDP-based DNS query, the Layer 7 information is available in the first frame.

Applications of Layer 7 DNS Load Balancing

As a UDP-based service, layer 7 DNS load balancing has some less obvious applications in the network. Let's take a look at how intelligent DNS load balancing can provide some advantages.

1. Providing Large Scale DNS Infrastructure

The first example of implementing Layer 7 DNS load balancing is very simple ”provide more intelligent distribution of UDP-based DNS requests into a DNS server farm. By using the ability to parse the Name field of the DNS query, client requests can be distributed based on the domain name being requested . This might take the form of using the first letter of the domain name, such as www. f oocorp.com, defined by regular expressions, or by using the top-level domain as a mechanism, such as www.foocorp. com or www.ietf. org . Figure 6-16 shows this type of implementation in more detail.

Figure 6-16. By parsing the Name field in the DNS query, DNS requests can be load balanced effectively using string matches against the host, subdomain, or top-level domain.

2. Implementing a Split DNS Infrastructure

For many enterprises , there exists a challenge when implementing DNS services for client machines or other DNS servers that is commonly referred to as Split DNS. With many network devices to configure, it is advantageous to implement a single IP address for DNS services within the network. However, many enterprises have different requirements for internal and external DNS naming. For example, imagine two groups of resources that are used by internal clients ”one group containing internal only resources, such as intranet.internal.foocorp.com , expenses.admin.foocorp.com , and so forth, and the second containing publicly accessible resources such as www.foocorp.com and all other Internet Web sites. The enterprise will require that internal only resources are resolved using internal, privately administered DNS servers, while external resources and all other Internet domain names are resolved using DNS servers provided and managed by their ISP. Implementing these DNS resources as defined real servers on a content switch and using string definitions to direct the DNS requests to the correct internal and external DNS resources based on Layer 7 inspection allows the enterprise to deliver different, or split, DNS servers represented via a common IP address ”the VIP on the content switch. Figure 6-17 shows an overview of a Split DNS infrastructure.

Figure 6-17. Implementing a Split DNS infrastructure with content switching.

Here we see a client with a DNS server configured as the VIP 10.10.10.100. The content switch is configured with two server groups:

• Internal DNS servers: These servers handle internal names such as intranet.foocorp.com or any host in the subdomain *.internal.foocorp.com.

• External (ISP) DNS servers: These servers handle any publicly accessible *.foocorp.com resources, such as www.foocorp.com, and all other Internet domains.

When the client's request arrives at the content switch, the Name field in the request is parsed and forwarded to the correct DNS server group based on host requested.