У нас есть настройка сайта у очень хорошего хостинг-провайдера, но я думаю, стоит ли передать им доменное имя.
С другой стороны, это должно быть быстрее и меньше хлопот с точки зрения управления.
С другой стороны, это означает, что все яйца в одной корзине. Хотя если хостинг не работает, нет смысла перенаправлять пользователя куда-либо ...
Есть какие-нибудь мнения о том, какой подход лучше? (а) один и тот же провайдер для обоих, (б) отдельные провайдеры для хостинга и регистрации домена
Услуги хостинга и домена / DNS следует разделять. Это означает, что вы можете легко сменить провайдера серверов и перенести все свои данные в новое место. без необходимости перенаправлять клиентов. Что касается надежности, что ж, если ваш провайдер DNS предлагает несколько серверов имен и имеет хорошую репутацию, все будет в порядке.
Я бы рекомендовал разделить услуги следующим образом:
Это зависит от качества обслуживания и репутации хостера. Обычно они владеют или имеют свои серверы в огромной инфраструктуре с фильтрованным воздухом, системами аварийного переключения и т. Д.
Для провайдера с высокой репутацией довольно мала вероятность того, что все рухнет, то есть ваш хост-сервер + их DNS-серверы.
Однако у вас может быть очень хорошая хостинговая компания, которая не уделяет особого внимания - недооценивает - службу DNS, либо из-за низкой производительности компьютера, либо (что более вероятно) из-за проблем с пропускной способностью / внутренней маршрутизацией.
Например, хотя хостинг работает хорошо, ответы DNS могут быть медленными. Обычно тайм-аут DNS наступает довольно быстро (~ 3 секунды), и запросы могут попадать на вторичный (и т.д.) сервер. Пользователям всегда неприятно видеть
Looking up domain.com...
в нижней части браузера в течение нескольких секунд, в то время как сам сайт быстро обслуживает веб-страницы (ответы DNS кэшируются несколько минут, но пользователи, впервые использующие / нечастые, будут разочарованы).
В качестве своего рода вывода я бы меньше беспокоился о простоях (для известной хостинговой компании), чем о времени ответа DNS, и без колебаний управлял бы DNS на другом уровне (например, регистратором или другой компанией), если ответы DNS будут медленными.
редактировать
Добавление способа наблюдения за временем ответа DNS
Найти хороший инструмент в сети непросто. Это показывает, насколько недооценивается важность времени ответа DNS. Это небольшой скрипт на Perl, который можно адаптировать; заполните массив доменов большим количеством доменов. Мы учитываем TTL (в основном время, когда доменное имя хотеть для кэширования) не более одного дня - это довольно высокое значение.
Вы должны убедиться, что на вашей рабочей станции resolv.conf установить на DNS-серверы хостинговой компании (или dig может быть изменен, но лучше, если вы проводите тест с сервера, на котором будет размещаться, напрямую обращаясь к DNS-серверам).
Мы хотим иметь представление о том, насколько быстро эти DNS-серверы ответят на ваш домен при первом запросе от других DNS-серверов / клиентов. Хотя DNS-хостинг должен иметь ваши домены в своем кеше, он может страдать от низкой пропускной способности, неэффективной маршрутизации, проблем с производительностью, проблем совместного использования и т. Д.
#!/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;
}
Время отклика зависит также от скорости целевых доменов - нам нужна глобальная картина того, как ведет себя DNS вашего хостинга. Лучше всего запустить тот же тест с другого DNS-сервера (например, на следующий день, в противном случае 1-й тестер может помочь второму, который придет через несколько минут - на стороне целевых доменов).
Цель