In this two-part blog post, I will talk about the Global Server Load Balancing (GSLB) feature provided by the NetScaler.
In Part 1, let’s examine DNS name resolution process, as GSLB is DNS based load balancing. In Part 2, we will take a look at implementation details on the NetScaler.
Name Resolution Process
Recursive DNS Query
Let’s assume that a MAC is connected to a network and subsequently obtains an IP address and DNS server information via DHCP, as shown below.
Open up Chrome and browse to ‘http://www.google.com’.
The browser firstly looks up its built-in DNS cache, looking for an existing entry for hostname ‘www.google.com’.
Chrome’s built-in DNS cache can be viewed by entering ‘chrome://net-internals/#dns’ at the address bar.
If an existing entry exists and is not expired.
DNS ends. Whatever happened afterwards, is DNS irrelevant.
For demonstration purposes, assuming that an entry for ‘www.google.com’ didn’t exist in cache.
Chrome’s built-in DNS client (a separate DNS client to the one built into the OS), shown below, enabled by default, makes a recursive DNS query to the Upstream DNS server, resolving ‘www.google.com’
The following trace captures that DNS traffic.
The first packet sourced from 192.168.1.3 (Mac) and destined to 8.8.8.8 (Upstream DNS), is a recursive query, asking for associating IP for Address (A) Record ‘www.google.com’.
The second packet in the reverse direction, is a DNS response, containing associating IP addresses.
For a recursive query, the DNS server MUST either return the associating IP(s) for the A Record, or informing that the A Record does not exist.
There MUST NOT be any other forms of responses. E.g. I don’t know, ask someone else.
The above response is a valid DNS response, however, not valid in the context of answering a recursive DNS query.
The above concludes DNS resolution process between the Mac and its Upstream DNS server.
Iterative DNS Query
What happens at the Upstream DNS server upon receiving a recursive query from the Mac?
Firstly it checks against its own DNS cache and see if there is an existing entry, that is, is there a fresh (not expired) entry for ‘www.google.com’.
Note: the freshness of a cache entry is determined by examining how many seconds an entry has been in cache and how long the TTL (time-to-live) of that record is set to. If the lifetime of an entry > TTL, entry is expired, warrant a lookup by the DNS server. Otherwise an entry is fresh.
If the DNS cache has a fresh entry for ‘www.google.com’, associating IP(s) for A Record ‘www.google.com’ is returned to Mac immediately, in response to the prior recursive DNS query.
If the DNS cache does not have a fresh entry for ‘www.google.com’. The DNS server needs to find out the answer itself. With a Recursion Enabled DNS server, it generates iterative DNS queries over this process.
For demonstration purposes, assuming that no fresh entry exists within DNS cache.
Note: For following analysis, 192.168.1.3 is the DNS server.
Packet #3 shows that 192.168.1.3 (DNS server) forwards the query it received from Mac to 192.33.4.12
Why 192.33.4.12?
Because a DNS server supporting recursion, must send a DNS query to what’s called a ‘Root Name Server’.
There are 13 Root Name Servers in the world.
The IP addresses of the Root Name Servers hardly change and the list of Root Name Servers is programmed into the DNS server application.
The DNS server makes an arbitrary selection from the list of available Root Name Servers, and in this particular case, 192.33.4.12.
Packet #4 (below) is the DNS response from Root Name Server 192.33.4.12.
It says, ‘sorry mate, I don’t know what www.google.com is, but I know the Name Servers that are responsible for .com domains have the answer, and by the way, these are the IP(s) for them.
Packet #5 shows that 192.168.1.3 (DNS server) forwards the same DNS query to 192.52.178.30.
Why 192.52.178.30?
Because the DNS server makes an arbitrary selection from the list of Name Servers responsible for .com domains. It doesn’t matter which Name Server it asks, hence arbitrary.
Note: The Name Servers that are responsible for a domain (e.g. .com) are called Authoritative Name Server. .com domain is a top level domain, the FQDN of those Name Servers included ‘gtld’, meaning ‘Generic top-level domain’. The above process is known as a DNS referral, because the Root Name Server does not return an ‘Answer’ section in its response. Only ‘Authoritative nameservers’ and ‘Additional records’ sections are included in the DNS response. The above process also involves a delegation, that is, .com domain is delegated to the .com Authoritative Name Server, by the Root Name Servers.
Packet #6 is a DNS response from 192.52.178.30.
It says, ‘I don’t have an answer for you mate, please ask the four Authoritative Name Servers for google.com subdomain. By the way, these are the IP addresses for them’.
Again, this is a referrer and delegation occurs on google.com Authoritative Name Servers.
Packet #7 shows that 192.168.1.3 (DNS server) forwards the same query to 216.239.36.10, after an arbitrary selection from the available four.
Packet #8 shows that it finally gets an answer.
As shown, this DNS resolution process is vastly different from what happened between the Mac and the Upstream DNS server. The difference is due to that the former involving a recursive DNS query, and the latter involving iterative DNS queries.
In summation, the following diagram captures the entire name resolution process.
How does GSLB fit in?
Assuming that the Authoritative Name Servers for google.com subdomain (relative to .com domain), instead of giving out the IP(s) in the ‘Answer section’ of its response, but says ‘I don’t know the answer, please go and ask the Authoritative Name Servers for www.google.com subdomain (relative to google.com), and by the way, these are their IP(s).’
The DNS server will then send the same iterative DNS query to an arbitrarily selected Authoritative Name Servers for www.google.com subdomain, and imagine they are hosted on the NetScaler(s). In this case the NetScaler(s) would be Authoritative Name Servers for www.google.com subdomain, effectively performing GSLB.
In order to achieve the above, two things must be done.
- Configure subdomain delegation on the Authoritative Name Servers for google.com domain.
- Setup ADNS (Authoritative DNS) service on the NetScaler(s), so it is acting Authoritative DNS servers for the GSLB subdomain.
Regarding point one, in the case of BIND name server (mostly widely used), the following extra configuration is needed.
It says for query involving ‘www.google.com’, talk to Authoritative Name Server dns1.gslb.google.com or dns2.gslb.google.com.
dns1.gslb.google.com is an A Record and the IP for that A Record is x.x.x.x; dns2.gslb.google.com is an A Record and the IP for that A Record is y.y.y.y
The above, in essence, is a delegation, entailing identical processes, shown earlier, by packet #4 and #6.
Regarding point two, assuming there are two NetScaler(s), we create an ADNS service on each NetScaler, with IP(s) x.x.x.x and y.y.y.y respectively.
The following diagram shows the name resolution process with GSLB involved.
Once the delegation is completed, the NetScaler is now acting Authoritative DNS Server for www.google.com subdomain, and DNS queries for ‘www.google.com’ will then arrive and be answered.
Please note that the DNS resolution process described above is universal. E.g. The same process applies to NetScaler’s implementation of GSLB and F5’s implementation of GTM, etc.
In part two, we will look at specific NetScaler configuration required for GSLB to work.
