Как стать автором
Обновить

Комментарии 43

НЛО прилетело и опубликовало эту надпись здесь
К сожалению, это практика всех регистраторов — удалять домен с собственных ns при переносе. Защититься на 100% можно предварительным делегированием на другие серверы.

Ну и transferPeriod — это уже состоявшийся перенос. Если в течение x-дней его не отменят, с нового регистратора снимут деньги за перенос, и, видимо, Internetbs ожидает этого, чтобы окончательно дать порулить доменом.
А есть ли какие-то технические сложности в том, чтобы прописать свои NS на домен в статусе transferPeriod?
По WHOIS они уже действительно управляют доменом.
Никаких преград нет, но новый рег, видимо, не хочет или не умеет (ждет статуса ok).

А старый рег мог бы поднять зону до окончания переноса…
Мог бы. Уже портянка переписки и несколько звонков. Не можем/не умеем/невозможно.
Сейчас уже до совсем простой задачи довел. Создал у них «Off-site» bits.media, прописал DNS записи нужные, единственная проблема — система по-умолчанию другие NSы ставит и не дает их сменить. Вот пытаюсь убедить Godaddy, что сменить две текстовые строки в их системе на две другие строки это вполне посильная задача.
Знал бы где подстелить, подстелил бы)

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


И, на самом деле, самое время подумать, что проблема может подстерегать не только с DNS.
Поговорку "админы делятся на тех, кто ещё не делает бекапы и тех, кто уже делает" можно расширить до такого вида: "админы делятся на тех, кто ещё не наступил на %rakename% и тех, кто уже наступил".
(только что узнал, что rake — грабли с англ).
Почаще спрашивать себя "что будет, если что-то пойдет не так", и подстилать соломку, если будет что-то нехорошее.

Соблюдать двойную осторожность это одеть шапку с шарфом а поверх еще и скафандр?
Или, что конкретно, что вы посоветуете делать в данной конкретной ситуации?
Соблюдать двойную осторожность это одеть шапку с шарфом а поверх еще и скафандр?

Это просто оборот речи.
Можно прикинуть возможные варианты развития событий и максимальный ущерб от самого неблагоприятного исхода.
Потом посмотреть затратность "подстилания соломки" для неблагоприятных вариантов, в деньгах, времени, суете.
Если окажется, что самый разрушительный сценарий можно заранее легко предотвратить малыми расходами, почему бы так не сделать?
Это что-то типа Критерия Сэвиджа, для принятия решений в условиях неопределённости в теории игр.


Или, что конкретно, что вы посоветуете делать в данной конкретной ситуации?

Тут нет никакой магии, автор в статье сам написал, что нужно было бы сделать:


Мудрые админы-ветераны говорят, что не по фен-шую вообще использовать DNS регистратора, надо или сторонний сервис, или свои держать NS серверы.
Ох. А у меня был опыт переноса домена от российского регистратора.
Но там все было ещё веселее. Документы, инициализирующие перенос они принимали почтой РФ.
Это было в прошлой жизни. С сентября перенос стал электронным как в gtld, всё как у людей ))
Не для .su. Благо партнеры регистратора в моем захолустье нашлись.
Так и Soviet Union уже не существует, тут проблемка ))
Godaddy, www.networksolutions.com и куда других компаний так делают.
ps один мой домен висел 6 дней, перенос был от networksolutions.com и все 6 дней я получал от них письма с предложением воспользоваться скидкой и вернуться. Причем в конце скидка на 1 продление выросла до 50%
Зеркала сайтов нужно заводить на случаи всевозможных форс-мажоров.
Зеркала надо чтобы пользователи знали.
Я в социалках объявил, что нужно в hosts прописать, чтобы сайт заработал. Какое-то количество пользователей справилось.
> Зеркала надо чтобы пользователи знали.
А кто запрещает сообщить пользователям о наличии зеркал на главной странице и в социалках? Только делать это надо до переноса доменов, а не после.

