We're having a site setup at a very good hosting provider, but I'm thinking if its a good idea to transfer the domain name to them as well.
On the pros side, it should be faster + less hassle from the management point of view.
On the cons side, it means all eggs in one basket. Although if the hosting is down, there's no point redirecting the user anywhere...
Any opinions out there on what's the best approach? (a) same provider for both, (b) separate providers for hosting and domain registration
Hosting and domain/DNS services should be separated. This means that you can easily change server providers and transfer all your data to a new location without having to redirect customers. As to reliability, well, if your DNS provider offers multiple nameservers and has a good track record, you should be fine.
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.
edit
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...
#!/usr/bin/perl
# 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`;
for (@r)
{
if (m/^;; Query time:\s*(\d+)/)
{
&log($domain, $1);
}
}
sleep 1;
}
sub log
{
my ($domain,$time) = @_;
open F, ">>$log";
print F sprintf("%6d %s\n", $time, $domain);
close F;
}
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).
Target
I would recommend to separate services as follows: