WO2013189021A1

WO2013189021A1 - Round trip time measurement system

Info

Publication number: WO2013189021A1
Application number: PCT/CN2012/077129
Authority: WO
Inventors: Qunyang LIN; Junqing Xie; Zhiyong Shen
Original assignee: Hewlett-Parkard Development Company, L.P.
Priority date: 2012-06-19
Filing date: 2012-06-19
Publication date: 2013-12-27

Abstract

Systems, devices, and methods, including executable instructions and/or logic thereon, are provided for Round Trip Time (RTT) measurement. A system includes a Measurement Trigger (MT) configured to serve as a Domain Name System (DNS) server for a domain of a particular server system. A plurality of Network Latency Collectors (NLCs) is provided. Each NLC is deployed in front of a respective one of a plurality of server sites within the particular server system and communicatively coupled to the MT.

Description

ROUND TRIP TIME MEASUREMENT SYSTEM

Background

Computing networks can include multiple devices including network devices such as routers, switches, and hubs, computing devices such as servers, desktop PCs, laptops, workstations, and peripheral devices, e.g., printers, facsimile devices, and scanners, networked together across a local area network (LAN), a wireless local area network (WLAN), and/or wide area network (WAN).

Internet content and application providers usually place multiple copies of replicated servers with a unified domain name at data centers in distributed locations. One goal is to deliver content and applications quickly and accurately to a given client location. One challenge to doing so is to determine which server site is closest in proximity or lowest in latency to a given client. As network applications rely on Domain Name System (DNS), work has been conducted with DNS servers to resolve the domain names of content and application servers to IP addresses.

In the industry, Global Traffic Management (GTM) systems use network latency comparisons to content and applicant servers for a given client from among a set of replicated servers deployed at distributed locations. Network latency, e.g., a Round Trip Time (RTT) measurement of a DNS system, may be used by GTM systems. However, active measurement methods and tools like ping, e.g., ICMP pings (Internet Control Message Protocol), DNS, traceroute, and UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) probe messages may not work when the measured local DNS systems do not respond due to reasons like security.

Brief Description of the Drawings

Figure 1 illustrates an example system according to an embodiment of the present disclosure. Figure 2 is an example embodiment of a message sequence for measuring Round Trip Time (RTT) according to the present disclosure.

Figure 3 is a block diagram illustrating a processing resource, a memory resource, and a machine readable medium according to an example

embodiment of the present disclosure.

Figure 4 illustrates an example method for Round Trip Time (RTT) measurement according to the present disclosure.

Detailed Description

Network latency, e.g., Round Trip Time (RTT), measurement is used to determine an appropriate server for a given client in distributed network systems, e.g., Content Delivery Networks (CDN) or large scale online game systems. Systems designed to optimize response time and improve availability may be referred to as Global Traffic Management (GTM) systems and/or Global Load Balance (GLB) systems. Many network applications use DNS to resolve a domain name to an IP address. A client is usually close to its local DNS.

Accordingly, the RTT between the content and/or application server and the client local DNS can be approximated as the RTT between the content and/or application server and the client.

As mentioned above, local DNS servers may not respond to active measurement methods and tools like ping, e.g., ICMP (Internet Control

Message Protocol), DNS, traceroute, and UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) probe messages due to security. An alternative passive measurement method includes TCP three way handshaking. However, this method relies on TCP connections whereas DNS transactions mainly run over UDP. Another passive measurement method is termed DNS reflection. However, DNS reflection employs extra resources, e.g., two IP addresses and two domain names for each content and/or application server. The extra resources additionally entail extra system costs associated with maintaining and running two DNS server instances for each content and/or application server. Embodiments of the present disclosure provide a cost efficient passive measurement system and method. An example system includes a

Measurement Trigger (MT) and a Network Latency Collector (NLC). As used herein, an MT and an NLC can both be embodied as either a physical network device and/or as modules, e.g., set of computer executable instructions

(program instructions), intentionally purposed, when executed, to perform the acts, functions and tasks described herein.

According to embodiments an NLC can be an intercepting device and/or module, deployed in front of each content and/or application server. In one example an NLC can be embodied as a global load balancer. Embodiments, however, are not limited to this particular example.

