Gold 6140 - это уже не самый новый процессор. E5 серия еще старше.
С осени мы ставим самый свежий Xeon Gold 6240 и 640 гигабайт оперативной памяти на сервер для виртуального хостинга.
Можно, но мы так не делаем.
Подсети, с которых систематически идут массовые запросы от ботов, тоже могут являться критерием для включения дополнительных мер по защите.
Откуда вы взяли эту информацию? Это не соответствует действительности.
Проверил через этот сервис вышеуказанный сайт https://nadezhdakhachaturova.ru/2016/01/otzyiv-o-begete/ - нет никакого скрипта.
Для http://trans-stone.ru/ этот скрипт включен явно и вручную еще с 2016 года с уведомлением владельца сайта. Каких-то вопросов, тикетов на этот счет нет.
Нет ничего мутного. Те, кто в разы превышал нагрузку или у кого были проблемы с нашествием ботов - знают об этом и могут жаловаться =) А 99% всех пользователей, у которых нет ни этого скрипта, ни каких-то проблем, не пишут об этом.
Уже можно ставить любые сертификаты без выделенного IP.
В Бегете этот скрипт действительно используется и без соотв. куки клиент может получить такой ответ от веб-сервера.
Такая защита устанавливается на сайты вручную как правило в случае, если на сайт идет много запросов от сомнительных ботов, которые становятся причиной значительного (в разы) превышения лимитов по нагрузке.
Этому скрипту уже много-много лет и он реально помогает отсечь часть ботов, которые массово сканируют сайты, брутят пароли в админках, пытаются вставить различные XSS итп. Это не единственный способ защиты и не единственный критерий установки такого скрипта. Остальные методы защиты я раскрывать не буду, а то придется их менять =) Подавляющее большинство пользователей и посетителей сайтов никогда не столкнутся с этим.
С поисковыми системами никаких проблем нет. Если у пользователя возникают сложности, то все легко решается через поддержку.
Кстати, а приведенный вами выше сайт не должен и не отдает этот скрипт. Мне действительно интересно, как вы получили его в ответ =)
Всем привет. Меня зовут Владислав. Я отвечаю за техническую часть в Бегете.
Сразу скажу - в последние 10-15 дней мы сами стали фиксировать много жалоб на срабатывания Яндекс.Вебмастера. С нашей стороны проверили все что только можно: время отдачи страниц вебсервером за последние несколько недель, который отдавал ответы по заявленным сайтам, работу сети, маршруты. Попутно нашли несколько потенциальных проблем, о которых раньше не знали =)) В общем, мы действительно не смогли найти корреляцию между срабатыванием алерта в Яндекс. Вебмастере и нашими серверами. Подавляющее большинство срабатываний оказывается, скажем так, сомнительными.
Помимо этого, для диагностики также своими силами осуществляли мониторинг доступности сайтов на серверах, с которых были наиболее свежие обращения. За сутки от 1 до 5 раз тестовый сайт открылся более чем за 2.5 секунды. При этом страницу открываем раз в 10 секунд. Или робот Яндекса мегачувствительный, или мы не очень понимаем по каким принципам он работает.
Справедливости ради отмечу, что скачки нагрузки на сервере и, как следствие замедление отдачи страницы, бывают. Но это бывает у всех и точно не в тех масштабах, о которых сообщает Яндекс.
Со своей стороны мы тоже направили запросы коллегам из Яндекса. Если ответят - поделимся информацией =)
Дополнительно прокомментирую пару моментов, о которых говорили коллеги в топике:
Да, всегда есть смысл проверить самостоятельно. По поводу переноса на другой сервер: у нас в прицнипе нет такого, чтоб был "очень загруженный" сервер и "не очень загруженный". Есть механизмы балансировки, которые более-менее равномерно распределяют пользователей не по количеству, а по реальной нагрузке, которую они создают. Но, если есть желание, мы никогда не отказываем в переносе на другой сервер. Правда, это, зачастую будет походить на плацебо =)
Это миф. Серверы, на которых есть уже заслуженные пользователи, не являются самыми загруженными ввиду той самой автобалансировки. Более того, во-многом они наоборот самые тихие, спокойные и с ними меньше всего инцидентов, т.к. там уже сформировался почти постоянный профиль нагрузки и постоянные пользователи.
Ее там нет, т.к. нет и регистрации доменов в этой зоне через Бегет
bums, а вы с reg.ru по оферте работаете?
Если да, то готовы к нововведениям?
Коллеги.
В сообщении /ru/forum/comment/15634053 пользователь makag достаточно точно осветил процесс переноса домена под наше обслуживание.
Дополню его первый пункт касательно получения кода.
Касательно API отвечаем конкретно: да, в случае, если домен находился под нашим управлением с reg.ru, мы выполняли запрос auth-кода через API регистратора REG.RU.
Хочу подчеркнуть, что для этого пользователю нужно было явно нажать на ссылку "получить код" и выбрать способ доставки кода.
Сам метод в API REG.RU открыт и доступен для всех: https://www.reg.ru/support/help/api2#create_authinfo_request
Такой метод подачи заявки на получение authinfo-кода не противоречит регламенту: https://cctld.ru/files/pdf/docs/regl_transfer.pdf
В остальных случаях пользователю показывалось диалоговое окно с инструкцией по получению кода, где синяя кнопка просто ведет на сайт регистратора.
Нет. конечно ничего такого мы не делали. Мы не меняем никакие данные администратора домена без его явной воли на это. В сценарии с переносом домена - конечно нет.
По факту мы просто сделали оповещение о возможности переноса в панели в виде плашки, без почтовой рассылки. Далее пользователь мог сам начать процедуру переноса и вписать authCode в соотв форму в панели управления.
Каких-либо скрытых махинаций без ведома пользователя мы не выполняли и никогда не выполняем.
Отвечу вкратце то, что ответил на хабре (https://habr.com/post/413553/#comment_18751373)
Вкратце:
1. Рассылок мы не делали про эту акцию вообще
2. При продлении никакого трансфера нет и не было (внимательно прочитайте условия и суть акции https://beget.com/ru/news/2018/transfer-renewal)
3. Трансфер домена - абсолютно отдельная операция в панели управления.
4. При продлении мы никаких предложений о трансфере не показывали.
