managed dns services general information

fyi: managed dns services -

dns service independence

Managed dns hosting services help domain name owners maintain independence from failures and shortcomings in other services. While it is common for smaller sites to run their dns servers on the same server as their other services, it is not a good idea. Using the same single server means that the dns servers listed with the registrar are not geographically distributed and constitute a single point of failure. In addition, response time can be degraded by the competition for resources with other services on the server.

Managed dns hosting services are also valuable in the process of server migration. Because the name servers specified for the domain do not change, propagation of changes to address records can propagate in seconds. On the other hand, self hosted domain servers would require that the registered name server records be changed and propagated throughout the internet. This process usually takes several days. During that time, users will experience difficulty in connecting to your servers.

authoritative dns from a user perspective

It is a common misconception that end user applications interact directly with authoritative name servers for a dns zone. This is not the case. The process for the end user application, such as a web browser is typically:
  • user types url into browser
  • browser requests dns answer from a isp provided caching dns server
  • isp caching dns server returns answer if available from a previous query, otherwise
  • isp dns server requests dns name server records from root servers
  • root dns servers refer the request to the appropriate tld servers
  • isp dns server repeats request to tld server for name server
  • tld dns server returns known name server records for request
  • isp dns server repeats request to authoritative dns server for the dns zone
  • authoritative dns server for zone returns requested record
  • isp dns server returns dns record to end user computer

The important points are that the end user computer never contacts the authoritative server, and that the isp caching dns server will cache known answers for some period of time.

dns, spam and email

DNS services are heavily used by many spam detection systems. The additional load is caused by dns lookups for address records, mail server records, spf records, and reverse records. These queries are made on every delivery attempt received by an email server. Before the advent of unsolicited bulk email, these sources of dns queries did not exist. As a result, dns servers must support a much heavier load than they did in the past.

dns response latency

Some vendors highlight response latency as a reason for implementing anycast. Response latency only directly affects a user of web site services. As described above, the end user is insulated from response latency of authoritative servers by the presence of caching dns servers. Thus, the response latency experienced by an end user is much more dependent on the size and freshness of the cache maintained by the isp dns server. The primary concern of authoritative dns servers is accuracy and dependability in processing arriving dns requests. Any response latency effects are mitigated by the isp caching dns server.

dns record propagation

DNS record propagation is controlled by a freshness value known as ttl, or time to live. Caching dns servers, client resolvers and client applications are expected to examine this value and refresh the value upon expiry. However, it is known that some internet service providers have configured their caching dns servers to ignore this value. The impetus seems to be to lighten the load on their servers. This comes at the expense of accuracy. Certain sites with special requirements use small values for the ttl in order to dynamically point clients at the required location. An additional use of short ttl values is to force the discarding of older values during a planned server migration from one address to another.

dns glue record considerations

DNS glue records are address additional records associated with name server records returned by name servers. The most common use is for name server referrals by the root and tld servers. Glue records serve to associate an internet address with a name server registered as the name server for a domain.

However, out of zone answers do not include glue records. An example of an out of zone query is a domain in the .com tld that has nameservers in the .org tld. Because the .com servers are not authoritative for .org, they can only return the name server names. The querying dns server must then start at the root servers again and lookup the .org tld servers and query them for the name server for the .org domain. Additionally, it must then query the authoritative server for that domain for the address records associated with the name of the .com name name servers. Thus, without the glue records, an additional four lookups are required.

A dns hosting service provider can avoid this on behalf of its clients by registering name servers in multiple tld zones. This allows customers of the dns service to register a name server within the same tld as the customer domain.

monitoring services

The health monitoring service monitors http, https, and smtp services by direct interaction with the protocol. Other services may be monitored using icmp echo requests, otherwise known as ping.

sms and pager alerts

You can have alerts sent to any email address. Just set up an additional alert recipient using the email address provided by your cell phone or pager service provider. To find out if free email access to your sms phone or pager is available, check with your service provider. You can also check this list of carrier free email to sms address formats If this facility is not available through your carrier, receiving sms alerts will require arranging sms credits with us.

failure alert schedules

Subscribers have full control over the timing of alert transmissions.

Configurable options include:

  • email and sms alerts
  • alert recipients
  • alert trigger delay
  • alert repeat frequency
This ensures that only valid alerts are sent, that the alert is sent via the most suitable path, and that escalation channels are automatically invoked.

easy setup and administration

There is no software to install and it makes no difference if you are running Apache, IIS, Sun or Zeus. All of the software runs on our servers. All a subscriber needs is a web browser to access the control panel and a way of receiving email or sms alerts.

http status codes

Status codes in the 100,200,and 300 series are interpreted as successful responses. Status codes in the 400 and 500 series are interpreted as failures. The absence or status codes in any other range are interpreted as failures.

double opt-in account verification

All subscriptions, including add-in subscribers, are verified by requiring acceptance and verification using a uniquely coded response from verification emails sent by the subscription management system.

uptime at has listed its servers for independent third party uptime monitoring at To see our stats, click here.

five nines uptime calculation

Calculating five nines uptime is not always an easy task for everyone since it involves mixing percentages, decimals and time conversions in the same calculation. A precalculated chart of the actual times that varying levels of percentage uptime imply is located here.

geoip and geolocation synonyms

The terms geoip and geolocation are not yet well established as terms for geographically aware dns. Other terms that have referred to the same concepts are geo-directional dns, directional dns or simply geo-direction. Another vaguely descriptive term previously seen is dynamic custom dns. When combined with balancing capabilities, it has also been called GSLB, global server load balancing.