Да, именно с этим. Проблемы (вполне решаемые подходящим масштабированием сервиса) это вызовет только для масштабного dns-хостинга, а не для пары доменов.
Никаких проблем. Если, конечно, все безопасно устроено. В частности, рекурсивные запросы кому попало снаружи не позволено делать.
Например?
А как еще действовать в отношение клиентского ПО, если оно стандартам не следует? Это проблемы пользователей. Вы не можете запретить клиентскому ПО кешировать зону вплоть до бесконечно долго, игнорируя TTL записей. Просто те, кто делает подобное игнорируя стандарты - вполне ССЗБ.
Это - да. К сожалению, не все парковщики DNS такое позволяют. Так что предпочтительнее вариант смены критичных IN A записей (TTL которых мал) предварительно и затем - делегирование на новые NS-сервера (ежели их надо сменить, и тут уже неважно как долго это длится).
Я в курсе. 2 минуты и 10-15 есть разница?
Унести их на нормальный провайдеровский сервер. Поддержка зоны стоит копейки.
Какие еще рекурсивные запросы на auth dns? То, что плохая конфигурация - это и ежу понятно.
"Все эти кеши" должны руководствоваться тем, что в TTL для домена указано, для отдельных записей в том числе.
Это каким образом?
Думаете я буду рекламировать какого-то конкретного провайдера? Да нет - не буду. Любой крупный хостер решает подобные задачи для своих клиентов.
Вы о чем? Кеширующие DNS плюют на настройки TTL записей что-ли? Бывает такое, конечно. Но это уже не техническая проблема, если люди не следуют стандартам.
Если Вы о изменении NS-записей (домен делегируется на другие ns-сервера) - это занимает до 72 часов по стандарту. Чтобы это не вызывало проблем для работы сайтов и т.п. - просто размещайте при переносе зону в точности так, как она была на старом сервере (за исключением NS-записей).
Что значит "резервный dns"? В dns некоторым образом встроено резервирование. Сколько захотите slave-серверов разместить - столько и делайте.
Можно и поболее - 120 далеко не 10 минут, о которых писали выше.
Какая роль у этого проекта? WEB-сервер + DNS "сбоку припека"? Что конкретно там может создавать нагрузку? По сравнению с GET/POST HTTP запросами, DNS - это копейки.
Унесите NS на нормальный DNS-хостинг. Раз знаний не хватает - доверьте тому, кто умеет.
Насколько большой? В сравнение с чем?
Или только "слышали звон"?
т.е. бесплатно будете разбираться - получил ли злоумышленник root-доступ на клиентской VPS (вероятно, о VPS шла речь у ТС, а не о физическом сервере) и как именно?
Вполне разумно.
Т.е. если клиент просит что-то сделать на его сервере - это как минимум, оплачивается дополнительно, исходя из потраченного администраторами времени. Верно?
Вот не надо так делать.
1) Протестировали работоспособность сайта - меняйте IN A записи, чтобы они указывали на IP адреса нового сервера. Это достаточно быстрая процедура - TTL для IN A записей обычно небольшой ставят, порядка 10 минут. И не важно где Вы держите NS - на VPS-1 или у стороннего парковщика доменов.
2) Только если держите NS на VPS-1 и этот сервер планируется отключить - можно перенести поддержку NS домена на VPS-2. Для этого - разместите там в точности такую же зону (различия должны быть только в адресах ns-серверов, остальные записи - прежними). И делегируйте домен на VPS-2. Никакого простоя на этом этапе не возникнет. Примерно через 3 дня - можно выключать VPS-1.
N.B.:
Встречал парковщиков, которые ставят _огромный_ TTL для IN A записей. Пример:
;; ANSWER SECTION:
reg.ru. 86352 IN A 217.16.28.63
Столько секунд это порядка 24 часов.
Если это Ваш случай - все сложнее.
Роботы долбятся на стандартный порт. Смените его - долбиться перестанут.
Сама, эт конечно хорошо. Но то, что "ребята" Вам дают пробовать - характеризует их не с лучшей стороны :) Исправлять результаты кривых рук владельца сервера - себе дороже. Хотя хз - может с Вас втридорога дерут за поддержку на таких условиях...
