INTRODUCING A BETTER, FASTER, SAFER, DNS.

Naturally, infrastructure supporting your site’s DNS service is critical for keeping your site available to end users. Any degradation or failure in your DNS service can result in your site slowing down or even becoming unavailable, since DNS is typically how any web browser or device finds your site.

The pivotal role of DNS also makes it one of the most common vectors for malicious attacks. DNS is often deployed on old, slow, insecure, and difficult-to-manage infrastructure which can make your business attackable.

A PREMIER GLOBAL NETWORK.

JoDiHost Route is a high-performance, high availability, scalable and secure DNS platform. Route leverages JodiHost’s massive global IP Anycast network, with points of presence in most major metros across four continents, and with high-performance proximity to almost every broadband user in the world. The global distribution of our DNS PoPs, capacity and redundancy of our network, and industry-leading performance also provide resilience against DDoS attacks and localized Internet failures.

JodiHost Route delivers the features, performance, scalability, reliability, availability and security required to ensure the best possible web experience for your web users in a cost-effective solution. And with no up-front capital costs, Route provides the availability, scalability, performance, and security your business needs.

July 2014 DNS Speed Comparison Report



These are the dns speed rankings for July 2014. This report includes the fastest managed DNS services across the world. In the month of July 2014, EdgeCast, CDNetworks and DNSMadeEasy are the top three managed DNS providers in terms of speed. Averaged across all name servers, EdgeCast took 3.43 milliseconds, CDNetworks took 4.25 milliseconds and DNSMadeEasy took 5.38 milliseconds. These are across several million DNS queries across over 1.1 million name servers across the world. EdgeCast has 20 points of presence across the world. CDNetworks has 48 network locations and DNSMadeEasy has 12 locations.

http://www.solvedns.com/dns-comparison/2014/07

Each customer of our CDN is provided with a variety of offerings through which he can achieve reliable, high performance, and secure DNS service. This Route solution allows the customer to perform all of the following:

• Manage a DNS zone.
• Set up a secondary DNS zone.
• Load balance traffic across servers.
• Establish a failover system that prevents an interruption to site traffic when server(s) can no longer properly fulfill requests.
• Verify a server's capability to fulfill requests through health checks performed from around the world.
• Mitigate Distributed Denial of Service (DDoS) attacks on your servers by leveraging our distributed DNS network and technologies.

The Route solution consists of two modules:

• Managed (Primary) or Secondary DNS
• DNS Health Checks

Managed (Primary) or Secondary DNS Module

The module allows:

• DNS zone management capabilities through which various types of records (e.g., A, AAAA, CNAME, etc.) may be added to a zone.
• Secondary zone capabilities that allow the transfer of a zone from a master name server to our name servers.
• Load balance or failover traffic across multiple servers.

The module contains the following components:

Component	Description
Standard Routing	Identifies zones that do not leverage our load balancing/failover capabilities or advanced policies.
Adaptive Availability	This component allows traffic management (i.e., load balancing or failover) for: Address or CNAME records of a primary zone hosted by our Route solution. A CNAME record or subdomain of a primary zone hosted by another DNS service provider.
Advanced Policy Routing	Identifies zones that leverage advanced policies that allow routing based on IP address, country, ASN, IP groups, network groups, POP, or IP type. This type of zone can also leverage our load balancing/failover capabilities.

DNS Health Checks Module

The health of a server/domain that is part of a load balancing or failover configuration can be probed by polling it with an HTTP or TCP request. If the majority of our servers deem it to be unfit to serve traffic, then this module will take the following action:

• Load Balancing: If a server/domain is deemed unhealthy, it will be pulled out of load balancing and traffic will be redistributed proportionally to the remaining healthy servers/domains.
• Failover: If the primary server/domain is deemed unhealthy, all traffic will be switched to the backup server/domain.

Our Route solution has been designed for ease of use. This means that the various modules offered in this solution can be configured and managed from a single location.

More Detailed Information

Primary Zone Management

The Managed (Primary) or Secondary DNS module allows the creation and management of zones. A zone defines a set of data through which our authoritative name servers can provide a response to DNS queries. This data can be found in the records associated with the customer’s zone. In addition to record administration, zone management also allows the definition of load balancing and failover configurations for address and CNAME records within that zone.

Before setting up a zone, it is important for the customer to make a distinction between a zone and a domain. A domain is a generic label used to identify a resource (e.g., computer) on the Internet. A zone is a delegation of authority over a particular namespace. This delegation allows our name servers to be authoritative for that zone. This means that recursive name servers can only receive an authoritative answer for the domain associated with the customer’s zone through our authoritative name servers.

