Load Balancing & Fault Tolerance
Inbound Load Balancing and Failover (Multihoming)
contains information about top level domains such as CA, COM, EDU, GOV, NET, etc. The next level below TLD is
Second Level Domain (such as whitehouse.gov, Microsoft.com, inforamp.net, etc.) followed by Third Level Domain,
and so on.
You can apply for domains for your organization. First, go to the Internet’s Network Information Center (InterNIC) to
find out if the domain has been registered already. You can also consult the ICANN-accredited registrar database.
Second, register the domain with a registrar. You have to provide at least two DNS servers to serve DNS requests. If
your registration has been approved, then any DNS request to your domain will be forwarded to the DNS servers you
are registered with. For example, xtera.com is registered and InterNIC has put the name “xtera” into the COM DNS
servers.
Once the domain is registered, sub-domains can be created. Example: a part or the network can be named
“sales.xtera.com”. InterNIC’s approval is not required for creating sub-domains. However, it is important to put DNS
information about sales.xtera.com into the DNS servers of xtera.com.
Here is an example of how DNS hierarchy works. A user at a university sees a link to sales.xtera.com on a web page
and clicks it. The browser will ask the local DNS server dns.utexas.edu about sales.xtera.com. Suppose it is not in the
cache of dns.utexas.edu. The DNS server goes to a Root DNS server to find the DNS server for COM TLD. The DNS
server for COM TLD tells dns.utexas.edu to go to dns1.xtera.com. Finally dns.utexas.edu is given the IP address of
sales.xtera.com by dns1.xtera.com.
SwiftDNS
One of the problems with traditional DNS servers are facing is TTL. A long TTL means a long update time when IPs
have been changed. Before the update time is up (i.e. TTL is expired), DNS requests may be answered with incorrect
information. FortiWAN employs SwiftDNS for multihoming based on the health state of the link and a traffic re-
directing algorithm. SwiftDNS dynamically answers DNS requests to prevent broken or congested links. In order to
solve the TTL issue stated above, SwiftDNS maintains a very short TTL and actively sends out updates to internal
DNS in case of link status changes.
How does SwiftDNS work?
Here is an example to illustrate how SwiftDNS works. When Multihoming is enabled, SwiftDNS becomes active. In this
case, the upper level DNS server for example.com has two NS records and they are for Primary DNS server at
210.58.100.1 and Secondary DNS server at 210.59.100.1. Both of them are pointing to FortiWAN.
In this case, a web site at 192.168.100.1 in LAN is exposed to these two IPs. When both ISP links are working
properly, FortiWAN replies to DNS requests for www.example.com with 210.58.100.1 and 215.59.100.1 at ratio of 1:2
(weight ratio).
124
FortiWAN Handbook
Fortinet Technologies Inc.
