хай!

ситуация:
домен на своих днс, допустим фри
домен направлен на одно айпи

изменяем айпи на другое, в результате сайт находится в дауне в течении 9 часов, то есть идет обновление айпи.

вопрос в том, можно ли поиграть настройками днс, ttl , refresh и т.д. для ускорения этих 9 часов, или это не имеет отношения к теме?

если не имеет, то как на днс можно прописать чтобы в случае обновления айпи на ns1.dns.ru
сайт временно брался с ns2.dns.ru , я так понимаю надо на ns2 прописать дополнительное айпи, но как это указать в днс?
(в этом случае при обновлении айпи на нс1, сайт не будет в дауне и будет браться с нс2)

Да, можно поставить быстрый рефреш и потом сменить ip, но даун на минту 15 все равно будет.

заметной части DNS серверов чихать на то какой TTL стоит - они запомнили и будут хранить в кеше сколько им ведомо. ( как и зачем они это делают - не знаю).
P.S. а кому не влом написать статью - перенос домена с минимальным временем простоя сервисов .. ?

Что-то мне подсказывает, что eSupport.org.ua это по силам.

Можно вообще без простоя, но понадобиться доступ к редактированию DNS на хостинге. Оно есть?

Denz, если НС-сервер не меняется, а меняется только IP, никакого дауна вообще не будет, меняете IP - и все сразу работает, если меняется NS-сервер - тогда на старом делаете перенаправление записью А на новый IP-адрес.

Ага...Только часть посетителей будет попадать на старый IP ) Т.к. есть такая вещь, как кеширование.
И если на старом IP вашего сайта уже нет, то пользователь увидит ошибку.

а какой именно за это отвечает?
вот этот видимо:
SOA Parameters
Refresh period 10800

или
Default TTL
Negative caching TTL





ну да есть, точнее есть свой днс, редактировать можно всякие ттл, рефреы, кеши и тд.
вот только вроде бы нельзя записать на второй нс другое айпи как резерв, или я просто не знаю как это делать, но страховка такая была бы хороша.



ну да вот в этом все и дело, что пока там все прописывается, кешируется несколько часов, сайт в дауне так как по старым айпи его нет.

тема ушла, а вопрос был важный - что сделать, чтобы при смене ip в а-записи изменения для конечного польщователя проходили как можно быстрее? У меня, например, на такое уходит порядка 9-13 часов.

Давайте уточним - кто Вы? - хостер, клиент хостера, пользователь VPS, пользователь ресурса? - и где не меняется IP для А в авторизированных ns серверах вашей зоны, в серверах у клиентов ресурса ?

Понял процентов 40 Вашего поста
Но попробую ответить: я - человек. У меня дома есть интренет, у моего интрнета есть провайдер со своими днс-серверами. Я, по совместительству (для примера) Администратор некоего ресурса. Имею доступ к файлу domain.tld.db .
Что мне в нем начиркать, чтобы сменив ip адрес для а записи на домене мне не ждать 9-13 часов, а произошло все почти мнгновенно? и возможно ли такое? При этом в кэшэ провайдера уже хранится старый ip/

При миграции с сервера на сервер (или vps, не суть) с root доступом, удобно ставить их в днс кластер. в этом случае сразу после переноса днс сами изменяют A запись на новую. NS при этом не меняется, так что клиенты вобщем сразу ходят на новый сервер (за исключением случаев кеширования на стороне самого клиента, но тут ничего не поделаешь, если только заранее поменьше ttl поставить).

тут проблема как раз в кешировании.
Как аставить милейший inetcomm.net не держать неделями зоны?
Обычно скандал по телефону к суппорту помогает.
Но хочется без крови

Как вариант - использовать не их днс сервера Свои или какие-нибудь стороние.

а какие проблемы сделать редирект портов на старом ай-пи? и забить на кеши совсем. rinetd либо форвардом в iptables (правда там заморочно, обходился rinetd).

человек имеет доступ в файлу зон, а не серверу вообще. Вот Вы, провайдер, если от Вас клиент уезжает сделаете ему редирект портов ? И кроме того это попадалово на траф заметное.

можно скриптами и mod_rew сделать для HTTP, пересылкой для почты ( поднять заранее новый домен типа new.domain.com)
Чтобы провадер не кешировал ДНС на вечно - только полить его сервера его же кровью ...

MIRhosting, так и делаю, но всей аудитории сайта - городу - не поменять на opendns
rustelecom, а что делать с остальными сайтам, лежащими на том сервере?

Есть люди, хорошо помнящие RFC по DNS ? ( искать и читать влом) - на какое минимимальное значение TTL обязан реагировать кеширующий сервер ? - если поле есть в стандарте прописано, вероятно