According to embodiments an MT can be a network device and/or module capable of performing DNS functionality. That is, the MT can be a network device and/or module which can act as a DNS server for the domain of a given application and/or content server system. Using these embodiments an RTT measurement can be triggered by an MT to measure a RTT between a client local DNS and a particular NLC on behalf of its co-located content and/or application server.

Embodiments of the present disclosure may include network devices, systems, and methods, including executable instructions and/or logic thereon, to measure RTT for traffic measurement. A network device includes a processing resource coupled to a memory. In the following detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure may be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the embodiments of this disclosure, and it is to be understood that other examples may be utilized and that process, electrical, and/or structural changes may be made without departing from the scope of the present disclosure.

The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 101 may reference element "01 " in Figure 1 , and a similar element may be referenced as 201 in Figure 2. Elements shown in the various figures herein can be added, exchanged, and/or eliminated so as to provide a number of additional examples of the present disclosure. In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the present disclosure, and should not be taken in a limiting sense.

Figure 1 illustrates an example system 100 according to an embodiment of the present disclosure. As shown in Figure 1 , the system can include a number of clients, e.g. client side user 101 accessing a number of content and/or application servers, e.g., 103-1 and 103-2 over a network. A network can include wired and/or wireless Local Area Networks (LANs) and/or Wide Area Networks (WANs), including the Internet. As mentioned above, Internet content and application providers usually place multiple copies of replicated servers with a unified domain name at data centers in distributed locations, e.g., SITE A and SITE B.

As shown in Figure 1 , the system 100 includes a Measurement Trigger (MT) 104. The MT 104 is configured to serve as a Domain Name System (DNS) server for a domain of a particular server system, e.g., server system including content/application servers 103-1 in SITE A and content/application servers 103-2 in SITE B. The MT 104 can be a network device and/or module, e.g.

computer executable instructions (program instructions), capable of performing DNS functionality. While two server sites are shown in the example of Figure 1 , embodiments are not limited to this example and more server sites may be included.

According to embodiments, the MT 104 includes program instructions executable to extend a set of DNS system instructions with a set of

measurement hook instructions and a set of measurement command

instructions. The set of measurement hook instructions includes instructions that can be executed to analyze a received message, e.g., DNS query, from a client local Domain Name Server (DNS) server 109 and identify an IP address of the client local DNS server 109. The MT 104 can then execute instructions to determine whether or not to trigger the RTT measurement. For example, the MT 104 can determine whether or not to trigger an RTT measurement in association with a particular NLC 106-1 106-2 based on whether an RTT measurement has already been collected or according to whether an RTT measurement has been collected within a particular time period, as a threshold. In this manner the instructions can be executed to determine whether or not to trigger the RTT measurement based on an evaluation of which NLC 106-1 106- 2 have been most recently probed, or other selectable policy.

If the RTT measurement is triggered, MT instructions are executed to call a measurement command. The MT measurement command instructions are executed to trigger measurement on the selected NLC and deliver a

measurement command message to the selected NLC. The message contains a measurement notification, an IP address associated with a selected content and/or application server, and the source address information (e.g., IP address and port number) of the query message from the client local DNS server 109.

A plurality of Network Latency Collectors (NLCs) 106-1 (NLC A) and 106- 2 (NCL B) are shown communicatively coupled to the MT 104. Each NLC 106-1 and 106-2 are deployed in front of a respective one of a plurality of content and application servers 103-1 and 103-2 in server SITE A and server SITE B. Each NLC can be an intercepting device and/or module, e.g. computer executable instructions (program instructions), deployed in front of each content and/or application server. In one example an NLC 106-1 and 106-2 can be embodied as a global load balancer.

A number of routers, hubs and/or switches 107-1 , 107-2, 107-3 and 107-

4 are also illustrated connecting the client side user 101 , the MT 104, the plurality of NLCs 106-1 and 106-2, and content/application servers over a network, e.g., Internet 1 10.

In the example embodiment shown in Figure 1 , a client side user 101 can send a name resolution query of an application server domain name, e.g., www.app.hico.com, to a local Domain Name System (DNS) server 109.

According to DNS system set up, the local DNS server can be configured to send name resolution queries associated with a particular application server domain name to a particular MT 104 which perform the functions of a DNS server for the particular application server domain name.