The following scenario provides a high-level overview on how a web browser's query is resolved. It's assumed that a zone has been previously created and configured on our DNS service.

1. A user uses a web browser to submit a request for "mydomain.com."

2. The web browser forwards this DNS request to a recursive DNS server as defined by the user's network configuration.

3. The recursive DNS server will check whether it is authoritative for the corresponding zone or if it previously has cached a response. If either of those conditions is true, it will provide an immediate response to the user.

4. Otherwise, the recursive DNS server will forward the request to a root name server. A root name server has a list of name servers that are authoritative for each top-level domain (e.g., COM, ORG, INFO, etc.).

5. The root name server will return the IP address of a name server that is authoritative for the requested domain's top-level domain (e.g., COM).

6. The recursive DNS server will then forward the DNS query to top-level name servers. These name servers have a list of name servers that are authoritative for each second-level domain (e.g., mydomain.com) associated with that top-level domain.

7. A top-level name server will then return the IP address of our authoritative name server.

8. The recursive DNS server will then forward the DNS query to our authoritative name server.

9. Our authoritative name server will provide an answer to the DNS query according to the records associated with the customer’s zone. For the purposes of this example, it will return the IP address defined in an A record.

10. The recursive DNS server will then relay the authoritative name server's answer to the user's computer and oftentimes cache it for future requests for the length of time associated with the TTL.

11. The user's user agent will then handle the request according to that answer.



As previously mentioned, a name server is only authoritative for the zones associated with it. In the above example, the "mydomain.com" zone was delegated to our DNS service. In the following illustration, we will see how DNS is resolved when "us.mydomain.com" is delegated to our DNS service and the "mydomain.com" zone remains with a third-party DNS service provider.



DNS Health Checks

A key to ensuring that the customer’s site's traffic flows properly is to check at regular intervals that his web servers can provide a response to requests. Our DNS Health Checks module is designed to check server/domain health status at regular intervals by sending an HTTP, HTTPS, TCP, or a TCP SSL request from our health checks agents. The worldwide distribution of our health check agents ensures that network latency doesn't result in a misdiagnosis of a server/domain's health state.

Our health check agents can be configured to poll a server at regular intervals using one of the following types of requests:

Request Type	Description
HTTP/HTTPS GET	Polls a server using a GET request over HTTP or HTTPS.
HTTP/HTTPS POST	Polls a server using a POST request over HTTP or HTTPS.
TCP/TCP SSL	Polls a server by opening a connection over TCP or TCP SSL.

A server/domain will be considered healthy if both of the following conditions are met:

• The response indicates that a valid connection was established (e.g., 200 OK).
• An additional check will be performed if content verification has been enabled on the health check. The body of the server’s response to a health check request must contain a user-defined word or phrase.

Our health check agents are distributed around the world. Each of them will poll a monitored server/domain every few seconds, as determined by the health check configuration. A simple majority consensus will then be used to determine whether traffic should be pulled from a server/domain.

A health check may fail due to a reason that is unrelated to health status (e.g., a connectivity issue on a single transit/peering route).

The following illustration demonstrates that a web server can be considered healthy even though a health check failed.


Health Check Consensus: Pass

A server/domain is considered healthy until a majority of health check agents indicate otherwise. In the following illustration there is a unanimous consensus that a server is unhealthy. This will cause our DNS service to stop serving traffic to that server as indicated below.

• Load Balancing: Traffic will be redistributed proportionally to the remaining servers in that load balancing group.
• Failover: If a primary server or domain is found to be unhealthy, then traffic will be redirected to the backup one.

Health Check Consensus: Fail

Once traffic is pulled from a server/domain, the customer’s health check configuration determines whether it will be automatically or manually reintegrated. Automatic reintegration means that traffic will flow through that server/domain as soon as a consensus is established that it is healthy. Manual reintegration means that the customer has to manually update his load balancing or failover configuration to indicate that it is now ready to receive traffic.

DNS Load Balancing

The process of distributing traffic for a particular domain across multiple servers is known as load balancing. This distribution of requests ensures data availability through redundancy. If a server in a load balancing group is unavailable, either due to scheduled maintenance or an unplanned outage, requests to the corresponding domain will be balanced among the remaining servers.
Our Route solution allows the following types of load balancing configurations:

Type	Description
CNAME Record	Load balance traffic that points to a CNAME record in a primary zone hosted on another DNS service provider.
Subdomain Delegation	Load balance traffic that points to a subdomain of a primary zone hosted on another DNS service provider.
Primary Zone (CNAME and Address Records)	Load balance traffic across A, AAAA, or CNAME records in a primary zone hosted on our Route solution.

A load balancing configuration allows our authoritative DNS servers to distribute requests across various servers or CNAMEs. Five key steps during this process are following:

1. In response to a user's action (e.g., requesting a web page), an application submits a DNS query to a recursive DNS server.

2. A recursive DNS server forwards the DNS query to the appropriate authoritative name server (i.e., Route). The appropriate authoritative name server is determined via root and top-level domain name servers.

3. A Route name server provides an answer to the DNS query. In this example, it will resolve a domain to an IP address according to the customer’s load balancing configuration.

• Address Records: The Route name server will proportionately resolve DNS queries to each address record in the group. The proportion of requests that will be resolved to each address record is defined by its weight.
• CNAME Records: The Route name server will proportionately resolve DNS queries to each CNAME record in the group. The proportion of requests that will be resolved to each CNAME record is defined by its weight. After which, the chosen CNAME record will be resolved to an address record according to its DNS configuration.

4. A recursive DNS server caches the response according to the TTL (e.g., 300 seconds) and forwards it to the customer’s application.