Такое ощущение, что каждый написал всё, что он знал на близкую _ему_ тему. А вовсе не ответил на вопрос ТС... Хотя из его вопроса и не совсем понятно -- какая именно перед ним стоит задача.

Два разных варианта:

• переключение происходит с работающего сервера на работающий и
• переключение происходит с неработающего сервера на работающий

Предположим, что второй сервер -- всегда работающий (иначе чего бы на него переключать?).
Первый может быть либо в рабочем состоянии, либо в упавшем. В первом случае от него ещё можно ждать помощи.

ТС, похоже, больше интересовала вторая ситуация: что предпринять, если сервер не отвечает, если есть рабочая копия сервера, и если есть возможность указать серверу имён новый адрес.


В общем случае: невозможно.


Как раз по этой причине.


И при чём здесь кластеры?


В общем случае: не ходят.


Как было справедливо замечено, у части серверов имеется своё представление о том -- как надо использовать этот параметр. И это представление отличается от ожидаемого.


Если сервер (с которого уходят) -- живой, то он может помочь. Если только HTTP трафик надо перенаправить, что можно просто перенаправить все запросы на новый сервер (с помощью Location, JavaScript, простого перенаправления и т.д.). С почтой -- ещё проще: заранее добавить нужную MX-запись.

А если хотят уйти с лежащего сервера, то все запросы по его закешированному (старому) адресу будут приходить на этот лежащий сервер. И от этого никуда не деться.

кроме dns кластера со всем согласен:
кластер для тех кому лень каждый раз передергивать руками вторичную зону ( не ждать пока сервер сам доберется до надобности ее перезагрузки 10 - 15 мин) - (можно еще поставить извещения с ключами)

Поскольку никто не вспомнил - пришлось лазать в RFC 2308 и искать самому.
Минимальное значение $TTL для записи - 0 ( запрещено к кешированию вообще) - проделал эсперимент все что попалось под руку чихает на эту инструкцию ( время жизни кеша составило 3 - 5 минут в среднем).
У одного провайдера попробовал через его панель управления установить TTL для записи ( поле там есть и доступно ) - это не повляло ни на что . ( в том числе на идею перегрузить зону - раз в 30 минут перечитывается зона и все тут). - провайдеру написал злобное письмо о TTL и том что неплохо его бы отдавать тоже...
В панелях управления стандартных не увидел как изменить TTL для зоны в целом (: ... ( кругом бардак)

Типично стоит:



Рестартуем Бинд.
Всё, желательно после этого подождать 24-48 часов пока обновится большинство заинтересованных в ДНС клиентов.
В результате создали неплохую нагрузку на ДНС сервер, так как заставляем обновлять данные каждую минуту и убиваем зону каждый час.
После переходного периода, меняем IP и делаем всё обратно. Особенно важно опять поменать на + единицу номер зоны. Иначе обновление данных затянется

Клинты Вашего хостинга имеют доступ к редактированию SOA ?

На cPanel реселеры да. На ДА нет. Я сам везьде root имею, так что мне не совсем понятны проблемы
Говоря серьёзно, тогда есть другой путь - с перва перекинуть DNS на новый хостинг, где администратор при загрузке новых клиентов будет заинтересован сделать нужные записи. А потом уже переносить всё богатсво
Я не пониомаю, почему создатели панелек управления не дают возможности для продвинутых пользователей дать возможность полностью управлять днс записиями....

в ДА как раз есть - DNS control. А вот в спанели нет. Хотя в общем можно дать продвинутому пользаку ресовские права - ограничив все кроме редактирования днс.

PS. насчет вопроса - ну какой вопрос такой и ответ. вопрос поставлен неточно и ответы соответственно "по площадям". Ай-пи меняются на корневых очень шустро как правило. Остальное это днс кеш который полечить сложно поскольку у инет провайдеров как правило зоны апдейтятся раз в час как минимум а то и раз в несколько суток. и все это время для посетителя с этого провайдера сайт будет недоступен. и никак это на стороне днсок сервера или внешних не решить. только редиректом со старого ипа на новый...

Это так называется. SOA не изменяется. В ДА не возможно ни на одном уровне нормально редагировать ДНС. Дешёвый и в Африке дешёвый

Те параметры что указал, как раз и говорят о том, на сколько часто ДНС интернет провайдеров обязаны получать данные этой зоны. То что часто у провайдеров криво настроенны ДНС сервера, это другой разговор.

помоэтому самый толковый ответ

на кеш влиять вообще очень трудно и стоит ли вообше этим заниматся..., поэтому проше поставить редиректы, посколь в основном речь идет о http, ftp и mail трафике, значит редиректы сделать не так уж сложно...

Самый грамотный ответ - поручите это провайдеру к которому переезжаете - от лицо заинтересованное.