Linux 4 All: Linux DNS

How DNS load balancing works

When the request comes to the DNS server to resolve the domain name, it gives out one of the several canonical names in a rotated order. This redirects the request to one of the several servers in a server group. Once the BIND feature of DNS resolves the domain to one of the servers, subsequent requests from the same client are sent to the same server.

DNS load balancing implementation (Multiple CNAMES)

This approach works for BIND 4 name servers, where multiple CNAMES are not considered as a configuration error. Assuming there are 4 web servers in the cluster configured with IP addresses 123.45.67.[1-4], add all of them to the DNS with Address records (A Names) as below. The srv[1-4] can be set to any name you want, such as foo[1-4], but should match the next step.

srv1 IN A 123.45.67.1
srv2 IN A 123.45.67.2
srv3 IN A 123.45.67.3
srv4 IN A 123.45.67.4

Add the following canonical names to resolve www.domain.com to one of these servers.

www IN CNAME srv1.domain.tld.
IN CNAME srv2.domain.tld.
IN CNAME srv3.domain.tld.
IN CNAME srv4.domain.tld.

The DNS server will resolve the www.domain.com to one of the listed servers in a rotated manner. That will spread the requests over the group of servers.

Note: The requests sent to http://domain.com (without 'www') should be forwarded to http://www.domain.com in this case to work. For BIND 8 name servers, the above approach will throw an error for multiple CNAMES. This can be avoided by an explicit multiple CNAME configuration option as shown below.

options {
multiple-cnames yes;
};

DNS load balancing implementation (Multiple A Records)

This above approach with multiple CNAMES for one domain name is not a valid DNS server configuration for BIND 9 and above. In this case, multiple A records are used.

www.domain.tld. 60 IN A 123.45.67.1
www.domain.tld. 60 IN A 123.45.67.2
www.domain.tld. 60 IN A 123.45.67.3
www.domain.tld. 60 IN A 123.45.67.4

The TTL value should be kept to a low value, so that the DNS cache is refreshed faster.

Other considerations

The DNS based load balancing method shown above does not take care of various potential issues such as unavailable servers (if one server goes down), or DNS caching by other name servers. The DNS server does not have any knowledge of the server availability and will continue to point to an unavailable server. It can only differentiate by IP address, but not by server port. The IP address can also be cached by other nameservers, hence requests may not be sent to the load balancing DNS server.

Considering the functionality, the round robin DNS is not a load balancing mechanism but a load distribution option. Some of these drawbacks can be overcome by implementing an advanced version of the DNS load balancer using Perl scripts. The details can be found here.

Some other variety of load balancing can be performed by using a proxy server, where one of the web servers, is solely used for re-routing of traffic to the other servers. If Apache is used as a web server, the mod_rewrite feature of Apache can be used for this purpose as detailed in this Apache website article.

Load Sharing with Round Robin DNS:

One of most common implementations of DNS is the Berkeley Internet Name Domain (BIND). This allows address records (A records) to be duplicated for a specific host, with different IP addresses. The name server then alternatively rotates addresses for any one name that has multiple A records, and is known as DNS round robin.
As an example, your company has three web servers. Their real names and IP addresses are as follows:

www.yourcompany.com	128.1.1.1
www.yourcompany.com	128.1.1.2
www.yourcompany.com	128.1.1.3

You want to set up the servers so that DNS requests by clients (in this case, web server access) are round robin rotated. This is accomplished by placing multiple A records in the authoritative name server files.
For the above example, we want all clients to access our site by using www.yourcompany.com, but we want these requests to be shared between our three servers using DNS round robin. To do so, we need to place the following A records in the name server file:

www.yourcompany.com.	IN	A	128.1.1.1
www.yourcompany.com.	IN	A	128.1.1.2
www.yourcompany.com.	IN	A	128.1.1.2

Note the '.' after the name www.yourcompany.com on each A record. This is mandatory.
A Time To Live (TTL) field is often added to the A records. The TTL value is the maximum time that the information should be held to be reliable. By setting the TTL to a fairly small amount time e.g. 60 seconds, the effectiveness of the distribution can be maximized. A lower value may be specified, but this causes more DNS traffic in updates, which improves the load sharing on the web servers at the expense of increasing the local on the name server.

www.yourcompany.com.	60	IN	A	128.1.1.1
www.yourcompany.com.	60	IN	A	128.1.1.1
www.yourcompany.com.	60	IN	A	128.1.1.1

When a DNS request for an IP address is received, BIND returns one of the IP addresses and makes a note of it. The next request will then return the next IP address in the file and so on until the last one, after which BIND returns to the first address again.

Advantages of DNS Round Robin:

An obvious advantage of using DNS Round Robin for load distribution is that it is seamless to the user. It is also simple and cost-effective to implement. It is standard software in most systems or else may be obtained at no or low cost. For this reason, it is very effective for small to medium size businesses or organisations and it is extremely popular among ISPs, e-commerce sites, universities and other cost sensitive sites.

Disadvantages of DNS Round Robin:

