Contact Us Anytime:
Managed 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.

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

DNS Speed Comparison Report - EdgeCast, CDNetworks and DNSMadeEasy are the top three managed DNS

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.
Try our features with a no commitment test account


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:

The Route solution consists of two modules:

Managed (Primary) or Secondary DNS Module

The module allows:

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:

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 ""

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., 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.

managed DNS

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

managed DNS

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:

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.

Managed DNS
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.

Managed DNS
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.

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.
Managed DNS
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.
Managed DNS
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.
Managed DNS
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:

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.
Managed DNS
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.
Managed DNS
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.
Managed DNS
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:

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

Managed DNS
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.

Managed DNS
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.

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:

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.

Managed DNS
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.

Try our features with a no commitment test account
alt_picture! Complete solution With no up-front capital costs, Route provides the availability, scalability, performance, and security you want and need.
alt_picture! Easy configuration Make configurations anyway you like – through our user interface or via REST API.
alt_picture! Massive scale Leverage JodiHost’s global IP Anycast network with distribution across more than 20 points of presence (PoPs) in 12 countries.
alt_picture! Immunity By not operating in recursive mode, Route is immune to cache poisoning.
alt_picture! DDoS mitigation Years of experience running a world-class CDN provides for robust, battle-tested DDoS protection.
alt_picture! Ultimate reliability Our infrastructure ensures resolution of DNS queries 100% of the time.
alt_picture! Speed matters The combination of Anycast technology with our network's massive scale and capacity results in an extremely fast experience.
alt_picture! Wide support of record types Route supports a wide variety of DNS record types, including: A, AAAA, CNAME, MX, NS, SOA, SPF, SRV, TXT.
alt_picture! Fully RFC-compliant Let Route function as either your managed or secondary DNS service.
alt_picture! All-day Support You can always rely on our support. Anytime, day-and-night we are ready to help you with any question with all the patience and without delays.
Application Delivery Accelerate delivery of web applications and non-static content.
Caching Our delivery and acceleration services will lead you to the world's digital threshold, from complete websites to mobile.
Analytics Full and instant visibility into performance of the content and the user experience.
Download Manager Your files are delivered globally with super-fast speed, intelligence and flexibility.
Security Protect your applications and content from unauthorized use with the powerful security tools.
Edge Optimizer Powered by Google PageSpeed, Edge Optimizer keeps your application's data and logic off of your network.
Streaming We will deliver better than anyone else your Flash, Silverlight, or HTTP – live or on-demand.
Storage It is more than just CDN storage. Security, replication, and caching infrastructures really mean massive scale at ultra-fast rates of speed.
Rules Engine With our powerful tool you have the whole control over when, how and if the content is served and delivered.
Piranha Purge Better caching flexibility, efficiency, and performance with Piranha Purge.

High-performance CDN solutions are costly?NOT ANYMORE!

Unprecedented INXY promo will get
you Premium-class CDN

for as low as $10/TB!contact us now

Premium-class CDN solution has never been cheaper!

Unprecedented Promo
will get you CDN from

for as low as $6/TB!contact us now