5. The user’s application uses the response to fulfill the request (e.g., direct an HTTP GET request to the site's IP address).

The following illustration depicts how requests are load balanced between three different servers.

DNS Resolution with Load Balancing

The manner in which requests will be distributed between the above servers is determined by the weight assigned to each server. More heavily weighted servers (i.e., servers that have been assigned a larger value) will receive more requests than servers that have been assigned a lower weight. The following illustration depicts a load balancing configuration that contains three servers. One of the servers has been assigned a lower load balancing weight than the other two. As a result, less traffic is sent to it.

Load Balancing Weight & Request Distribution

Server	Weight	Calculation	Traffic Percentage
A	20	(20/50) * 100	40%
B	20	(20/50) * 100	40%
C	10	(10/50) * 100	20%
Total:	50	Total:	100%

The following illustration demonstrates how traffic is redistributed among the remaining servers when a server is removed from a load balancing configuration.

Traffic Redistribution due to the Removal of a Server from Load Balancing

In the above illustration, our DNS service stopped serving traffic to a server that was previously receiving 40% of total traffic. This traffic must now be redistributed proportionally among the remaining two servers. We accomplish this by recalculating the traffic percentage using the new total weight value. The new total weight value, which is 30, can be calculated by summing the weight of all active servers in the configuration (20 + 10). The following table uses the above formula to calculate the percentage of traffic that will be sent to each server.

Server	Weight	Calculation	Traffic Percentage
A	0	(0/30) * 100	0%
B	20	(20/30) * 100	66.67%
C	10	(10/30) * 100	33.33%
Total:	30	Total:	100%

In summary, we can make the following conclusions:

• Load balancing provides the means through which traffic can be balanced between servers with varying hardware and/or performance levels.
• A server's weight is important, since it is an indication of the amount of traffic that should be distributed to it.
• Weight is relative to the total weight associated with a load balancing configuration.
• Load balancing allows traffic to be redistributed to healthy servers when a server is pulled out of the load balancing configuration.
• A server's relative weight plays an even greater role when a load bearing server is pulled from a load balancing configuration.

DNS Failover

A primary/backup relationship can be established between two servers or domains. This type of relationship allows a backup server/domain to take over when the primary server/domain can no longer fulfill its responsibilities. This prevents an outage from impacting site traffic. This process is known as failover.

Type	Description
CNAME Record	Failover traffic that points to a CNAME record in a primary zone hosted on another DNS service provider.
Subdomain Delegation	Failover traffic that points to a subdomain of a primary zone hosted on another DNS service provider.
Primary Zone (CNAME and Address Records)	Failover traffic across multiple address or CNAME records in a primary zone hosted on our Route solution.

A failover configuration establishes a primary and backup relationship between two servers or domains. Our authoritative name servers will send all traffic to the primary server/domain until it fails a majority of its health checks. At which point, all traffic will be redirected to the backup server/domain.

The following illustration shows the process through which all requests are resolved to the IP address of a primary server.

Resolving a DNS Query for a Failover Configuration

A health check configuration plays a major role in determining when to fail traffic over to a backup server/domain. Once a health check configuration has been established, a server/domain will be polled at regular intervals to ensure that it is still healthy.

In the following illustration, both the primary and backup servers have passed a majority of their health checks. All traffic is directed to the primary web server as a result of a failover configuration.

Healthy Primary Server

If the primary server fails a majority of its health checks, our DNS service will redirect all traffic to the backup server. This is illustrated below.

Unhealthy Primary Server

In the above scenario, traffic will continue to be served to the backup server until the primary server is reintegrated back into the failover configuration. At which point, our DNS service will redirect all traffic to the primary server.

Secondary DNS

Secondary DNS allows our name servers to be authoritative for DNS zones managed outside of our network.

This type of setup allows the following:

• Automatic propagation of updates from DNS zones managed on a master name server. This allows the customer’s zone content to be managed elsewhere, while still leveraging our global Anycast DNS product and network to resolve the customer’s users' DNS queries.
• Hidden master name servers. This security measure protects the customer’s name server from malicious attacks while continuing to manage his zones locally or through another DNS service provider. This allows the customer to leverage Route's performance, reliability, and security capabilities while maintaining continuity with his existing zone management process.

Our Secondary DNS solution synchronizes zone content between a master name server and our Anycast DNS system. This process consists of the following steps:
1. Initial Zone Transfer

2. Zone Synchronization

Initial Zone Transfer


Initial Zone Transfer & Domain Delegation

1. An administrator creates a secondary zone within Route.

2. The Route transfer system requests a zone transfer for that zone from a master name server.

3. The master name server performs a full zone transfer (AXFR) for the requested secondary zone.

4. A read-only copy of that zone is created within Route. Glue records for our vanity name servers are automatically added to that zone. Vanity name servers lend a professional appearance to the customer’s site's DNS. The resulting zone is known as a secondary zone.

5. Our Route transfer system will then deploy the secondary zone to our Route name servers.

6. DNS queries must now be directed to our Route name servers. This step requires an administrator to update the appropriate domain registrar to point the zone to our vanity name servers.

Zone Synchronization

Once a secondary zone has been created, our DNS solution ensures that it remains synchronized with the master zone. It is able to do so by querying the master name server approximately every 120 seconds. This query compares serial numbers between the master and secondary zone. If this comparison reveals that the master zone's serial number has been incremented, then a full zone transfer (AXFR) from the master name server to our Route transfer system will be triggered. Once the new version of the zone has been received, our Route transfer system will deploy the secondary zone to our worldwide Anycast DNS system in approximately 60 seconds.


Secondary Zone Synchronization

Serial Number Comparison

In order to ensure that a secondary zone is synchronized with a master zone, our name servers will query each master name server associated with that secondary zone approximately every 120 seconds. This query compares the serial number in the SOA record between the master and secondary zone. The result of this comparison determines the behavior of our name servers.

• If the serial number matches, then no action will take place.
• If the serial number has been incremented, then the following steps will take place:
• The Route transfer system will submit a zone transfer request (AXFR) to the master name server.
• The secondary zone will be replaced with the results of the zone transfer.
• The new version of the secondary zone will be propagated throughout the world to our Route name servers.

DNS Query Handling

Our Route name servers will be able to authoritatively resolve DNS queries to the customer’s zone once the following conditions are met:

• The secondary zone in question has been deployed to our Route name servers.
• The zone has been delegated to our vanity name servers.

If the customer’s master name servers are unavailable, our Route solution will continue to serve the last transferred zone regardless of whether the requested record's TTL has expired. This differentiates our service from traditional Master/Slave DNS systems where slave name servers stop serving zones when the master name server remains unavailable beyond a record's TTL.

This design ensures that stale DNS requests are resolved efficiently even when the customer’s master name server is unavailable. In the following illustration, notice how DNS requests handled by our name servers are never forwarded to the customer’s master name server.


Route Name Servers Behave as Master Name Servers

Zone Transfer Authorization

Our Secondary DNS feature allows a zone to be transferred from one or more master name servers to our Route name servers. This initial zone transfer, along with subsequent synchronizations, requires that our Route transfer system be allowed access to the master name servers that host the primary zone.

Creating a secondary zone will not automatically redirect DNS traffic to our Route name servers. Once a secondary zone is ready to handle production traffic, its traffic needs to be directed to our Route name servers by changing the name servers at the customer’s domain registrar. This may require the creation of glue records, which are also known as Host or Name Server records. This type of record identifies our vanity names servers by name and IP address.