| The Domain Name Service (DNS) is the naming system on the Internet used by applications that require access to network resources via humanly recognizable names. Because GSLB systems can use DNS for distributed site selection, you should have a solid understanding of DNS before you tackle the load balancing concepts in this Chapter. The DNS system is a distributed hierarchical database of name-to-IP mappings. Figure 12-1 gives an example DNS hierarchy for some Cisco.com web servers. Figure 12-1. DNS Domain Hierarchy 
At the top of the hierarchy are the root name servers, as Figure 12-1 illustrates. The root servers are responsible for resolving all DNS requests on the Internet but delegate the resolution to the Top-Level Domain (TLD) servers for more specific domains. The TLD servers, in turn, delegate responsibility to intermediary DNS (IDNS) servers, which your enterprise or Internet Service Provider (ISP) may own and administer. The IDNS servers can be responsible (or authoritative) for specific domains or can further delegate resolution of subdomains to subdomain DNS servers. The subdomain servers may be responsible for one or more domain names, such as www.cisco.com. You can consider the GSLB devices in this Chapter as subdomain DNS servers. The Address (A) records reside at the leaves of the tree. In Figure 12-1, the www.cisco.com subdomain DNS server is responsible for the single subdomain www.cisco.com. The *.support.cisco.com DNS server is responsible for two domains for technical and sales support. Nonprofit organizations administer the DNS root servers. They all behave identically in terms of DNS operation but have different hardware and software requirements, depending on the load on each server. Because the round trip time (RTT) to the root servers is a cause of additional delay in Internet transactions that require name resolution, the selection of the root server is important for reducing overall transaction times. As a result, the administrators of some of the busiest DNS root servers use Border Gateway Protocol (BGP)-anycasting for site selection. With BGP-anycast, the root DNS server is replicated across numerous sites, and the IP prefix of the server is advertised into BGP from each location. The BGP routing algorithm is then able automatically to select the best site for user requests on the Internet. Introducing DNS Resource Records A DNS server maintains configuration files that contain the resource records (RRs) for domains they are authoritative for. As an example, the IDNS server for *.cisco.com may contain the following resource records: Start of Authority (SOA), Address (A), Name Server (NS), and Mail Exchange (MX). Start of Authority (SOA) Records The DNS servers that are authoritative for a particular subdomain contain a Start of Authority (SOA) record. Example 12-1 gives a sample SOA record for the domain cisco.com that would reside on the intermediary DNS server for *.cisco.com. Example 12-1. A Sample SOA Resource Record CISCO.COM. IN SOA ns1.cisco.com. ns2.cisco.com. ( 1 ; serno (serial number) 86400 ; refresh in seconds (24 hours) 7200 ; retry in seconds (2 hours) 2592000 ; expire in seconds (30 days) 345600) ; TTL in seconds (4 days)
|
In the SOA record in Example 12-1, "IN" refers to the class of record. DNS currently supports only the Internet (IN) class. The type is SOA, and the primary and secondary authoritative intermediary DNS servers for the domain are ns1.cisco.com and ns2.cisco.com, respectively. These two name servers can both actively respond to DNS requeststhe secondary remains synchronized with the primary by requesting zone transfers from the primary. Zone transfers contain all the available records on the primary DNS server. The SOA also contains the following: - Current version (serial number) of the data file - Number of seconds that the secondary name server should wait before checking for updates on the primary name server - Number of seconds a secondary name server should wait before retrying a failed zone transfer - Maximum number of seconds that a secondary name server can use data before it must either be refreshed or expire
The Time-to-Live (TTL) value enables you to specify the default amount of time that client DNS servers, when using iterative DNS, locally cache the A record responses. If you use recursive DNS, as you will learn in the next section, all DNS servers have access to the A record response and may cache the A record locally for subsequent requests. Although each domain should be identified by two DNS servers, with one as the active DNS server and the other as the backup, the examples in this Chapter reference only a single authoritative server for each subdomain. Address (A) records A records define the association between each domain and IP address that your device is authoritative for. An example of an A record for Cisco.com is cisco.com. 3600 IN A 10.1.10.100 In this resource record, the rightmost "." in the domain name indicates the root server; .com indicates the TLD server, and cisco.com refers to the authoritative domain containing all *.cisco.com subdomains. The www refers to the subdomain that your device is authoritative for. You can override the TTL value in the Start of Authority (SOA) record by specifying the TTL after the domain in the A record. The "A" refers to the type of record. Name Server (NS) records DNS servers delegate authority to other DNS servers by using NS records. An example NS record for the domain Cisco.com, thus delegating the domain to the subdomain DNS server gslb.cisco.com, is www.cisco.com. IN NS gslb.cisco.com The A record to determine the IP address of the GSLB DNS server is gslb.cisco.com. IN A 10.1.10.101 An NS record is also known as a referral record, because it refers client DNS servers to other DNS servers that are delegated to resolve more specific TLDs or subdomains. Mail Exchange (MX) records MX records are the mail server domains that the DNS server is responsible for. An example MX record for the e-mail domain user@cisco.com is cisco.com. IN MX smtp.cisco.com The A record to determine the IP address of the mail server is smtp.cisco.com IN A 10.1.10.103
Note DNS uses UDP port 53 for standard DNS requests and responses. However, because zone transfer payloads are much larger, they require TCP (also on port 53) as a reliable transport.
Iterative DNS With iterative DNS resolution, each server delegates the resolution responsibility to the next-level DNS server down the hierarchical tree you learned about previously in Figure 12-1. The DNS servers in the flow send an NS-record containing the next-level DNS server closer to the authoritative DNS server, as Figure 12-2 illustrates. Figure 12-2. Iterative DNS 
Note The Internet uses the iterative method for DNS resolution. The iterative method is beneficial in GSLB environments in which the client's DNS server IP address should be preserved throughout the flow for proximity load balancing and GSLB-sticky, as you will learn later in this Chapter.
Consider the example from Figure 12-2 in which a client issues an A record request for Cisco.com. The client browser sends the A record request to the operating system. The operating system first checks its local hosts file for the requested A record. The hosts file is a text file to which you can manually add A records on your workstations or servers. If the host file contains the record, the client uses the entry for the connection. Additionally, if the client requested the same mapping in the recent past, the operating system may have a cached copy of the host-to-IP mapping in a local DNS cache. If so, the client uses the cached IP address for the connection. Otherwise, the client DNS server forwards the request recursively to the client DNS server. You can configure your local DNS server(s) either manually or dynamically via a Dynamic Host Control Protocol (DHCP) server. Note In iterative DNS, clients send requests to their configured DNS server as recursive requeststhe DNS server initiates and coordinates the iterative DNS flow. See the next section for more details on recursive DNS.
The local DNS server checks for a cached copy of the A record and responds directly to the client with the mapping, as a nonauthoritative answer. If it does not have a cached copy of the requested A record, the DNS server issues an iterative A record request to a root server, on behalf of the client. The root name server responds to the client DNS server with the NS-record of the *.com TLD server. Note You configure the list of root name servers and their IP addresses on the name server. Because the root servers change infrequently, maintaining a static list of root name server IP addresses is a trivial task that you can perform manually.
The client DNS server then extracts the TLD IP address from the NS-record response and formulates another A record request, which it sends to the TLD server. The TLD server responds with the NS record of the *.cisco.com IDNS server to the client DNS server. The client DNS server sends an A record request to the *.cisco.com IDNS server. The *.cisco.com IDNS server responds with the NS record for the subdomain DNS name server authoritative for www.cisco.com. The client DNS server sends the A record request to the subdomain DNS server. The subdomain DNS name server responds with the A record of the domain. To improve performance and reduce delay, the authoritative subdomain DNS server includes a TTL value in the A record response to the client DNS server. The client DNS server stores the A record in its cache for the length of time specified by the TTL. The client DNS server sends the A record back to the client. The client uses the IP specified in the A record for the TCP connection of the HTTP session to the Cisco.com web server.
Note In Figure 12-2, the root and TLD DNS servers never see the A record response from the subdomain DNS servers. Therefore, using iterative DNS resolution, they cannot cache a copy of the A record locally.
Recursive DNS With recursive DNS resolution, each server assumes responsibility of the resolution, in contrast to iterative resolution in which each DNS server passes the resolution responsibility to another DNS server. When a client sends an A record request for an IP address, recursive DNS requires that each DNS server in the hierarchy resolves the host name. When a recursive DNS server receives an A record request, it issues an A record request of its own to a server delegated to the domain at the next level down the DNS tree. This process continues until the request reaches the server authoritative for the domain, as Figure 12-3 illustrates. Figure 12-3. Recursive DNS 
Consider an example of a user attempting to connect to Cisco.com from a web browser on the Internet. The client checks for the A-record in its cache and hosts file. The operating system sends the request in the form of a standard DNS A record request to its local DNS server, if the entry is not in its host file or cache. The local DNS server checks for a cached copy of the A record and responds directly to the client with the mapping, as a nonauthoritative answer. If it does not have a cached copy of the requested A record, the DNS server issues a recursive A record request to a root server, on behalf of the client. If the root server has a cached copy of the requested A record, it sends the answer to the client's DNS server. Otherwise, the root server issues an A record request to the name server that is authoritative for the TLD of *.com. The TLD server checks for a cached copy of the mapping but sends the request to the iterative DNS server authoritative for cisco.com if the cache does not contain the mapping. In this example, the iterative DNS server contains the A record for www.cisco.com. The responses ripple backward as DNS A record answer packets, in the reverse direction to which the requests arrived at the www.cisco.com name server. Now that the application knows the IP address, it can open a TCP connection directly to the web server, to make an HTTP request for content.
Note The Internet does not use the recursive DNS method for name resolutionthis example is for illustration purposes only.
|
