Summary
The DNS system is considered as a distributed database which uses the Client/Server architecture. Name Servers are the servers in the architecture, and the resolvers are the clients that are typically library routines installed on an operating system that create and send queries across the network.
The logical hierarchy of the Domain Name Service (DNS) is shown in the following diagram:
Note: The second level root servers are responsible for maintaining Name Server > Address mappings for Name Server delegations within the .com, .net, .org, .gov (and so on) domains. Subsequently, each domain within the second level domains is responsible for maintaining Name Server > Address mappings for the lower level organizational domains. Once you get to the organization level, you start to get into individual host address resolution for www, ftp, and other service providing hosts.
Delegation
The main purpose of the current DNS topology is to ease the burden of maintaining all address records on one authority. This allows for delegation of an organization name space to that particular organization. The organization can then further delegate its space to sub-domains within the organization. Examples of this could be citrix.com creating sub-domains called sales.citrix.com, education.citrix.com, and support.citrix.com. The corresponding departments could then maintain their own set of Name Servers that are authoritative for their sub-domain, and subsequently maintain their own set of host name to address mappings. No single department is responsible for maintaining all of Citrix address records, and each department could seamlessly change addresses and modify topologies in a seamless manner, and not impose additional work at the higher level domain/organization.
Benefits to the Hierarchical Topology
Other benefits incurred from this topology include scalability, the ability to add caching functionality into Name Servers at each level, where a DNS request can be served by a host that is not authoritative for a particular domain, but can contribute the answer to the query and cut down on congestion, and response time. Caching also creates redundancy and resilience to Server failure. If one name server fails, it is still possible that records can be served from other servers that have recent cached copies of the same records.
Resolvers
As stated previously, resolvers are the client component in the DNS system. Programs that are running on a host that need information from the domain name space use the resolver. The resolver handles:
Querying a name server
Interpreting responses (which might be resource records or an error)
Returning the information to the programs that requested it.
The resolver is usually a set of library routines that are compiled into programs like telnet, ftp, and ping. They are not usually separate processes. They are only smart enough to put together a query, send it, and wait for an answer, and send it again (possibly to a secondary Name Server) if it is not answered in a sufficient period of time. These types of resolvers are known as stub resolvers. Some resolvers have the added functionality to cache records, and honor time to live (TTL). In Windows, this functionality is available through the DNS Client service; viewable through the services.msc console.
Name Servers
Name Servers generally store complete information about a particular part of a domain name space (called a zone). The Name Server is then said to have authority for that zone. They can also be authoritative for multiple zones.
The difference between a domain and a zone is subtle. A domain is the full set of entities including its sub-domains while a zone is only the information within a domain that is not delegated to another Name Server. An example of a zone is citrix.com, while a separate zone would be sales.citrix.com if that zone was delegated to another Name Server within the sub-domain. In this case, the primary Citrix zone could include citrix.com, it.citrix.com, and support.citrix.com, but because sales.citrix.com is delegated, it is not part of the zone that the citrix.com Name Server is authoritative over. The following diagram shows the two zones.
To properly delegate a sub-domain, you must assign authority for the sub-domain to different Name Servers. Instead of the ns1.citrix.com in the preceding example containing information about the sub-domain sales.citrix.com, it contains pointers to the Name Servers that are authoritative for the sub-domain (ns1.sales.citrix.com).
Root Name Servers and Query Resolution
Root Name Servers know the IP addresses of all of the Name Servers authoritative for the second level domains. If a Name Server does not have information about a given domain in its own data files, then it only needs to contact a root server to begin traversing the proper branch of the DNS tree structure to eventually get to the given domain. This might involve a series of requests to multiple Name Servers to assist in the tree traversal to find out who the next authoritative Name Server is that needs to be contacted for further resolution. The following diagram shows a typical DNS request, assuming that there is no cached record for the requested name during the traversal. The example given uses a mock up of the Citrix domain as a use case.
Recursive and Non-Recursive Queries
The preceding example demonstrates the two types of queries that can occur.
Caching
Although the resolution process is quite involved, and might potentially require small requests to several hosts, it is usually very fast. One of the things that increase the speed of DNS resolution is caching. Each time a Name Server receives a recursive query, it might have to communicate to other servers to eventually get to the proper authoritative server for the specific request. It can also store all of the information that it receives along the way for future reference. Subsequently, when the next client makes a similar request such as a different host but in the same domain, it already knows the Name Server that is authoritative for that domain, and can send a request directly there instead of starting at the root Name Server.
Caching can also occur for negative responses such as those queries for hosts that do not exist. In this case, the server must not query the authoritative Name Server for the requested domain to find out that the host does not exist, to save time, the Name Server simply checks the cache and responds back with the negative record.
Name Servers do not cache records indefinitely, or else you can never update the IP addresses. To avoid synchronization problems, DNS responses contain a time to live (TTL). This field describes the amount of time that a cache can contain a record before it must discard it and check with the authoritative Name Server for any updated records. Chances are the records have not changed, but the use of TTL allows for this as well as allowing for rapidly dynamic responses from devices performing Global Server Load Balancing (GSLB).
Resource Record Types
There are many types of DNS resource records and a comprehensive list of types and description can be found at http://www.bind9.net/dns-parameters or in the various RFCs that define the current DNS standard. The following table lists the common resource record types.
A | a host address | [RFC 1035] |
NS | an authoritative name server | [RFC 1035] |
MD | a mail destination (Obsolete - use MX) | [RFC 1035] |
MF | a mail forwarder (Obsolete - use MX) | [RFC 1035] |
CNAME | the canonical name for an alias | [RFC 1035] |
SOA | marks the start of a zone of authority | [RFC 1035] |
WKS | a well known service description | [RFC 1035] |
PTR | a domain name pointer | [RFC 1035] |
HINFO | host information | [RFC 1035] |
MINFO | mailbox or mail list information | [RFC 1035] |
MX | mail exchange | [RFC 1035] |
TXT | text strings | [RFC 1035] |
AAAA | IP6 Address | [RFC 3596] |
SRV | Server Selection | [RFC 2782] |
The NetScaler software release 9.1 currently supports the following resource record types:
A, NS, CNAME, MX, AAAA, PTR, SOA, SRV.
How Does GSLB fit into this?
GSLB is special only because of the algorithms and protocols involved in deciding which IP address must be sent for a DNS query. GSLB sites are typically geographically distributed and there is a DNS authoritative Name Server at each site running as a service on the NetScaler appliance. All Name Servers at the various sites involved are authoritative for the same domain(s). Each of the GSLB domains is a sub-domain for which a delegation is configured so that the GSLB Name Servers are authoritative and can use one of the various load balancing algorithms to decide which IP address to give out at any given time.
A delegation is created by adding a Name Server record for the GSLB domain in the parent domain database files and a subsequent address record for the Name Servers that are used for the delegation. For example, if you wanted to use GSLB for http://www.citrix.com/, then the following Bind SOA file can be used to delegate requests to http://www.citrix.com/ to Name Servers Netscaler1 and Netscaler2.
################################################################################################Understanding BIND is not a requirement for configuring DNS, and all compliant DNS server implementations have a method of creating the equivalent delegation. Microsoft DNS servers can be configured for delegation using the instructions at:
http://technet.microsoft.com/en-us/library/cc785881(WS.10).aspx.
What makes GSLB on NetScaler appliance different from using the standard DNS service for distributing traffic is that the NetScaler GSLB sites exchange data using a proprietary protocol call Metric Exchange Protocol (MEP). With MEP, the GSLB sites are able to maintain information about all other sites. Therefore, when a DNS request is received, it is able to look at the GSLB metrics to determine information such as the site with the least number of current connections, or which site is closest to the LDNS server that sent the request based on Round Trip Times. There are several other load balancing algorithms that can be used, but GSLB is a DNS with the brain underneath telling the Name Server (hosted on the NetScaler appliance) which address must be sent based on metrics of participating sites.
Other benefits that GSLB provides are the ability to maintain persistence (or site affinity). Responses to the incoming DNS queries can be compared with the source IP address to determine if that address was directed to a particular site in the recent past. If so, then the same address is sent in the DNS response to ensure that the client session is maintained.
Another form of persistence can be obtained at the site level through the use of HTTP redirects, or HTTP proxying. These forms of persistence occur after the DNS response occurs. Therefore, if you get an HTTP request at a site that contains a cookie to direct the request to a different participating site, then you can either respond with a redirect or proxy the request to the appropriate site.
Metric Exchange Protocol
Metric Exchange Protocol (MEP) is used to share the data used in Global Site Load Balancing calculations across sites. Using MEP connections, you exchange three types of data. These connections need not be secure over TCP port 3011 or can be secure using SSL over TCP port 3009. The following three types of data are exchanged, and have their own intervals and exchange methods.
By default, site services are monitored over MEP based on polling information only, but if you bind monitors based on monitor interval, the state is updated and you can control the frequency of the updates by setting the monitoring interval accordingly.
联系客服