> Я в социалках объявил, что нужно в hosts прописать, чтобы сайт заработал. Какое-то количество пользователей справилось.
Это уже после «пожара», что весьма неадекватно. К тому же посетители сайтов — не вебмастера и для многих из них привязка IP сайта к домену в hosts не является тривиальной задачей.
НЛО прилетело и опубликовало эту надпись здесь
Раз есть связь с посетителями через социальные сети, то, наверное, проще (для посетителей) было сделать временный домен (самый дешевый) или поддомен (на имеющемся в распоряжении домене) и сообщить его адрес аудитории.
Напишите здесь пожалуйста, что писать в hosts, не нашел Вас в соцсетях.
А в идеале — инструкцию, как это сделать на MacOS.
Спасибо!
176.9.19.12 forum.bits.media
78.46.244.226 bits.media

А вот Mac под рукой нет, сорри(
Речь идёт о файле /etc/hosts
Чтобы его поправить, в терминале наберите sudo nano /etc/hosts и добавьте в конец файла 2 указанные выше строчки. После сохранения изменения применяется сразу, никаких перезагрузок не нужно.
Думал, что сейчас начнут смеяться над моим ламерством, а получил развернутый ответ на свой вопрос. Спасибо огромное, все получилось.
Купите у того же Godaddy DNS хостинг на 1 месяц, стоит копейки, и ЕМНИП на тех же ДНС-серверах.
Заведите нужные записи и пусть работает до окончания переноса.
Мысль интересная, уже вчера пытались сделать. Есть у Godaddy в панели такой пункт как Off-site. Но при добавлении домена таким образом выдаются другие, т.н. временные NS серверы. Установить нужные самостоятельно нельзя. Звонили в поддержку, поддержка по традиции ничего не может.
Купили услугу Premium DNS, но тут никакая полезная в данном случае функциональность не добавилась.
Как я понял по комментариям, один из способов защититься от таких переносов — перед переездом перенести зоны на, например, Яндексе, и установить время жизни в несколько суток?
Самое действенное, прописать в SOA зоны большой период TTL, чтобы она не вымывалась с серверов. По завершении переноса вернуть TTL на разумное значение.
Сколько, неделю ставить?)
Теперь конечно буду иметь ввиду, что такое может быть при переносе. Но большинство людей о таких возможных проблемах не задумываются, потому что ситуация явно не стандартна, и что-то у кого-то из регистраторов пошло не так. Перенос давно должен был успешно завершиться.

Вот, надеюсь мой пост будет полезен кому-нибудь, кто собирается домены переносить. Что и вот такие подводные камни могут еще вдруг обнаружиться.
Ну в этой ситуации это и была бы та соломка, конечно бред, что достаточно простая процедура прошла так коряво, но… это хоть немного, но помогло бы.
После всего этого веселья не пропало желание с Internetbs связываться?
У всех свои особенности. Но тут сейчас какая-то жесть. Internetbs перестал отвечать на письма более двух дней назад:



А вот такие результаты получаются, когда регистраторы не могут договориться:



Похоже, у обоих саппортов четкое намерение дотянуть до окончания переноса ничего не делая.
И если у Godaddy позиция «не можем/не умеем/невозможно», то Internetbs похоже открыто издеваются.
Посреди переписки спросили, о каком домене вообще речь. После этого прислали инструкцию как менять записи в их панели, будто она позволяет это делать, и всей предыдущей переписки не существовало.

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

Bella Kinch
Internet.bs — Support Team
А Godaddy тем временем отличается спамом, засыпали ящик предложениями.
Особенно письма типа «We make it easy to transfer your domain to us.» радуют.
Продолжаю вести лог событий. Сегодня утром домен перешел из статуса transferPeriod в статус Ok по WHOIS самого internetbs.

Но это ничего не изменило в панели управления internetbs, там по-прежнему значится статус «Pending transfer» и невозможно что-либо изменить.