It should be noted that DNS is a load sharing mechanism rather than a load balancing mechanism. It does not gauge the "load" on the server in any way, but rather it shares the load among multiple hosts. One or more of the hosts in the pool will tend to get more activity than the other servers. DNS Round Robin should be quite effective up to about 10 servers per virtual cluster.
DNS has no way of detecting physical failure e.g. when the hard disk on server2 (www2) fails. As requests come in for www.yourcompany.com, the DNS will continue to forward one out of every three requests to www2 - which will fail. Effectively, 33% of all requests to www.yourcompany.com are now connecting to a black hole. This is an improvement over having just one web server and having all the requests being lost due to a hardware failure, but only to a certain degree.
It is very common for a computer to request data from the same host several times in any given session. It is also common for many hosts from the same site to make requests from the same servers. Usually, these requests are made to a local name server that in turn ask another name server for the resolution of the domain. In order to minimize network traffic these responses are cached - possibly on each name server along the way. This helps the network to respond quickly with domain name resolution, but it can also defeat the round-robin load distribution.
However, this caching problem may be resolved by using the TTL value. The protocol requires that local and intermediate DNS servers dump these entries from their cache when the TTL runs out. Most systems, such as Solaris, NT and Linux (and others) support BIND 4.9 and later versions. DNS round robin supports pools of servers for any applications, not just web servers. Pools of web, email, ftp, database and other servers can all be setup to load share using DNS.

Dynamic Load Balancing DNS: dlbDNS

Another approach to solving the problem of network traffic congestion is to add a dynamic load balancing feature to the existing DNS.
Distributing a request across servers can be implemented by monitoring the servers regularly and directing the request dynamically to the 'best server'. This way of dynamically directing a request across multiple servers based on the server load is called dynamic load balancing. This feature can be added to the pre-existing DNS, as it already plays a prominent role in resolving client requests and can be configured to direct client requests across multiple servers in an effort to avoid network traffic congestion. Here, the 'best server' refers to the server with the best rating, based on a rating algorithm.
There are several load balancing models available. The model implemented by dlbDNS is an internal monitoring system, that monitors the performance of the servers and provides feedback to the DNS. It is easy to maintain and administrate. Other advantages include closeness to the source of addressable problems and no security hazards.
As there are several load balancing models available, there are also a number of load balancing algorithms available. The rating algorithm implemented in dlbDNS, which determines the best server, is based on the number of users and load average shown. The algorithm is reasonable, as it favors the host(s) with the smallest number of unique logins and lower load averages.
The Server-Side Algorithm is added to the pre-existing DNS feature. During configuration, a new attribute called DNAME is added to distinguish the hosts taking part in dynamic load balancing. If the service requested is of type DNAME, do the following:

Determine the set of participating servers for this service
Request ratings from all participating servers by establishing a concurrent connectionless (UDP) connection with each server
Using the ratings returned, determine the best server
Handle error conditions such as:

Server is too busy to return the rating within the time frame
The rating returned by the server gets lost on its way back to the dlbDNS
All servers have same rating
A server is down

A Rating Demon Algorithm is run on each server taking part in dynamic load balancing and is as follows:

Receive request for rating from dlbDNS and respond by returning the host rating
Calculate the host rating once every minute rather than calculating it at the time of request, as quick response time is a most important factor
Ensure the host rating is updated every minute, independent of the dlbDNS request
Handle error conditions such as dlbDNS closing the UDP sockets without waiting for host response

Implementation of the dlbDNS provides efficient utilization of system resources and ensures that facilities newly added to the existing network will be utilized. Since DNS is used, applications such as FTP and TELNET will also utilize dlbDNS.
See figure: dlbDNS This dlbDNS algorithm was proposed by the Computer Science department of Wichita State University, due to the uneven distribution of load across the servers thus causing major problems for the department. It should be noted that there is further work to be done on this approach. In particular the rating algorithm is incomplete. An algorithm that takes into account the number of processors, CPU and memory utilization would make the rating algorithm more efficient. Also, a more extensible design is needed, as Linux servers are the only servers that can participate in the dynamic load balancing scheme.

Conclusion:

The most common implementation of DNS load sharing is most certainly the DNS Round Robin technique. It is very feasible for small to middling companies and organizations. However, it is not sufficient for larger organizations and they should probably take into account other load balancing sc

BIND 9 External and Internal DNS Information

How do I configure Bind 9 dns server views to allow a single nameserver in my DMZ to make different sets of data available to different sets of clients? For example, I'd like to run recursion, some other data for LAN users (192.168.1.0/24), and for the Internet user I'd like to display limited DNS data without recursion. How do I configure views to partition external (Internet) and internal (LAN) DNS information?

You need to edit /etc/named.conf or /var/named/chroot/etc/named.conf file, run (the following configuration is tested on FreeBSD and RHEL 5.x BIND 9 servers):
# vi /var/named/chroot/etc/named.conf
Append the following and define internal subnet (192.168.1.0/24 and localhost with full access and recursion):

acl internal {
   192.168.1.0/24;
   localhost;
};

Define zone and other data as per your requirements:

//
// Lan zone recursion is the default
//
view "internal-view" {
  match-clients { internal; };
  zone "." IN {
    type hint;
    file "db.cache";
  };
  zone "internal.nixcraft.com " IN {
    type master;
    file "zones/lan.master.nixcraft.com";
    allow-transfer { key TRANSFER; };
  };
};
//
// external zone w/o recursion
//
view "external-view" {
  match-clients { any; };
  recursion no;
  zone "nixcraft.com " IN {
    type master;
    file "zones/internet.master.nixcraft.com";
    allow-transfer { key TRANSFER; };
  };
};

Make sure you configure TSIG as described here.

Create Zone Files

First, create required directories, enter:

# mkdir -p /var/named/chroot/var/named/zones

# chown named:named /var/named/chroot/var/named/zones

Create Internal Zone With LAN IP Data

Edit /var/named/chroot/var/named/zones/lan.master.nixcraft.com, run:
# vi /var/named/chroot/var/named/zones/lan.master.nixcraft.com
Append the data, enter:

$ORIGIN nixcraft.com.
$TTL 3h
@        IN SOA ns1.nixcraft.com. vivek.nixcraft.com. (
                       20080703328        ; Serial yyyymmddnn
                       3h                ; Refresh After 3 hours
                       1h                ; Retry Retry after 1 hour
                       1h                ; Expire after 1 week 1w
                       1h)             ; Minimum negative caching of 1 hour

@                          IN NS    ns1.nixcraft.com.
@                          IN NS    ns2.nixcraft.com.

@                      3600 IN MX 10 mail1.nixcraft.com.
@                      3600     IN MX 20 mail2.nixcraft.com.

@                      3600    IN A     208.43.79.236
ns1                    3600    IN A     208.43.138.52
ns2                    3600    IN A     75.126.168.152
mail1                  3600    IN A     208.43.79.236
mail2                  3600    IN A     67.228.49.229
out-router             3600    IN A     208.43.79.100
; lan data
wks1                   3600    IN A     192.168.1.5
wks2                   3600    IN A     192.168.1.5
wks3                   3600    IN A     192.168.1.5
in-router              3600    IN A     192.168.1.254
; add other lan specifc data below

Edit /var/named/chroot/var/named/zones/internet.master.nixcraft.com, run:
# vi /var/named/chroot/var/named/zones/internet.master.nixcraft.com
Same as above but no internal data:

$ORIGIN nixcraft.com.
$TTL 3h
@        IN SOA ns1.nixcraft.com. vivek.nixcraft.com. (
                       20080703328        ; Serial yyyymmddnn
                       3h                ; Refresh After 3 hours
                       1h                ; Retry Retry after 1 hour
                       1h                ; Expire after 1 week 1w
                       1h)             ; Minimum negative caching of 1 hour

@                          IN NS    ns1.nixcraft.com.
@                          IN NS    ns2.nixcraft.com.

@                      3600 IN MX 10 mail1.nixcraft.com.
@                      3600     IN MX 20 mail2.nixcraft.com.

@                      3600    IN A     208.43.79.236
ns1                    3600    IN A     208.43.138.52
ns2                    3600    IN A     75.126.168.152
mail1                  3600    IN A     208.43.79.236
mail2                  3600    IN A     67.228.49.229
out-router             3600    IN A     208.43.79.100

Finally, reload data:
# rndc reload
Test it, enter:

$ ping in-router.nixcraft.com

$ ping out-router.nixcraft.com

dns tips while configuring

Just sharing some DNS tips, which needs to keep on mind while configuring your DNS server.

1. An A Record must ALWAYS contain IP address (map host to IP)

Whenever you specify A record it must contain IP address on the Right side. The A record is so important in DNS without which the meaning of mapping hostnames to IP would be absurd. So remember this!

2. CNAME (Alias) must contain hostnames. No IPs here

3. NS an MX records must contain host names. No IPs allowed.

4. Use the DOT in the end, whenever you specify a domain name in the DNS zone file. This DOT is so important and if you forget this you will have nightmares with your dns configuration.
For example
example.com. IN NS ns1.example.com.

Why DOT? simply because it tells to start query from root servers (denoted by dot)

5. MX records (for mail servers) should contain hostnames NOT IPs.

6. Allow Port 53 for both UDP and TCP connections
If you use firewall make sure you do not block port 53 for DNS tcp and udp requests. By default dns lookups use UDP protocol while zone transfers and notifications use TCP protocol of port 53.
-Port 53 UDP = Dns Requests
-Port 53 TCP = Zone transfers

7. CNAMEs cannot co-xist with MX hosts.
Do not specify CNAME or aliases pointing to MX records.

domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ----------> WRONG

Instead use A record to map directly to IP address.

mail IN A 11.33.55.77 ---> CORRECT

8. No duplicate MX records
domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com ----> DUPLICATE

In case if some information provided above is incorrect, please feel free to update me.
Will surely add more tips & tricks in the coming future.

Latest Posts

DNS Configuration in RHEL 5

Round Robin DNS Load Balancing