managed dns services general information

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.

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

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

Configurable options include:

• email and sms alerts
• alert recipients
• alert trigger delay
• alert repeat frequency

• the site address is resolved using a DNS query to a caching DNS server
• a http connection is made
• a http request is sent
• the http result code is examined
• the html page is downloaded

The goal of public facing web sites is to make sure that the site is available at all times to external users. External monitoring is best suited to ensuring that this goal is met because it uses external access routes just like external users and are independent of the facilities being measured.

Furthermore, as an independent data source, it is useful in discussing service difficulties with network and hosting providers.

It is perfectly acceptable to retain your usual email address as the default destination for reports and backup warnings.