It depends on the quality of service and reputation of the hoster. Usually they own or have their servers in a huge infrastructure, with filtered air, failover systems etc...
For a high reputation provider, the probability is pretty low that everything falls down, ie, your hosted server + their DNS servers.
However, you may have a very good hosting company that does not take great care - underestimating it - the DNS service, either due to the low computer efficiency, or (more likely) bandwidth / internal routing problems.
For instance, while the hosting works well, the DNS responses may be slow. Usually the DNS time-out comes pretty quickly (~3 seconds) and the requests may fall to the secondary (etc...) server. It is always annoying for users to see
Looking up domain.com...
at the bottom of the browser for a few seconds, while the site itself serves the web pages quickly (DNS responses are cached a few minutes, but the 1st time/infrequent users will be disappointed).
As a kind of conclusion I would worry less about downtime (for a known hosting company) than DNS response time, and would not hesitate to have the DNS managed at another level (e.g. the registrar or another company) if the DNS responses are slow.
Adding a way to observe the DNS response time
It is not easy to find a good tool from the Net. That shows how underestimated is the importance of DNS response time.
This is a small perl script that can be adapted ; fill the domains array with a lot of domains. We consider the TTL (basically the time that a domain name want to be cached) to be a maximum of one day - this is a rather up value.
You must ensure your workstation has its
resolv.conf set to the hosting company DNS servers (or
dig could be modified, but it is better if you do the test from the server to be hosted, accessing directly the DNS servers).
We want to have an idea of how fast those DNS servers would answer your domain when queried for the first time by other DNS servers / clients. While the hosting DNS should have your domains in its cache, it may suffer from low bandwidth, inefficient routing, performance issues, sharing concerns etc...
# Put a lot of domains... better if used infrequently
@domains = ( "google.com","cnn.com","stackoverflow.com","serverfault.com" );
# Change the path to the log file reflecting the response times per domain
$log = "/tmp/dns-log.txt";
# Sleep $sleep seconds per domain, for a day you need (24*3600) / $sleep domains
# if you consider the average (max) TTL to be 1 day. Or increase the $sleep.
$sleep = 60;
foreach $domain (@domains)
@r = `dig $domain`;
if (m/^;; Query time:\s*(\d+)/)
my ($domain,$time) = @_;
open F, ">>$log";
print F sprintf("%6d %s\n", $time, $domain);
The response time depends also on the targeted domains speed - we want a global picture of how behaves your hosting DNS. The best would be to run the same test from another DNS server (the next day for instance, otherwise, the 1st tester may help the 2nd one coming a few minutes later - on the targeted domains side).
- consistency over time
- after several tests from different servers, over several days, there should be no much difference between your DNS and other DNS.