In at least one embodiment, the MT 104 is configured to construct a message to a selected NLC, e.g., NLC A, including a measurement notification, an IP address of a specified content and/or application server, and the source address information of the query message from the client local DNS server 109. Further the MT 104 can send a message to the selected NLC to respond to the domain name query to a particular application server domain name with a DNS Name Server (NS) response message to the client local DNS server 109. The NS response indicates that the selected NLC is delegated to resolve the domain name query.

According to embodiments the NLC 106-1 and 106-2 include program instructions executable to perform a User Datagram Protocol (UDP) spoofing action to send the DNS NS response message on behalf of an arbitrary address to the client local DNS server 109. This includes modifying a UDP header to set a source IP address and a source port as a source IP address and a source port address of the MT 104. The source address information, including IP address and port number, of the query message from the client local DNS server 109 will be used as the destination of the DNS NS response message. The NLC 106-1 and 106-2 additionally execute instructions to generate the DNS response message. This can include constructing a DNS header and a number of records to put in each response section. The records can include a record selected from the group of an NS record, an A record (e.g., for IPv4 platforms), an AAAA record (e.g., for IPv6 platforms), and a CNAME record, etc. The sections can include a section selected from the group of an answers section, an authoritative name servers section, and an additional records section, etc. The format for the fields of such sections can follow those in adopted and/or proposed DNS message standards.

In response to receiving the DNS NS response, the local DNS server sends the domain name query to the selected NLC. Upon receipt of the domain name query, the selected NLC is configured to calculate a time between sending the NS response and receiving a follow-on DNS query from the local DNS server as a Round Trip Time (RTT).

Hence, using these embodiments an RTT measurement can be triggered by an MT to measure a RTT between a client local DNS and a particular NLC on behalf of its co-located content and/or application server.

Figure 2 is an example message sequence diagram according to an embodiment of the present disclosure. In the example of Figure 2 a message sequence is shown between a client 201 , a local DNS server 209, a

Measurement Trigger (MT) 204, a first Network Latency Controller (NLC A) 206- 1 , and a second NLC (NLC B) 206-2. In at least one embodiment the client 201 can be analogous to the client side user 101 discussed in Figure 1 . The local DNS server 209 can be analogous to the local DNS server 109 shown in Figure 1 . The MT 204 can be analogous to MT 104 in Figure 1 and NLC A 206-1 and NLC B 206-2 can be analogous to NLC A 106-1 and NLC B 106-2 in Figure 1 .

The example message sequence in Figure 2 illustrates measuring Round

Trip Time (RTT) between a local DNS server (local to a client) and a selected NLC, e.g., NLC B 206-2. In the example of Figure 2 a name resolution query of an application server domain name, e.g., www.app.hico.com, can be initiated by a client 201 and sent from the client 201 to the client's local DNS server 209, as shown at 213. The local DNS server 209 at 214 follows the standard DNS operations and forwards the name resolution query to the MT 204 serving as the DNS server for the associated application server domain name, as shown at 215.

According to this example embodiment, instead of the MT 204

responding with the IP address of an application server, e.g., 103-1 and 103-2 in Figure 1 , as the DNS server for the domain, the MT 204 determines whether or not to trigger an RTT measurement. For example, the MT 204 can execute instructions to determine if a given content and/or application server site, e.g., SITE A and/or SITE B in Figure 1 , have participated in a RTT measurement relative to a given user client side and local DNS server 209 previously or within a particular time period threshold. At 21 6, if the MT 204 determines that an RTT measure should be conducted, the MT 204 will select an NLC to participate in an RTT measurement relative to the local DNS server 209.

In the example of Figure 2, the MT 204 selects NLC B to participate in an RTT measurement relative to the local DNS server 209. The MT 204 constructs a measurement command message including a measurement notification, source address information of the query message from the client local DNS server 209, and IP address of a particular application server, e.g., 103-2, to be assigned to the client 201 and sends the message at 217 to the selected NLC 206-2, e.g., NLC B 106-2 in Figure 1 .

The selected NLC 206-2 receives the message from the MT 204. In this example, the selected NLC 206-2 generates a spoofed DNS NS response message (e.g., type=NS, NS=nlc-b. app.hico.com) to delegate itself to resolve the domain name query by appending a sub-domain server name and the IP address of the selected NLC 206-2 in the DNS response at 218. At 219 the selected NLC 206-2 sends the spoofed NS response to the local DNS server 209.

