Depende da qualidade do serviço e reputação do hoster. Geralmente eles possuem ou possuem seus servidores em uma enorme infraestrutura, com ar filtrado, sistemas de failover etc ...
Para um provedor de alta reputação, a probabilidade é bastante baixa de que tudo caia, isto é, seu servidor hospedado + seus servidores DNS.
No entanto, você pode ter uma empresa de hospedagem muito boa que não tome muito cuidado - subestimando - o serviço DNS, seja devido à baixa eficiência do computador ou (mais provavelmente) problemas de largura de banda / roteamento interno.
Por exemplo, enquanto a hospedagem funciona bem, as respostas do DNS podem ser lentas. Normalmente, o tempo limite do DNS chega rapidamente (~ 3 segundos) e os pedidos podem cair para o servidor secundário (etc ...). É sempre irritante para os usuários verem
Looking up domain.com...
na parte inferior do navegador por alguns segundos, enquanto o próprio site veicula as páginas da Web rapidamente (as respostas do DNS são armazenadas em cache por alguns minutos, mas a primeira vez / usuários pouco frequentes ficarão desapontados).
Como uma espécie de conclusão, eu me preocuparia menos com o tempo de inatividade (para uma empresa de hospedagem conhecida) do que com o tempo de resposta do DNS e não hesitaria em ter o DNS gerenciado em outro nível (por exemplo, o registrador ou outra empresa) se as respostas do DNS são lentos.
editar
Adicionando uma maneira de observar o tempo de resposta do DNS
Não é fácil encontrar uma boa ferramenta na Internet. Isso mostra como é subestimada a importância do tempo de resposta do DNS. Este é um pequeno script perl que pode ser adaptado; Preencha o array de domínios com vários domínios. Consideramos que o TTL (basicamente o tempo que um nome de domínio deseja que seja armazenado em cache) seja no máximo um dia - esse é um valor bastante alto.
Você deve garantir que sua estação de trabalho tenha seu resolv.conf definido para os servidores DNS da empresa de hospedagem (ou dig pode ser modificado, mas é melhor fazer o teste do servidor a ser hospedado, acessando diretamente os servidores DNS ).
Queremos ter uma ideia de quão rápido esses servidores DNS responderão ao seu domínio quando forem consultados pela primeira vez por outros servidores / clientes DNS. Embora o DNS de hospedagem deva ter seus domínios em seu cache, ele pode sofrer com baixa largura de banda, roteamento ineficiente, problemas de desempenho, problemas de compartilhamento, 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;
}
O tempo de resposta depende também da velocidade dos domínios almejados - queremos uma imagem global de como se comporta o DNS de hospedagem. O melhor seria executar o mesmo teste de outro servidor DNS (no dia seguinte, por exemplo, caso contrário, o primeiro testador pode ajudar o segundo a chegar alguns minutos depois - no lado dos domínios de destino).
Target
- consistência ao longo do tempo
- após vários testes de servidores diferentes, durante vários dias, não deve haver muita diferença entre o seu DNS e outro DNS.