General
What is Route?
Route is a solution through which all of your DNS needs can be met. It provides the means through which you can administer primary and secondary DNS zones. It also provides the means through which you can define how traffic will be distributed to your servers.
What is the difference between the various components of the Managed (Primary) or Secondary DNS module?
A component is a category used to identify the rate at which DNS queries will be billed for a particular zone. Each component identifies the level of functionality that can be applied to DNS requests for that zone. The functionality that distinguishes these components is described below:
The following table indicates how zones are categorized into billing components:
How will I be billed for Route services?
Route billing varies by module and component. Billing information for each module is provided below.
| Module | Activation | Billing Method |
|---|---|---|
|
Managed (Primary) or Secondary DNS |
A zone is not considered billable until it has been queried. A zone will remain billable until it is deleted. |
A recurring monthly charge will be applied to your account. The amount that will be charged to your account is calculated by adding the following fees:
|
|
DNS Health Checks |
A health check configuration is considered billable upon creation. |
A recurring monthly fee will be applied to your account. This monthly fee is calculated by multiplying the average number of health check configurations by a fixed rate. |
Managed (Primary) or Secondary DNS
Why are there default records in my zone?
Those records are required by our Route solution to serve your zone. A default set of address and name server records identify our vanity name servers.
Primary zone example:
Secondary zone example:
What are vanity name servers (e.g., ns1.example.com. or s1ns1.example.com.)?
Vanity name servers identify the set of zone-specific name servers through which DNS queries for your zone may be resolved. Vanity name servers lend a professional appearance to your site's DNS.
Primary zone example:
Secondary zone example:
Primary Zone: Do I have to use vanity name servers when delegating a domain?
No. You may use our Route-branded name servers instead. This involves the additional step of adding address and name server records required to support those name servers to your zone.
Primary Zone: What are the steps involved in setting up DNS for my domain?
The recommended procedure through which you can set up DNS for your domain is:
-
Create a DNS zone. Make sure to set the Name option to the desired name.
Example:
example.com -
Create the desired records for your new DNS zone.
For example, address records (i.e., A or AAAA) allow our name servers to resolve a hostname to an IP address.
-
Verify your DNS configuration by performing a dig on each desired domain.
Example:
dig example.com @ns1.edgecastdns.net -
From your domain registrar, delegate your domain to CDN by setting up glue records for our vanity name servers.
An alternative setup is to define glue records for our Route-branded name servers. However, this type of configuration requires adding records to your zone and DNS testing tools may warn that stealth name servers were detected.
Once this change takes effect, DNS queries for your zone's domain will be resolved by our name servers.
What is domain delegation and how is it done?
In order to resolve DNS queries, a name server must be authoritative for the zone corresponding to the requested domain. This requires that you access your domain registrar account and point your domain to the desired name servers. This process is known as domain delegation.
Secondary Zone: What are the steps involved in setting up DNS for my domain?
The recommended procedure through which you can set up DNS for your domain is:
- Create a master server group that identifies your master name servers.
- Create a secondary zone group that identifies the zones that will be transferred from those master name servers.
- Verify that your records have been successfully transferred to our DNS service.
-
Verify your DNS configuration by performing a dig on each desired domain.
Example:
dig mydomain.com @s1ns1.mydomain.com -
Register our vanity name servers to your DNS registrar.
Once this change takes effect, DNS queries for your zone's domain can be resolved by our name servers.
- Make sure that our Route transfer system is allowed access to the appropriate master name servers.
What are best practices when defining a record's TTL?
A record's TTL determines the amount of time that a record will be cached on a recursive name server.
Please consider the following factors when setting a record's TTL:
-
Long TTL: Setting a long TTL allows recursive name servers to cache the record longer. This will reduce DNS latency, since the recursive name server will not need to resolve it via our name servers.
Our global presence combined with our technology ensures the quick and efficient resolution of DNS queries regardless of where the recursive name server is located.
-
Short TTL: Setting a short TTL provides more DNS flexibility. This means that changes made to DNS records can quickly propagate to all recursive name servers.
A short TTL generates more DNS queries on our name servers. The total number of DNS queries handled by our name servers is taken into account when billing your account.
Traffic Management
Can I load balance or fail over traffic to my servers?
Yes. Traffic can be managed in the following ways:
- Primary Zone: Traffic can be managed between servers identified by address records.
- External CNAME Record: Traffic for a CNAME record in a zone owned by a different DNS service provider can be managed by Route. Simply create a load balancing or failover configuration, define the set of IP addresses to which traffic will either be load balanced or failed over, and then point your CNAME record to our name servers.
- Subdomain Delegation: Traffic for a subdomain of a zone owned by a different DNS service provider can be managed by Route. Simply create a load balancing or failover configuration, define the set of IP addresses to which traffic will either be load balanced or failed over, and then update your domain registrar to resolve that subdomain to our name servers.
Can I administer traffic for a subdomain without transferring it to Route?
Yes. Simply create a load balancing or failover configuration for the desired subdomain and then update your DNS service provider's configuration for that subdomain to point to our name servers:
ns1.edgecastdns.net.
ns2.edgecastdns.net.
ns3.edgecastdns.net.
ns4.edgecastdns.net.
What is a recursive name server and how does it affect traffic management?
If a user's DNS request cannot be resolved on the local computer, then it will typically be sent to a recursive name server. A recursive name server reduces DNS traffic and improves performance by caching the response provided by an authoritative name server for the length of time defined by a record's TTL. This means that the DNS response generated for a record that has a long TTL will remain cached longer on recursive name servers. In turn, this reduces the effectiveness of your load balancing or failover configuration, since users will have to wait for the TTL to expire before our authoritative name servers can direct them to a different server. Therefore, a short TTL is strongly recommended for load balancing and failover groups.
Health Checks
What type of monitoring can be performed on my servers?
Our Route solution offers health check capabilities that allow us to monitor your servers on a 24x7x365 basis for a multitude of DNS and performance-related factors. Key factors include the following items:
- Response time
- Number of queries
- Types of queries
- Excessive queries per second from a specific recursive DNS system
- Memory usage
- CPU usage
How often will my servers be monitored?
The number of health checks that will be performed on your servers is determined by your load balancing or failover configuration. Health check frequency is completely customizable to fit your needs.
How do I filter out health checks from my traffic analytics?
Filter out traffic for the following user agent:
When is a server considered down or unavailable?
If your server is being monitored, then a simple majority consensus of our health check servers assess the server's current state. If a majority of health check servers consider your server to be unavailable, then traffic will no longer be served to it. This will result in the redistribution of traffic to other servers in the same load balancing or failover configuration.
When is a server considered to be back up?
It depends on whether you have configured your load balancing or failover setup for automatic or manual reintegration.
- Automatic: A simple majority consensus of our health check servers assess the server's current state. If a majority of health check servers consider your server to be available, then its status will be updated and traffic to it can resume.
- Manual: Your DNS configuration must be manually modified to indicate that traffic to that server should resume.
How should I configure my firewall to allow health checks?
Configure your firewall to allow traffic for the IP addresses associated with our Health Check servers.