After receiving the DNS response, client local DNS server 209 follows the delegation and sends a name resolution query (e.g., type=A,

name=www.app.hico.com) to the selected NLC 206-2, as shown at 221 . The selected NCL 206-2 receives the name resolution query from the client local DNS server 209 and, at 222, the selected NLC 206-2 calculates the time period between sending the spoofed DNS response at 219 and receiving the follow-on DNS query at 221 to get the RTT from the selected NCL 206-2 to the client local DNS server 209.

Additionally, the selected NLC 206-2 responds with the IP address specified in the measurement command message to the client local DNS at 223. At 225, the client local DNS server 209 forwards the IP address specified in the measurement command message to the client 201 .

As such, example embodiments of the present disclosure do not involve modification in the client 201 or the client local DNS server 209. The MT 204 executes instructions to extend the implementation of the DNS system, which can communicate with existing clients 201 and local DNS servers 209 smoothly. The selected NCL 206-2 is an intercepting network device or module performing the measurement to collect the RTT on behalf of the co-located content and/or application servers without any modification to the content and/or application servers.

Figure 3 is a block diagram illustrating an example of a processing resource 314, a memory resource 31 6, and a machine readable medium 318 according to the present disclosure. The processing resource 314 and the memory resource 316 can be local to a computing device, such as on a router, switch, server or other network device, etc. The machine readable medium 318 (e.g., a tangible, non-transitory computer readable medium) and/or the memory resource 31 6 can store a set of machine readable instructions (e.g., program instructions in the form of software, firmware, etc.) executable by the processing resource 314. The machine readable medium can be local to a computing device or remote therefrom. For those examples in which the machine readable medium is remote from the computing device, the instructions can be loaded into the memory resource 314 of the computing device.

As shown in the example embodiment of Figure 3, the machine readable medium 318 includes a Measurement Trigger (MT) module 320 and a Network Latency (NLC) module 322. The MT module 320 and the NLC module 322 can include instructions, e.g., program instructions, which can be executed to by the processing resource 314 to perform particular tasks, acts and/or functions on a given computing device as described herein.

In the example embodiment of Figure 3, the MT module 320 instructions include instructions executed to extend the capability of a DNS server to that of the MT 104/204 functionality described in connection with Figures 1 and 2. For example the MT module 320 includes instructions to create a measurement hook and a measurement command.

The MT module's 320 measurement hook instructions are executable to receive a DNS query from a given client local DNS server, e.g., 109 in Figure 1 , and analyze the message and identify the IP address of the client local DNS server. The MT module's 320 measurement hook instructions are executable to determine whether or not to trigger an RTT measurement. If yes, the instructions are executed to select an NLC from among a plurality of NLCS, e.g., 106-1 and 106-2 in Figure 1 , each deployed in front of a respective one of a plurality of servers sites within a particular server system, to be measured. If yes, the MT module's 320 instructions are executed to call a measurement command.

The MT module's 320 measurement command instructions are executed to trigger measurement on the selected NLC, e.g., 206-2 in Figure 2. The MT module's 320 measurement command instructions are executed to generate a measurement command message. The message contains a measurement notification, an IP address of a particular server, e.g., content and/or application server, to be assigned to a client, e.g., from a particular server site, and the source address information of the query message from the client local DNS server, e.g., 209 in Figure 2. The MT module's 320 measurement command instructions are executed to send the constructed measurement command message to the selected NLC.

In the example of Figure 3, the NLC module's 322 instructions include instructions that can be executed by a processing resource 314 to perform a UDP spoofing action and construct a DNS response message.

The UDP spoofing action leverages the fact that DNS communication is mainly based on UDP. Thus, the DNS response can be sent of behalf of an arbitrary IP address to the client local DNS. To generate a spoofed UDP message, the NLC module's 322 instructions are executed to modify portions of a UDP header. For example, the instructions are executed to set the source IP address and the source port in the UDP header as an IP address and a source port of the MT, e.g., 104 in Figure 1 .

The NLC module 322 instructions are also executed to construct the DNS message. To generate the DNS message, a DNS header and a number of records are constructed and put into each response section. By way of example and not by way of limitation the number of records can include an NS record, an A record, an AAAA record, a CN AM E record, etc. By way of example and not by way of limitation the response sections can include an answers section, an authoritative name servers section, and an additional records section. The format for the fields of such sections can follow those in adopted and/or proposed DNS message standards.