У меня есть твердое убеждение, что ошибка произошла еще 3 ноября, когда перенос должен был завершиться после подтверждения обоим регистраторам. Но саппорт internetbs успешно морозился 5 дней в надежде, что само рассосется после смены статуса домена. Не рассосалось.
Аплдейт: около полуночи с 9 на 10 число пришло письмо от internetbs, что домен перенесен.
Ни объяснений причин сбоя, ни извинений. Зона девственно чистая, не перенеслась. При штатном переносе домена она тоже сохраняется. Хорошо, что был бэкап файла зоны.

Итог: неделя даунтайма для сайта на ровном месте.

А с чего вдруг должна сохраняться зона? Как вы себе это представляете?


Вы давали права на AXFR/IXFR для новых DNS перед переносом для клонирования зоны? Нет, и не могли, если использовали сервера регистратора.

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

Только если два соответствующих регистратора имеют специальные договорённости, но это совсем не означает, что


При штатном переносе домена она тоже сохраняется.
Конкретно между этими переносил, и проблем раньше не было. Сорри что не уточнил, это не общий случай имелся ввиду.
переносил недавно 47 доменов разом с одного регистратора другому. выделил, запросил коды, запустил перенос.
ребята из тех поддержки в тиккете скинули весь список кодов для трансферта. процесс запустился.
1) на всех доменах были строго прописаны мои ДНС. держу два: один в стойке с серверами моего хостинга, второй в другой стране на минимальной VPS. Был случай когда грохнулась связь с ДЦ и моей стойкой соответственно. И тут как бы не классно работали сервера, домены тоже перестали отвечать. Теперь страхуюсь. Понятно, что если стойка опять упадет, сайты работать не будут. но у клиентов есть куча поддоменов, которые ссылаются на другие стойки в других ДЦ. Хотя бы так.
2) процесс длился почти ДВЕ недели. несколько раз писал технарям как в новый так и в старых хостинг. отписки такие же как у вас. первые — мы уже отдали. вторые — мы еще не получили.
Интересно, что старый хостер звонил пару раз, уточнял почему так сразу и все увожу от них, предлагал скидки.
А смысл менять регистратора?
Насколько сильно условия отличаются?
Цены вроде по 500 р в мес за домен, а простой в неделю может убытки в разы больше принести и на перспективу.
Проще может договариваться типа у того товарища по 450 хочу скидку?
могу про смысл ответить по моему мнению. нам в работе очень понадобилось интегрировать управление доменами со своего биллинга. когда обратился к старому регистратору, был отфутболен, типа зачем нам такое нужно, у нас свой кабинет пользуйтесь. обратился к их конкурентам, те обеспечили своим API, дали кучу рекомендаций и чтоб уж совсем убедительно выглядело, да, дали скидку на регистрации и продление. когда покупаешь пару доменов и продлеваешь их раз в год разница небольшая с кем работать. когда их пара сотен, очень важны и фин. условия и на первом месте тех. реакция на проблемы. в том числе такие, как в этом посте.
Была у меня история с переносом от reg.ru на internetbs. Весь корень зла заключался в том, что reg.ru присылал мне неверный код трансфера. Высылался он автоматически, по запросу из панели управления. Три дня я доказывал тех.поддержке, что я не идиот и ввожу код правильно, но он не подходит. Пока один из менеджеров не решил таки спросить у меня этот код, который я безуспешно пытался ввести. Я выслал, на что получил ответ, что код неверный. Ну что ж, отлично, подумал я. Потом доказывал со скринами, что сей неверный код мне выдает их система на автомате. На все эти переписки ушло где-то 4 дня. В итоге код мне все таки выдали в ручную, домен перенес, но осадок от reg.ru остался. Кстати, dns'ы регистратора не использую принципиально. Какое-то у меня к ним недоверие.
IMHO оптимальный вариант — собственный master (да хоть на домашнем маршрутизаторе) и один-два публичных secondary (в зависимости от нужной надёжности). При такой схеме остаётся один вариант отказа доменного имени — разделегирование (по финансовой или политическим причинам)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории