В прошлом году мы запустили бесплатный DNS-хостинг на «Mail.Ru для бизнеса», а недавно он вышел из бета-тестирования. Сегодня я хочу рассказать, как мы его делали, какие технические решения принимались, и немного о том, как мы запускались на всю аудиторию.
Мы внимательно прислушиваемся к пожеланиям наших пользователей и ведем учет всех хотелок. В этом списке DNS-хостинг стабильно держался в первых строчках. В результате мы решили две задачи: реализовали дополнительную услугу, о которой просили многие, и добавили еще один способ подтверждения домена для новых клиентов. К тому же после перехода на наш DNS-хостинг все необходимые для работы почты DNS-записи добавляются автоматически.
Выбор DNS-сервера
При выборе DNS-сервера мы ориентировались на скорость, потребляемые ресурсы и удобство работы. Очень хотелось, чтобы он умел работать с БД из коробки. Рассматривались BIND, NSD и PowerDNS.
BIND — самый популярный сервер, имеет хорошую документацию, и, наверное, можно найти ответ на любой вопрос по нему. Однако он не умеет работать с БД из коробки. Есть, конечно, DLZ-патч, но последнее обновление датируется 2013 годом. Не отличается высокой производительностью.
NSD — безусловный лидер по скорости и потребляемым ресурсам, но вот ни с чем, кроме файлов, он работать не умеет. На практике это значит, что нужно писать скрипт, который с периодичностью достает все записи из базы, пишет их в файл и делает reload NSD.
PowerDNS имеет хорошую производительность, умеренно использует ресурсы сервера. Имеет много полезных и не очень родных патчей. Умеет работать с PostgreSQL из коробки.
В конечном счете при выборе между высокой производительностью NSD и хорошей производительностью и простотой работы PowerDNS победил PowerDNS.
Работать с PowerDNS — одно удовольствие: вносишь изменения в БД, а он сам их подхватывает. К тому же, так как все данные берутся из базы, не приходится настраивать master-slave на стороне PowerDNS, а можно переложить их репликацию на базу.
История имен
Для подтверждения домена мы выдаем две NS-записи — например, moscow.ens.mail.ru и spb.ens.mail.ru. Откуда взялись города? Чтобы объяснить это, нужно сначала рассказать о задаче, которую мы пытались решить.
Мы стремились сделать регистрацию на «Mail.Ru для бизнеса» простой и удобной. Сейчас она работает следующим образом. Предположим, вы владеете доменом bestcompanyever.ru и хотите зарегистрироваться. Вы добавляете домен bestcompanyever.ru на нашем сайте, мы выдаем вам пару доменов для NS-записей. После того как вы их пропишете, вам станет доступно управление почтой и DNS-записями.
Однако возможна ситуация, когда два человека попытаются зарегистрировать bestcompanyever.ru в одно и то же время. Для таких случаев необходим алгоритм, который позволит выявлять настоящего владельца домена и выдавать ему права на управление почтой и DNS-сервером для этого домена.
Самое простое решение — выдавать имена в стандартном формате: dns1.mail.ru, dns2.mail.ru и т. д., а для идентификации использовать уникальное сочетание записей. Скажем, первому пользователю, добавившему bestcompanyever.ru, предлагается прописать dns7.mail.ru и dns23.mail.ru, а второму — dns3.mail.ru и dns84.mail.ru. Затем мы сверяем, какая пара NS-записей прописана для домена, и на основе этого определяем, кто истинный владелец. Казалось бы, отличная система — но есть нюанс. Часто пользователи, получив, например, dns3 и dns84 в качестве своих записей, прописывают и все остальные в этом диапазоне: dns3, dns4, dns5, dns6 и т. д. Никаких бонусов это не дает: единственное, что получает пользователь в результате таких действий, — это ошибка при верификации домена. Чтобы избежать таких ситуаций, мы выдаем имена, где последовательность неочевидна. Для этого мы задействовали названия городов. Сейчас у нас два списка по 50 городов.
Каждый, кто регистрируется в «Mail.Ru для бизнеса», получает одну запись из каждого списка. Это дает 2500 уникальных комбинаций, что гарантирует однозначную идентификацию владельца домена, даже если несколько человек пытаются зарегистрировать один домен.
После того как регистрация завершена, имена серверов теряют техническое значение. Независимо от того, по какому из адресов придет запрос, мы всегда отдадим запрашиваемые записи.
Перебор
Теоретически злоумышленник мог бы начать процедуры регистрации одного и того же домена под 2500 аккаунтами и получить все возможные вариации пар NS-имен. Когда пришел бы настоящий владелец домена и начал процедуру регистрации, ему досталась бы пара из уже занятых злоумышленником. И тогда после добавления их у регистратора и автоматической проверки мы активировали бы домен, зарегистрированный на злоумышленника.
Безусловно, этот сценарий сложный, дорогой, и в целом доменов, из-за которых стоило бы так мучиться, не так уж много. Решили эту проблему следующим образом: добавили ограничение на количество неподтвержденных доменов с одним именем, причем для каждого домена гарантированно генерируется уникальная пара.
Пользуясь случаем, хочу напомнить, что у Mail.Ru Group есть программа поиска уязвимостей. Если ты, пытливый читатель, найдешь баги в DNS-хостинге (как и в целом на biz.mail.ru), ты можешь заработать плюс в карму и денег, подав заявку.
Система фич
Вся новая функциональность включается для пользователей через систему фич. Это позволяет гибко выкатывать функции, выбирая, каким пользователям дать к ним доступ. Таким образом, мы можем проверять новые фичи на продакшене, не показывая их всем. При необходимости можно включать функции для конкретных пользователей, доменов или определенного процента аудитории.
В случае с DNS-хостингом у нас был список пользователей, которые очень-очень хотели его попробовать. Они были включены в группу закрытого бета-тестирования. Этот шаг позволил нам выявить баги, связанные с редкими кейсами, а также поправить несколько проблем в юзабилити интерфейса.
По окончании закрытого бета-тестирования мы начали открывать доступ к хостингу всем пользователям: сначала 10%, потом 50%, а через неделю — всем нашим клиентам.
Вместо заключения
Мы создали быстрый и надежный DNS-хостинг и останавливаться на этом не собираемся. В ближайшее время мы планируем запустить DNSSEC. Мы продолжаем улучшать наш хостинг и очень любим, когда нас критикуют. Так что прошу всех, кто уже воспользовался им, рассказать в комментариях о том, что вам хочется улучшить или добавить в хостинге.
А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.
Источники
blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers
Комментарии (203)
bardak_roman
04.02.2016 16:49А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.
перечитал три раза. для получения домена достаточно комментария? тогда я в деле )
merlin-vrn
04.02.2016 19:42эй, я был первон… ну, короче, первый комментарий к топику — мой. Можно и мне тоже? :)
IvaYan
04.02.2016 16:55Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.
Раз так, то и я оставлю комментарийIvaYan
04.02.2016 17:23Ой, а мне два что ли? :)
Core2Duo
04.02.2016 18:28Три :)
IvaYan
04.02.2016 18:58+5Отлично, как там пишут?
Друзья, я заказывал домен, а мне случайно выдали три, но мне столько не надо. Так как я испытываю презрение к товарно-денежным отношениям, я решил отдать два домена случайным людям, для этого надо сделать репост этой записи и в ночь с 30 на 31 февраля я выберу двух победителей.
Gray_Wolf
04.02.2016 17:00А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.
Почему бы и не попробовать.
studentpm
04.02.2016 17:03Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.
Хорошо бы до уровня cloudflare.com дорасти Вам.miotano
04.02.2016 17:31Да, парни делают отличные сервис. Обязательно будем рости.
studentpm, а какие фичи хочется видеть в первую очередь?
промокод отправил в личкуstudentpm
04.02.2016 17:38+1Первое с чем сталкиваешься при переносе домена на cloudflare, это сканирование имеющихся днс записей. Мелочь но очень приятно.
Второе что у них нравится это возможность использования их cdn, https и защита от возможных атак на сайт, понятно что это уже мало относится к простому dns хостингу, но уж очень хочется иметь альтернативу этому сервису в зоне .ru.miotano
04.02.2016 18:07Сканирование DNS записей сделано в минимальном виде, основные будут перенесены.
firehunt
04.02.2016 17:10Коллеги, было бы интересно, если бы вы рассказали как у вас реализована защита от атак:
1) DNS Amplification;
2) Water Chinese Turtle.
Первая — когда ваш сервис используют в качестве усилителя, когда недобросовестный пользователь например делает много «A» записей на одно имя или большие, до 4к, «TXT» записи. А потом запрашивает от имени IP адреса атакуемой жертвы эти имена.
Вторая когда идет атака на ваш бэкенд (базу), с помощью большого потока запросов с рандомными поддоменами, исключая таким образом внутренний кеш PowerDNS из обработки, так как данные запросы им обслужить не могут.miotano
05.02.2016 09:37+1Спасибо за идею. Сделаю отдельный пост.
firehunt
05.02.2016 14:25Спасибо за ответ. Если можно, еще спрошу:
1) Реализована ли у вас версионность данных в зоне?
2) Журналируете ли вы запросы?
3) Будет ли доступна клиентам статистика по обращению к их зонам, в виде кол-ва запросов за отчетный период и/или графики и пр.?
Подозреваю, что это тянет еще на несколько статей…
foxmuldercp
05.02.2016 23:16Внедряю у себя PDNS и тоже адски реквестирую — как ведется статистика?
на старых серверах у меня был bind — одна строка в логе — один запрос, соответственно все атакующие fail2ban'ом отправлялись в iptables -P relax, но pdns весьма странно ведёт логи :(
osj
04.02.2016 17:22Как быстро будут обновляться записи после изменения?
miotano
04.02.2016 20:12Обновление произойдет в течении нескольких секунд.
firehunt
05.02.2016 14:19Подозреваю, что речь идет про то, что обновление появится в БД через несколько секунд (сейчас пока зон и данных в них мало, как и количество реплик базы). А через какое время их увидит PowerDNS? Вы после обновления БД принудительно сбрасываете кеш PowerDNS?
lostpassword
04.02.2016 17:23Подскажите, DNS будет распространяться только на домены в зоне .ru или можно любое другое имя захостить? И на какой срок будет доступна услуга?
miotano
04.02.2016 17:37Ограничений по зонам нет. Услуга бессрочная.
lostpassword
04.02.2016 18:08Выпишите тогда и мне один, пожалуйста. Может, все-таки сподоблюсь в этом году завести себе представительство в сети Интернет.)
osj
04.02.2016 18:22Что же вы обманываете, домен.РФ то нельзя подключить к бизнес почте и к DNS-хостингу соответственно тоже.
lostpassword
04.02.2016 18:27Меня интересовала зона ".me".)
osj
04.02.2016 18:34+1Не видел DNS-хостингов, которые бы не поддерживали зону .me.
Однако говорить, что ограничений по зонам нет, когда они есть, это откровенное введение в заблуждение.
miotano
04.02.2016 20:46+1Спасибо за уточнение.
Зону.рф, действительно нельзя сейчас у нас зарегистрировать.
Можно добавить русскоязычные домены в виде xn--d1acufc.com.
В ближайшее время сделаем поддержку зоны.рф и читабельного варианта домен.com
skurudo
04.02.2016 17:27Простите, а как выглядит интерфейс этого хозяйства?
Редактирование записей? Что сейчас поддерживает? Есть ли массовое редактирование?
Можно ли мигрировать с другого сервиса с переносом существующих записей?miotano
04.02.2016 20:55Отправил в личку промокод на регистрацию домена. На нем можно попробовать.
Поддерживаются основные типы записей, wildcard.
Массового редактирования нет. Если есть пример хорошей реализации, с удовольствием посмотрю.
Сейчас переносятся лишь самые популярные записи (www., mail., ftp. и т.п.).
pavelodintsov
04.02.2016 17:32А что используется как бэкэнд хренения DNS? PowerDNS прилично работает лишь с MySQL/PostgreSQL, которые по своему дизайну крайне фигово подходят для задач «надежного» обеспечения доставки обновлений от центрального хранилища до удаленных узлов с DNS машинами.
miotano
04.02.2016 18:23Используем PostgreSQL. А в чем выражается фиговость?
pavelodintsov
04.02.2016 18:29Поставьте один из серверов где-нибудь в Латинской Америке либо Азии (желательно, в континентальном Китае) и посмотрите, как будет работать репликация. По нашим впечатлениям — крайне плохо. Часто бывает сильное нарушение связанности между мастер днсом и слейвами, когда до нескольких часов почти все пиги теряются, не говоря уже о работе tcp протокола как такового. Отсюда и вопрос, что за протокол как транспорт.
А вторая проблема — это единое место хранения информации при сбое которого, опять же, встают все задачи по правке зон.miotano
04.02.2016 21:04Все днс работают в режиме мастера. У каждого из них своя база и репликация как раз была отдана на откуп БД, это же решает проблему с единым местом хранения. Т.к. база рядом, то у PowerDNS не возникает ни каких проблем с получением данных.
Если вы имели введу проблему репликации удаленной базы, то здесь ничего рассказать не могу, проблем со связью между нашими дата-центрами нет.
clickfreak
05.02.2016 17:20Используете родную потоковую репликацию postgresql или используете стороннюю триггерную?
NosovK
04.02.2016 17:48не откажусь от промо кода.
по поводу ns серверов — вопрос один, на сколько датацентров сейчас разнесен этот функционал? Ведь ns сервер это по факту точка отказа для всего сайта. В свое время пережив пару падений ns серверов у хостеров прочно пересели на cloudflare на всех проектах (благо там есть поддержка wildcard записей, как у вас с этим кстати?)
antonwork
04.02.2016 18:06Есть же Amazon Route 53 который за 50 центов в месяц может все. Считают каждое обращение, миллион запросов $ 0,40. Сравнительно дорого. Много где можно получить качественных днс за 1 доллар в год, но так как на амазоне — я не нашел нигде.
Лично у меня уровень доверия (я про надежность) к Амазону наивысший.
По API к ним вопросов тоже нет: возможно абсолютно всё. Дают (стандартно) лимит в 10К ресурсных записей в каждой зоне, в faq написано, что можно расширить по запросу. Можно через API хоть каждую секунду обновлять, можно выставить любой TTL, все моментально реплицируется на остальные.clickfreak
05.02.2016 17:32Имхо, если большинство ваших пользователей в России, то используя NS'ы Амазона и записи с маленькими значениями ttl (для быстрого фейловера, например, или ещё какой фичи) вы будете заставлять своих пользователей ждать пока их рекурсоры будут гонять пакеты за тридевять земель.
antonwork
05.02.2016 18:29Да, из Москвы, 30-50 мсек, пожалуй единственный минус, но только один раз — это ведь копейки, особенно на фоне современных сайтов, которые только саму страницу загружают за 0.5-1 сек, а потом еще она рендрится 1-3 сек (привет тысячам социальных виджетов). Дожили :D
heathen
04.02.2016 18:46А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.
Любопытно. Хотелось бы протестировать.
mahnunchik
04.02.2016 20:06А промокоды ещё остались?
lrom
04.02.2016 20:48Присоединяюсь. Хотелось бы протестировать.
miotano
04.02.2016 21:51Промокод в личке
lrom
04.02.2016 22:50Получил. Если правильно понимаю, то регистрируемый по акции домен просто передается в управлении пользователя, но фактически является собственностью mail.ru?
https://help.mail.ru/biz/free_domainmiotano
05.02.2016 09:44Да. Если будет необходимость, то домен можно переоформить на себя через тех. поддержку.
ivanz85
04.02.2016 20:57Часть про города — точный перевод решения Cloudflare, только вместо имен у mail.ru города
Хорошо бы на первоисточние ссылаться.
Кстати, Cloudflare тоже дает бесплатный DNS.
blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers
click0
05.02.2016 00:05+1Мдя.
Вы не осилили bind. Не осилили стандартных механизмов обновления зон master-slave.
Помню связку из 4-х bind'ов в 2008, которые на файлах держали 50K ДНС зон.miotano
05.02.2016 10:08Мы не стали использовать bind — это все же другое.
А какие преимущества стандартного механизма обновлений зон master-slave, перед репликацией БД?click0
05.02.2016 11:28+2> Мы не стали использовать bind — это все же другое.
Тогда что у вас такого особенного в сервисе?
> А какие преимущества стандартного механизма обновлений зон master-slave, перед репликацией БД?
БД — лишняя точка отказа в схеме.
К тому же, в баг-репортах разных БД полно незакрытых багов при репликации.miotano
05.02.2016 12:18Bind не сделал бы сервис особенным. В целом стек технологий стандартный и в этом больше плюсов.
Людей, работающих с репликацией БД, в разы больше, чем с репликацией DNS. Отсюда и большее количество найденых багов.
БД — надежный инструмент, о том как его масштабировать или решать какие-либо проблемы написано много документации/статей.
В файл данные все равно попадут из БД, так что полностью избавиться от этой зависимости не получится.merlin-vrn
05.02.2016 13:10Людей, работающих с репликацией БД, в разы больше, чем с репликацией DNS. Отсюда и большее количество найденых багов.
Очень сомнительно. Репликацию DNS настроить несравненно проще, а задачу свою она отлично решает. Да наверняка каждый студент комьютерных наук хоть раз да настраивал эту репликацию. А вот репликация БД — безусловно гораздо более мощный инструмент, но за это приходится платить — гораздо более сложный и значит менее надёжный. И количество багов там больше именно в силу большей сложности, а пользователей этой технологии по этой же причине должно быть меньше.clickfreak
05.02.2016 16:53Удаление зоны через AXFR? В случае с репликацией базы удаление получается «из коробки», в случае с AXFR вам нужно будет городить агента или ещё какой-нибудь способ очистки слейвов. Нужно ли очищать? с одной стороны — нет, с другой стороны — должен быть порядок и если домен удален из клиентской панели, значит авторитетные серверы не должны больше отвечать на эти запросы.
click0
05.02.2016 17:05+1Зачем удалять? вон ВК вообще не удаляет данные со своих серверов :)
Ставите опцию allow-query { }; или только IP-заглушку.
А дальше в плановом режиме перегенирируйте конфиги зон.
firehunt
05.02.2016 13:43+1Дьявол, как известно, прячется в деталях. Несомненно, схема с бэкэндом в виде реляционной базы удобна в реализации. Но именно реляционная база может стать (и станет, если кому то захочется завалить ваш сервис) узким местом в эксплуатации, в силу того, что она не способна предложить высокий уровень производительности, достаточный для абсорбирования атак типа Water Chinese Turtle, когда запросы не укладываются в кеш и доходят до БД. Вы наверняка найдете решение, но вот будет ли оно оптимальным или потянет за собой много оборудования в виде бесчисленных реплик БД? Как большая компания вы наверняка сможете это себе позволить (много оборудования) с точки зрения расходов. Но правильно ли архитектурное решение?
pavelodintsov
05.02.2016 16:10+1Что именно — дьявол в деталях. Сравнивать сложность репликации СУБД и сложность DNS AXFR — может лишь тот, кто не имеет ни малейшего понятия ни о том, ни о другом. DNS AXFR весьма прост, каменно надежен и рассчитан на работу в самых плохих условиях сетевого трафика. Репликация во-первых в сотни раз сложнее, во-вторых, в десятки рах более подвержена к косякам.
firehunt
05.02.2016 16:55+2Если рассматривать детали — тогда стоит упомянуть о том, что AXFR в нормально реализованных авторитативных DNS серверах это только первичный трансфер зоны. Дальше как правило используется IXFR. Косяков хватает везде и том же в PowerDNS сейчас открыто 309 тикетов, конечно не все явные ошибки, но все же.
По поводу сложностей репликации СУБД — каждая команда разработчиков ищет свое решение, подходящее именно им. Тот же Neustar, одна и самых известных компаний в области DNS хостинга, обслуживающая в том числе домены .biz, .us и .co, использует БД Oracle с репликацией. И они не одни такие.
Сложность реализации и возможное большее теоретическое наличие косяков в алгоритмах или конкретном ПО является лишь одним из факторов, которые принимаются во внимание при разработке. Иногда функциональные преимущества, скорость разработки или др. факторы оцениваются как более важные.pavelodintsov
05.02.2016 17:16+1PowerDNS — мягко говоря не лучший DNS. И понять это можно как раз по баг-трекеру проекта ну либо набив себе эти шишки руками. Мне пришлось набивать их на практике. А на практике инфраструктура DNS с 1/4 миллиона доменов испытывала 95% всех проблем исключительно из-за «особенностей» PowerDNS.
Даже Bind стабильнее в разы, но, увы, он сдался на 100к доменов.
NSD форева, за два года в продакшене ни единого инцидента и даже зависания! Вообще!
А в целом так еще Knot довольно перспективен.
По поводу Неустара и Оракла — не стоит путать авторитативный DNS и корневую зону. Корень почти не меняется, а в от авторитативник может за сутки измениться до неузанаваемости. А из этого все последствия по количеству информации, которую стоит передавать.
Если же идти дальше, то самые крутые ребята по DNS — это CloudFlare, у которых свой демон на Go на базе проекта Miekg DNS + свое кастомное хранилище. Вот они ушли в решении вопроса максимально далеко от всех прочих.
А Оракл на DNS… Ну можно и микроскопом гвоздить бить. Но нужно ли?!firehunt
05.02.2016 17:37+1Про то, что PowerDNS не лучший DNS, даже его автор понимает. Он обрабатывал до четвертой версии (пока альфа) DNS имена как ASCII строки, что безусловно не является хорошим решением. Как и некоторые другие особенности. Сейчас переписывает.
NSD компилирует, если мне не изменяет память, все данные зон непосредственно в RAM, что перестает работать в некоторых специальных случаях, когда зоны слишком большие и не помещаются в RAM.
Knot — да, перспективный, но пока почти не представлен в серьезных инсталляциях, хотя тут я могу и ошибаться.
Неустар именно выстукает как DNS хостер, в частности занимаясь хостингом клиентских доменов.
По поводу CloudFlare могу сказать, что по внешним признакам решение тоже далеко не идеальное и что они также плохо переваривают Water Chinese Turtle. Недавно наблюдал как там был размещен китайский домен блога по высоким технологиям и другие трудящиеся из Поднебесной его вывели из обслуживания такой атакой, которая пролилась на CloudFlare. Но к их чести (CloudFlare) это коснулось только этого конкретного домена.pavelodintsov
05.02.2016 17:51Мы вот про это говорим, верно blog.secure64.com/?p=377? Я честно говоря, не понимаю, как оно опасно, если есть рекурсия и защита по RRL. Поясните, если не сложно?
firehunt
05.02.2016 18:10+1В этой атаке как правило используются клиенты разных ISP с открытой на весь мир рекурсией, которые в свою очередь как правило (но не обязательно) смотрят в DNS кеши своего оператора связи. Агрегатно генерируется много запросов с рандомными поддоменами атакуемого домена. От каждого единичного клиента при этом полоса всего около 10 qps, В результате эти запросы не могут быть обслужены из локального кеша сервера провайдера и доходят до авторитативных серверов домена. Авторитативные сервера так же не могут служить их из собственного локального кеша и запрашивают свои бэкенды. Нагрузка ложится на SQL бэкенды со всеми вытекающими. А именно: большое количество рекурсивных контекстов у кеширующих серверов на стороне правайдеров, с ухудшением обслуживания своих клиентов и умирающий SQL бэкекнды на стороне авторитативных серверов, обслуживающих домен.
RRL никак не спасает. Атака на вымывание кешей и на перегрузку бэкенда.
clickfreak
05.02.2016 16:57Держали или обслуживали? В bind можно затолкать немало, но при тестах пару лет назад bind с одной маленькой зоной смог обработать 28rps загрузив 8 ядер, powerdns же на одном ядре и 10к зон в базе переваривал 100rps на одном ядре (да, packetcache был включён, иначе бы таких цифр не получилось).
click0
05.02.2016 17:07Держали и обслуживали. И массово мигрировали при смене IP.
Клиенты были большого специфичного хостинга.
pavelodintsov
05.02.2016 17:18+1Bind реально без проблем скалится до 100к доменов на файлах, да (и я по-прежнему считаю, что это лучший формат если стоит выбор между субд или файлы). Но время перезапуска уходит в небеса и становится совершенно негуманным. NSD выбирайте, NSD! ;)
b1rdex
05.02.2016 06:37В целом, вы сами себе создали проблему добавив подтверждение установкой NS-записей и как-то странно её решили.
Я правильно понимаю, что после того, как домен был привязан к одному из аккаунтов, его уже нельзя подтвердить в другом аккаунте и таким образом перенести?
Вот в почте для домена от Яндекса, например, подтверждённый домен, на котором ещё нет созданных ящиков, можно подтвердить и перенести.skurudo
05.02.2016 09:15По поводу Яндекс.Почты хотел бы уточнить — владельцу домена можно через тех. поддержку перенести не только домен между аккаунтами, но и почту на нем (т.е. можно с почтой, можно без). Во-первых, подтвердят владельца домена. Во-вторых, для переноса почты спросят, какие именно ящики были заведены.
miotano
05.02.2016 12:30Тот, кто подтвердил домен, может передать права на него другому пользователю.
Если так случилось, что подтвердивший домен, не может/хочет предать права (например, обидевшийся сис. админ), владелец может получить доступ через тех. поддержку с подтверждение прав на него.
s_kozlov
05.02.2016 10:47Посмотрел пошаговые видеоинструкции, выложенные на сайте, есть одно замечание. Нигде не сказано, как сделать дефолтный ящик, куда сыпались бы все письма с неправильными адресатами. По моему опыту, этот вопрос всегда возникает, когда люди осознают, что вообще-то в написании почты можно и ошибиться. Начинают пугаться, а тут опа — и ответ есть. А сейчас его нет.
Профессионал разберется, но ведь эти инструкции не для профессионалов сделаны, правда?
Я бы тоже от кода не отказался, буду пробовать.
JackRowsen
05.02.2016 13:11Дня доброго.
Тоже интересно было бы попробовать.
В частности как реализовано добавление прав на управление DNS для других пользователей.
На Яндексе, например, админа добавить только через API и получение токена…
clickfreak
05.02.2016 17:44Судя по rtt, ns1.ens.mail.ru находится в Москве, а где расположен ns2.ens.mail.ru?
Будут ли авторитетные серверы доступны по IPv6?
От промо тоже не откажусь :D
devpreview
Зачем злоумышленнику регистрировать чужой домен на ваших NS-серверах?
merlin-vrn
например, чтобы легальный владелец этого домена не смог разместить его на серверах mail.ru
этакая пакость
xytop
В mail.ru нет проверки принадлежности домена, как например у яндекса (просят код в meta или создать cname). Поэтому теоретически возможен вариант когда злоумышленник зная о планах переноса домена на управление mail.ru может заранее зарегить его там и при выставлении новых ns записей для домена он сможет получить доступ к домену через CP mail.ru
devpreview
Да, простите, туплю. Разграничение прав доступа на управление DNS-записями.
А тогда такой вариант: я из-под одного аккаунта зарегистрируюсь и укажу ns-записи, а потом из-под другого — кому достанется право управление доменом?
P.S. Какая-то не очевидная система верификации.
xytop
Вот они и рассказывают, что у них 2500 ns'ов, При добавлении домена в CP просят ввести два предложенных ns, выбранных случайно. Если ввел правильные ns — то домен твой :)
devpreview
Это я понял :)
А если я с другого аккаунта ту же процедуру пройду — что произойдет?
В первом аккаунте домен исчезнет?
К тому же довольно странно верифицировать домен сменой ns…
А если у меня домен не по промо-коду, а действующий?
Я должен сменить ns'ы (тем самым получив доступ к управлению), а только потом смогу настраивать записи?
Не понимаю я, короче говоря… Надо, видимо, протестить.
devpreview
Да не, ерунда.
Вон же куча способов для проверки:
help.mail.ru/biz/verification_settings/other/confirm
xytop
в случае проверки NS-ами они больше ничего не верифицируют
miotano
Совсем не так.
Пара NS и домена всегда уникальна.
Для того, чтобы домен стал «твоим», нужно как-то убедить реального владельца домена сменить NS записи на выданные тебе.
По сложности эта такая же задача, как и при просьбе закинуть нужный файл на сервер или добавить TXT запись в DNS. Ни один владелец (в здравом уме) этого делать не будет, а значит и доступ злоумышленник не получит.
Если же владелец будет регистрировать в то же время, что и злоумышленник, ему достанется другая уникальная пара NS.
xytop
Я ответил на вопрос про злоумышленника, про возможный вариант атаки которого вы писали и защитились :) То что вы сделали пару ns+domain уникальными я прочитал.
ivlad
Странно, что один способ проверки заведомо слабее двух других. Зачем вы решили это так сделать? Я понимаю, что нужно как–то подтверждать неделегированные домены, но если уж хочется это делать таким странным способом, стоит добавить еще IPv6 адреса NS серверов — энтропии станет намного больше. PowerDNS нормально работает с IPv6, доказано 2a02:6b8::feed:0ff.
miotano
Уникальность домена и кода/NS всегда гарантируется. Единственный способ получить права на чужой домен, как-то убедить владельца совершить манипуляции со своим сайтом или днс. Именно про задачу, связанную с убеждением я и говорил.
Если кто-то будет целенаправлено регистрировать один домен, он все равно не получит доступ к нему. Реальному владельцу просто будут предложены другие способы подтверждения.
IPv6 отличная идея, но это так же, как и с рандомными имена ns, ухудшает читабельность имен, а её мы хотим сохранить. Возможно стоит использовать этот способ, когда злоумышленник занял все возможные NS. Спасибо за идею.
ivlad
А делать NS без IPv6 в XXI веке как–то странно.
miotano
Проверка принадлежности домена есть.
Сейчас 4 способа проверки: html файл, html тег, txt запись в dns и новый через NS записи.
xytop
Проверка NSами этими же NSами и ограничивается, как я понял.
Вы не ответили на мой вопрос в самом верху:
miotano
Ответил выше