Figure 4 illustrates a method for measuring a Round Trip Time (RTT) for traffic management according to an example embodiment of the present disclosure.

As shown at block 410, the method includes receiving a Domain Name System (DNS) query at a Measurement Trigger (MT) from a client local Domain Name System (DNS) server. In this example, the DNS query is initiated by a client and sent to the local DNS server.

At block 420 the method includes using the MT to determine whether or not to trigger an RTT measurement between one of at least two Network Latency Collectors (NLCs) and the client local DNS. In at least one example, the MT can execute instructions to determine whether or not to trigger the RTT measurement based on a policy, e.g., a most recently probed NLC. Further, if the RTT measurement is triggered, MT instructions can be executed to call a measurement command. In at least one example, MT instructions can be executed to trigger measurement on the selected NLC and deliver a message containing a measurement notification, an IP address associated with a selected content and/or application server to the selected NLC, and the source address information, including IP address and port number, of the query message from the client local DNS server.

At block 430, the method includes sending from a selected NLC, triggered by the MT, a DNS Name Server (NS) response to the local DNS server delegating the selected NLC to resolve the DNS query. At block 440, the example method of Figure 4 includes receiving a return of the DNS query from the local DNS.

In at least one example, the NLC can execute instructions to perform a User Datagram Protocol (UDP) spoofing action to send the DNS NS response on behalf of an arbitrary address to the client local DNS server. The UDP spoofing action can include modifying a UDP header to set a source IP address and a source port as a source IP address and a source port address of the MT. Further the NLC can execute instructions to construct a DNS message. In this example, the NLC executes instructions to construct a DNS header and a number of records to put in each response section as described herein.

At block 450, the method example of Figure 4 includes calculating a time period between sending the DNS NS response from the selected NLC and receiving a the return of the DNS query from the client local DNS server.

Hence, embodiments of the present disclosure can provide greater reachability than conventional active measurement methods (e.g., Ping, UDP/TCP based probing) since many local DNS systems are configured not to respond to a probing message (e.g., ICMP, DNS query) from external networks due to security (e.g., firewalls). The embodiments of the present disclosure overcome this issue by measuring the RTT between a local DNS and an intercepting network device or module, e.g., selected NLC. The selected NLC performs the RTT measurement on behalf of a co-located server, e.g., content and/or application server, without any modification to the co-located server, by performing a UDP spoofing action to send the DNS NS response on behalf of a source IP address and a source port address of the MT to the client local DNS server.

Embodiments may also provide additional cost efficiency as compared to DNS reflection techniques. For example, existing DNS reflection techniques involve an extra resource (e.g., involve two IP addresses and two domain names for each server) and involve maintaining and two DNS servers instances for each server. The embodiments described herein involve running just one DNS server instance, e.g., MT, for an entire system versus each server.

Embodiments of the present disclosure may benefit many network systems and application services such as Global Traffic Management (GTM) systems, Content Delivery Networks (CDNs), Peer-to-Peer (P2P) network systems, enterprise cloud services, etc.

Although specific examples have been illustrated and described herein, those of ordinary skill in the art will appreciate that an arrangement calculated to achieve the same results can be substituted for the specific examples shown. This disclosure is intended to cover adaptations or variations of one or more examples of the present disclosure. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Combination of the above examples, and other examples not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The scope of the one or more examples of the present disclosure includes other applications in which the above structures and methods are used. Therefore, the scope of one or more examples of the present disclosure should be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.

The term "a number of" is meant to be understood as including at least one but not limited to one.

Claims

What is claimed is:

1 . A Round Trip Time (RTT) measurement system, comprising:

a Measurement Trigger (MT) configured to serve as a Domain Name System (DNS) server for a domain of a particular server system; and

a plurality of Network Latency Collectors (NLCs) communicatively coupled to the MT, each NLC deployed in front of a respective one of a plurality of server sites within the particular server system.

2. The system of claim 1 , wherein the particular server system is a content and/or application server system and the plurality of server sites are content and/or application server sites.

3. The system of claim 1 , wherein a client local DNS server is

communicatively coupled to the MT and to the plurality of NLCs.

4. The system of claim 1 , wherein the MT is configured to:

construct a message to a selected NLC including an IP address of a specified content and/or application server; and

send a message to the selected NLC to respond to a domain name query to the domain with a Name Server (NS) response to a local DNS server.

5. The system of claim 4, wherein the NS response indicates that the selected NLC is delegated to resolve the domain name query.

6. The system of claim 5, wherein the selected NLC is configured to calculate a time between sending the NS response and receiving a follow-on query from the local DNS server as a Round Trip Time (RTT).

7. A method for round trip time (RTT) measurement, comprising: receiving a Domain Name System (DNS) query at a Measurement Trigger (MT) from a client local Domain Name System (DNS) server, the DNS query initiated by a client to the local DNS server;

using the MT to determine whether or not to trigger an RTT measurement between one of at least two Network Latency Collectors (NLCs) and the client local DNS;

sending from a selected NLC, triggered by the MT, a DNS Name Server (NS) response to the local DNS server delegating the selected NLC to resolve the DNS query;

receiving a return of the DNS query from the local DNS to the selected

NLC; and

calculating a time period between sending the DNS NS response and receiving the return of the DNS query.

8. The method of claim 7, where the MT includes program instructions executable to extend a set of standard DNS system instructions with a set of measurement hook instructions and a set of measurement command

instructions.

9. The method of claim 7, wherein the set of measurement hook instructions includes instructions executed to:

analyze a received message from the client local DNS server and identify an IP address and port number of the client local DNS server;

determine whether or not to trigger the RTT measurement.

10. The method of claim 9, wherein the instructions are executed to determine whether or not to trigger the RTT measurement based on a policy including a most recently probed NLC.

1 1 . The method of claim 9, wherein, if the RTT measurement is triggered, MT instructions are executed to call a measurement command, and wherein the MT measurement command instructions are executed to: trigger measurement on the selected NLC; and

deliver a measurement command message to the selected NLC, wherein the message contains a measurement notification, an IP address associated with a selected content and/or application server, and source address information, including IP address and port number, of the DNS query from the client local DNS server.

12. The method of claim 7, wherein the NLC includes program instructions executable to:

perform a User Datagram Protocol (UDP) spoofing action to send the

DNS NS response on behalf of an arbitrary address to the client local DNS server, including;

modifying a UDP header to set a source IP address and a source port as a source IP address and a source port address of the MT; and

construct a DNS message, including;

constructing a DNS header and a number of records to put in each response section.

13. A non-transitory computer-readable medium storing a set of instructions executable by a processing resource, wherein the set of instructions can be executed by the processing resource to:

receive to a Measurement Trigger (MT) a name resolution query of a server domain name as forwarded by a local Domain Name System (DNS) server, the MT trigger acting as a DNS server for a domain associated with the server domain name;

in response to the receipt of the name resolution query, determine by the MT whether to trigger a Round Trip Time (RTT) measurement;

if the MT determines to trigger an RTT measurement, the MT executes instructions to:

select a Network Latency Collector (NLC) among a number of

NLCs, each NLC deployed in front of a number of server sites; generate a measurement command message including an IP address of a server within a particular server site of the domain to be assigned to a client; and send the measurement command message to the selected NLC; in response to a received measurement command message by the selected NLC, the NLC executes instructions to:

generate a DNS Name Server (NS) response, including a sub- domain server name and an address of the selected NLC as the IP address of the response, to delegate the selected NLC to the local DNS server to resolve the server domain name; and

send the DNS NS response to the local DNS server, including the sub-domain server name and the address of the NLC as the IP address.

14. The medium of claim 13, wherein the instructions are executed to:

receive the name resolution query from the local DNS server to the selected NLC;

respond with the IP address of the server from the selected NLC to the local DNS server, which is forwarded from the local DNS server to the client; calculate, by the selected NLC, a time period between sending the DNS NS response and receiving the name resolution query in order to calculate the RTT between the selected NLC and the local DNS server.

15. The medium of claim 13, wherein the instructions are executed to:

perform a User Datagram Protocol (UDP) spoofing action to send the DNS NS response on behalf of an arbitrary address to the client local DNS server, including;

construct a DNS message, including; constructing a DNS header and a number of records to put in a number of response sections, wherein the records include a record selected from the group of an NS record, an A record, an AAAA record, and a CNAME record, and wherein the sections include a section selected from the group of an answers section, an authoritative name servers section, and an additional records section.