Comments 207
Имеется ли API для автоматизации управления записями (например, чтобы сделать динамический DNS на базе вашего сервера)?
Сейчас API доступен только партнерам. Готовим его для открытия всем. Следите за новостями)
добавили ограничение на количество неподтвержденных доменов с одним именем

Если злоумышленник зарегил максимальное количество доменов, то хозяин уже не сможет зарегистрировать домен у вас?

Как насчет уникального ключа в имени ns сервера? Например, dns-1qwe43oi.mail.ru?
Со временем не подтвержденные домены удаляются.
Если все же случится так, что к моменту регистрации домена владельцем, лимит будет исчерпан, ему предложат подтвердить другим способом.

Уникальные ключи рассматривали, но хотелось выдавать читабельные NS записи.
Зачем злоумышленнику регистрировать чужой домен на ваших NS-серверах?
например, чтобы легальный владелец этого домена не смог разместить его на серверах mail.ru

этакая пакость
В mail.ru нет проверки принадлежности домена, как например у яндекса (просят код в meta или создать cname). Поэтому теоретически возможен вариант когда злоумышленник зная о планах переноса домена на управление mail.ru может заранее зарегить его там и при выставлении новых ns записей для домена он сможет получить доступ к домену через CP mail.ru
Да, простите, туплю. Разграничение прав доступа на управление DNS-записями.

А тогда такой вариант: я из-под одного аккаунта зарегистрируюсь и укажу ns-записи, а потом из-под другого — кому достанется право управление доменом?

P.S. Какая-то не очевидная система верификации.
Вот они и рассказывают, что у них 2500 ns'ов, При добавлении домена в CP просят ввести два предложенных ns, выбранных случайно. Если ввел правильные ns — то домен твой :)
Это я понял :)

А если я с другого аккаунта ту же процедуру пройду — что произойдет?
В первом аккаунте домен исчезнет?
К тому же довольно странно верифицировать домен сменой ns…

А если у меня домен не по промо-коду, а действующий?
Я должен сменить ns'ы (тем самым получив доступ к управлению), а только потом смогу настраивать записи?
Не понимаю я, короче говоря… Надо, видимо, протестить.
в случае проверки NS-ами они больше ничего не верифицируют
Совсем не так.
Пара NS и домена всегда уникальна.
Для того, чтобы домен стал «твоим», нужно как-то убедить реального владельца домена сменить NS записи на выданные тебе.
По сложности эта такая же задача, как и при просьбе закинуть нужный файл на сервер или добавить TXT запись в DNS. Ни один владелец (в здравом уме) этого делать не будет, а значит и доступ злоумышленник не получит.

Если же владелец будет регистрировать в то же время, что и злоумышленник, ему достанется другая уникальная пара NS.
Я ответил на вопрос про злоумышленника, про возможный вариант атаки которого вы писали и защитились :) То что вы сделали пару ns+domain уникальными я прочитал.
По сложности эта такая же задача, как и при просьбе закинуть нужный файл на сервер или добавить TXT запись в DNS.
Непонятно. Кажется, что не такая. Положим, у вас 2500 серверов, угадать нужно два, то есть 2500*2499. Сложность этого примерно равна log(26+26+10)(2500*2499) ≈ 4 — четырехсимвольному секрету из больших, маленьких букв и цифр. Я не знаю, какого размера у вас ключ для TXT записи или для файла, но, полагаю, больше 4 символов.

Странно, что один способ проверки заведомо слабее двух других. Зачем вы решили это так сделать? Я понимаю, что нужно как–то подтверждать неделегированные домены, но если уж хочется это делать таким странным способом, стоит добавить еще IPv6 адреса NS серверов — энтропии станет намного больше. PowerDNS нормально работает с IPv6, доказано 2a02:6b8::feed:0ff.
Уникальность домена и кода/NS всегда гарантируется. Единственный способ получить права на чужой домен, как-то убедить владельца совершить манипуляции со своим сайтом или днс. Именно про задачу, связанную с убеждением я и говорил.

Если кто-то будет целенаправлено регистрировать один домен, он все равно не получит доступ к нему. Реальному владельцу просто будут предложены другие способы подтверждения.

IPv6 отличная идея, но это так же, как и с рандомными имена ns, ухудшает читабельность имен, а её мы хотим сохранить. Возможно стоит использовать этот способ, когда злоумышленник занял все возможные NS. Спасибо за идею.
ухудшает читабельность имен, а её мы хотим сохранить
Вы точно уверены, что это — не самоцель? Хотя, разумеется, дело ваше.

А делать NS без IPv6 в XXI веке как–то странно.
Проверка принадлежности домена есть.
Сейчас 4 способа проверки: html файл, html тег, txt запись в dns и новый через NS записи.
Проверка NSами этими же NSами и ограничивается, как я понял.
Вы не ответили на мой вопрос в самом верху:

Если злоумышленник зарегил максимальное количество доменов, то хозяин уже не сможет зарегистрировать домен у вас?
Как насчет уникального ключа в имени ns сервера? Например, dns-1qwe43oi.mail.ru?
А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.

перечитал три раза. для получения домена достаточно комментария? тогда я в деле )
эй, я был первон… ну, короче, первый комментарий к топику — мой. Можно и мне тоже? :)
О, оставляю комментарий, как раз хочу домен и почту на нем!
Ладно, дайте и мне промокод :) Чего-нибудь сделаю интересное
Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.

Раз так, то и я оставлю комментарий
Отлично, как там пишут?

Друзья, я заказывал домен, а мне случайно выдали три, но мне столько не надо. Так как я испытываю презрение к товарно-денежным отношениям, я решил отдать два домена случайным людям, для этого надо сделать репост этой записи и в ночь с 30 на 31 февраля я выберу двух победителей.
А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.

Почему бы и не попробовать.
Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.

Хорошо бы до уровня cloudflare.com дорасти Вам.
Да, парни делают отличные сервис. Обязательно будем рости.
studentpm, а какие фичи хочется видеть в первую очередь?

промокод отправил в личку
Первое с чем сталкиваешься при переносе домена на cloudflare, это сканирование имеющихся днс записей. Мелочь но очень приятно.
Второе что у них нравится это возможность использования их cdn, https и защита от возможных атак на сайт, понятно что это уже мало относится к простому dns хостингу, но уж очень хочется иметь альтернативу этому сервису в зоне .ru.
Сканирование DNS записей сделано в минимальном виде, основные будут перенесены.
Коллеги, было бы интересно, если бы вы рассказали как у вас реализована защита от атак:
1) DNS Amplification;
2) Water Chinese Turtle.

Первая — когда ваш сервис используют в качестве усилителя, когда недобросовестный пользователь например делает много «A»  записей на одно имя или большие, до 4к, «TXT» записи. А потом запрашивает от имени IP адреса атакуемой жертвы эти имена.

Вторая когда идет атака на ваш бэкенд (базу), с помощью большого потока запросов с рандомными поддоменами, исключая таким образом внутренний кеш PowerDNS из обработки, так как данные запросы им обслужить не могут.
Спасибо за ответ. Если можно, еще спрошу:
1) Реализована ли у вас версионность данных в зоне?
2) Журналируете ли вы запросы?
3) Будет ли доступна клиентам статистика по обращению к их зонам, в виде кол-ва запросов за отчетный период и/или графики и пр.?
Подозреваю, что это тянет еще на несколько статей…
Внедряю у себя PDNS и тоже адски реквестирую — как ведется статистика?
на старых серверах у меня был bind — одна строка в логе — один запрос, соответственно все атакующие fail2ban'ом отправлялись в iptables -P relax, но pdns весьма странно ведёт логи :(
Спасибо. В течении какого срока будут действительны промокоды? Прошу уточнить, домен на месяц/год или бессрочно?
Код действителен до конца месяца. Домен регистрируется на год.
Не удалось зарегистрироваться по промо-коду по данной акции (пробовал 15 минут назад с 2 логинами в mail.ru по очереди), страница регистрации отвечает:
Неправильный промо-код
Можно ли обеспечить регистрацию домена?
(Ответил также по ЛС человеку, непосредственно выдавшему промо-код, но сейчас выходные, поэтому решил продублировать.)
Как быстро будут обновляться записи после изменения?
Подозреваю, что речь идет про то, что обновление появится в БД через несколько секунд (сейчас пока зон и данных в них мало, как и количество реплик базы). А через какое время их увидит PowerDNS? Вы после обновления БД принудительно сбрасываете кеш PowerDNS?
Подскажите, DNS будет распространяться только на домены в зоне .ru или можно любое другое имя захостить? И на какой срок будет доступна услуга?
Выпишите тогда и мне один, пожалуйста. Может, все-таки сподоблюсь в этом году завести себе представительство в сети Интернет.)
Что же вы обманываете, домен.РФ то нельзя подключить к бизнес почте и к DNS-хостингу соответственно тоже.
Не видел DNS-хостингов, которые бы не поддерживали зону .me.
Однако говорить, что ограничений по зонам нет, когда они есть, это откровенное введение в заблуждение.
Спасибо за уточнение.

Зону.рф, действительно нельзя сейчас у нас зарегистрировать.
Можно добавить русскоязычные домены в виде xn--d1acufc.com.

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

Редактирование записей? Что сейчас поддерживает? Есть ли массовое редактирование?
Можно ли мигрировать с другого сервиса с переносом существующих записей?
Отправил в личку промокод на регистрацию домена. На нем можно попробовать.

Поддерживаются основные типы записей, wildcard.
Массового редактирования нет. Если есть пример хорошей реализации, с удовольствием посмотрю.
Сейчас переносятся лишь самые популярные записи (www., mail., ftp. и т.п.).
А что используется как бэкэнд хренения DNS? PowerDNS прилично работает лишь с MySQL/PostgreSQL, которые по своему дизайну крайне фигово подходят для задач «надежного» обеспечения доставки обновлений от центрального хранилища до удаленных узлов с DNS машинами.
Поставьте один из серверов где-нибудь в Латинской Америке либо Азии (желательно, в континентальном Китае) и посмотрите, как будет работать репликация. По нашим впечатлениям — крайне плохо. Часто бывает сильное нарушение связанности между мастер днсом и слейвами, когда до нескольких часов почти все пиги теряются, не говоря уже о работе tcp протокола как такового. Отсюда и вопрос, что за протокол как транспорт.

А вторая проблема — это единое место хранения информации при сбое которого, опять же, встают все задачи по правке зон.
Все днс работают в режиме мастера. У каждого из них своя база и репликация как раз была отдана на откуп БД, это же решает проблему с единым местом хранения. Т.к. база рядом, то у PowerDNS не возникает ни каких проблем с получением данных.

Если вы имели введу проблему репликации удаленной базы, то здесь ничего рассказать не могу, проблем со связью между нашими дата-центрами нет.
Используете родную потоковую репликацию postgresql или используете стороннюю триггерную?
не откажусь от промо кода.
по поводу ns серверов — вопрос один, на сколько датацентров сейчас разнесен этот функционал? Ведь ns сервер это по факту точка отказа для всего сайта. В свое время пережив пару падений ns серверов у хостеров прочно пересели на cloudflare на всех проектах (благо там есть поддержка wildcard записей, как у вас с этим кстати?)
Есть же Amazon Route 53 который за 50 центов в месяц может все. Считают каждое обращение, миллион запросов $ 0,40. Сравнительно дорого. Много где можно получить качественных днс за 1 доллар в год, но так как на амазоне — я не нашел нигде.

Лично у меня уровень доверия (я про надежность) к Амазону наивысший.
По API к ним вопросов тоже нет: возможно абсолютно всё. Дают (стандартно) лимит в 10К ресурсных записей в каждой зоне, в faq написано, что можно расширить по запросу. Можно через API хоть каждую секунду обновлять, можно выставить любой TTL, все моментально реплицируется на остальные.
Имхо, если большинство ваших пользователей в России, то используя NS'ы Амазона и записи с маленькими значениями ttl (для быстрого фейловера, например, или ещё какой фичи) вы будете заставлять своих пользователей ждать пока их рекурсоры будут гонять пакеты за тридевять земель.
Да, из Москвы, 30-50 мсек, пожалуй единственный минус, но только один раз — это ведь копейки, особенно на фоне современных сайтов, которые только саму страницу загружают за 0.5-1 сек, а потом еще она рендрится 1-3 сек (привет тысячам социальных виджетов). Дожили :D
Комментариев было 65 когда писал, значит и я в деле! Если успел, вышлите промокод, попробую. Можно же будет с ним поискать баги?
А если вы еще не успели попробовать наш сервис — оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне .ru с подключенным сервисом почты и DNS.

Любопытно. Хотелось бы протестировать.
Промокод будет интересен :)

Приятно что вы развиваетесь. Многие клиенты просят почту на домене «как на mail.ru», удобно иметь DNS-управление также в одном аккаунте…
Телефоны с кодом +7 999 считаются некорректными, но с другой стороны они есть! Исправите?
Получил. Если правильно понимаю, то регистрируемый по акции домен просто передается в управлении пользователя, но фактически является собственностью mail.ru?

https://help.mail.ru/biz/free_domain
Да. Если будет необходимость, то домен можно переоформить на себя через тех. поддержку.
Им мне промокод, если еще остались )
что то mail.ru в последнее время радуют.
Очень вовремя да еще и с интересным предложением.
Пришлете промокод?
Да, при заявленных критериях у powerDns конкурентов нет.

Интересно будет попробовать сервис.
Промо-код отправил в личку. Будет интересно почитать впечатления от сервиса)
Мдя.
Вы не осилили bind. Не осилили стандартных механизмов обновления зон master-slave.
Помню связку из 4-х bind'ов в 2008, которые на файлах держали 50K ДНС зон.
Мы не стали использовать bind — это все же другое.
А какие преимущества стандартного механизма обновлений зон master-slave, перед репликацией БД?
> Мы не стали использовать bind — это все же другое.
Тогда что у вас такого особенного в сервисе?

> А какие преимущества стандартного механизма обновлений зон master-slave, перед репликацией БД?
БД — лишняя точка отказа в схеме.
К тому же, в баг-репортах разных БД полно незакрытых багов при репликации.
Bind не сделал бы сервис особенным. В целом стек технологий стандартный и в этом больше плюсов.
Людей, работающих с репликацией БД, в разы больше, чем с репликацией DNS. Отсюда и большее количество найденых багов.

БД — надежный инструмент, о том как его масштабировать или решать какие-либо проблемы написано много документации/статей.
В файл данные все равно попадут из БД, так что полностью избавиться от этой зависимости не получится.
Людей, работающих с репликацией БД, в разы больше, чем с репликацией DNS. Отсюда и большее количество найденых багов.

Очень сомнительно. Репликацию DNS настроить несравненно проще, а задачу свою она отлично решает. Да наверняка каждый студент комьютерных наук хоть раз да настраивал эту репликацию. А вот репликация БД — безусловно гораздо более мощный инструмент, но за это приходится платить — гораздо более сложный и значит менее надёжный. И количество багов там больше именно в силу большей сложности, а пользователей этой технологии по этой же причине должно быть меньше.
Удаление зоны через AXFR? В случае с репликацией базы удаление получается «из коробки», в случае с AXFR вам нужно будет городить агента или ещё какой-нибудь способ очистки слейвов. Нужно ли очищать? с одной стороны — нет, с другой стороны — должен быть порядок и если домен удален из клиентской панели, значит авторитетные серверы не должны больше отвечать на эти запросы.
Зачем удалять? вон ВК вообще не удаляет данные со своих серверов :)
Ставите опцию allow-query { }; или только IP-заглушку.
А дальше в плановом режиме перегенирируйте конфиги зон.
Дьявол, как известно, прячется в деталях. Несомненно, схема с бэкэндом в виде реляционной базы удобна в реализации. Но именно реляционная база может стать (и станет, если кому то захочется завалить ваш сервис) узким местом в эксплуатации, в силу того, что она не способна предложить высокий уровень производительности, достаточный для абсорбирования атак типа Water Chinese Turtle, когда запросы не укладываются в кеш и доходят до БД. Вы наверняка найдете решение, но вот будет ли оно оптимальным или потянет за собой много оборудования в виде бесчисленных реплик БД? Как большая компания вы наверняка сможете это себе позволить (много оборудования) с точки зрения расходов. Но правильно ли архитектурное решение?
Что именно — дьявол в деталях. Сравнивать сложность репликации СУБД и сложность DNS AXFR — может лишь тот, кто не имеет ни малейшего понятия ни о том, ни о другом. DNS AXFR весьма прост, каменно надежен и рассчитан на работу в самых плохих условиях сетевого трафика. Репликация во-первых в сотни раз сложнее, во-вторых, в десятки рах более подвержена к косякам.
Если рассматривать детали — тогда стоит упомянуть о том, что AXFR в нормально реализованных авторитативных DNS серверах это только первичный трансфер зоны. Дальше как правило используется IXFR. Косяков хватает везде и том же в PowerDNS сейчас открыто 309 тикетов, конечно не все явные ошибки, но все же.
По поводу сложностей репликации СУБД — каждая команда разработчиков ищет свое решение, подходящее именно им. Тот же Neustar, одна и самых известных компаний в области DNS хостинга, обслуживающая в том числе домены .biz, .us и .co, использует БД Oracle с репликацией. И они не одни такие.
Сложность реализации и возможное большее теоретическое наличие косяков в алгоритмах или конкретном ПО является лишь одним из факторов, которые принимаются во внимание при разработке. Иногда функциональные преимущества, скорость разработки или др. факторы оцениваются как более важные.
PowerDNS — мягко говоря не лучший DNS. И понять это можно как раз по баг-трекеру проекта ну либо набив себе эти шишки руками. Мне пришлось набивать их на практике. А на практике инфраструктура DNS с 1/4 миллиона доменов испытывала 95% всех проблем исключительно из-за «особенностей» PowerDNS.

Даже Bind стабильнее в разы, но, увы, он сдался на 100к доменов.

NSD форева, за два года в продакшене ни единого инцидента и даже зависания! Вообще!

А в целом так еще Knot довольно перспективен.

По поводу Неустара и Оракла — не стоит путать авторитативный DNS и корневую зону. Корень почти не меняется, а в от авторитативник может за сутки измениться до неузанаваемости. А из этого все последствия по количеству информации, которую стоит передавать.

Если же идти дальше, то самые крутые ребята по DNS — это CloudFlare, у которых свой демон на Go на базе проекта Miekg DNS + свое кастомное хранилище. Вот они ушли в решении вопроса максимально далеко от всех прочих.

А Оракл на DNS… Ну можно и микроскопом гвоздить бить. Но нужно ли?!
Про то, что PowerDNS не лучший DNS, даже его автор понимает. Он обрабатывал до четвертой версии (пока альфа) DNS имена как ASCII строки, что безусловно не является хорошим решением. Как и некоторые другие особенности. Сейчас переписывает.

NSD компилирует, если мне не изменяет память, все данные зон непосредственно в RAM, что перестает работать в некоторых специальных случаях, когда зоны слишком большие и не помещаются в RAM.

Knot — да, перспективный, но пока почти не представлен в серьезных инсталляциях, хотя тут я могу и ошибаться.

Неустар именно выстукает как DNS хостер, в частности занимаясь хостингом клиентских доменов.

По поводу CloudFlare могу сказать, что по внешним признакам решение тоже далеко не идеальное и что они также плохо переваривают Water Chinese Turtle. Недавно наблюдал как там был размещен китайский домен блога по высоким технологиям и другие трудящиеся из Поднебесной его вывели из обслуживания такой атакой, которая пролилась на CloudFlare. Но к их чести (CloudFlare) это коснулось только этого конкретного домена.
Мы вот про это говорим, верно blog.secure64.com/?p=377? Я честно говоря, не понимаю, как оно опасно, если есть рекурсия и защита по RRL. Поясните, если не сложно?
В этой атаке как правило используются клиенты разных ISP с открытой на весь мир рекурсией, которые в свою очередь как правило (но не обязательно) смотрят в DNS кеши своего оператора связи. Агрегатно генерируется много запросов с рандомными поддоменами атакуемого домена. От каждого единичного клиента при этом полоса всего около 10 qps, В результате эти запросы не могут быть обслужены из локального кеша сервера провайдера и доходят до авторитативных серверов домена. Авторитативные сервера так же не могут служить их из собственного локального кеша и запрашивают свои бэкенды. Нагрузка ложится на SQL бэкенды со всеми вытекающими. А именно: большое количество рекурсивных контекстов у кеширующих серверов на стороне правайдеров, с ухудшением обслуживания своих клиентов и умирающий SQL бэкекнды на стороне авторитативных серверов, обслуживающих домен.
RRL никак не спасает. Атака на вымывание кешей и на перегрузку бэкенда.
Держали или обслуживали? В bind можно затолкать немало, но при тестах пару лет назад bind с одной маленькой зоной смог обработать 28rps загрузив 8 ядер, powerdns же на одном ядре и 10к зон в базе переваривал 100rps на одном ядре (да, packetcache был включён, иначе бы таких цифр не получилось).
Держали и обслуживали. И массово мигрировали при смене IP.
Клиенты были большого специфичного хостинга.
Bind реально без проблем скалится до 100к доменов на файлах, да (и я по-прежнему считаю, что это лучший формат если стоит выбор между субд или файлы). Но время перезапуска уходит в небеса и становится совершенно негуманным. NSD выбирайте, NSD! ;)
По той же причине, почему нет моего любимого Екатеринбурга — длинное имя)
В целом, вы сами себе создали проблему добавив подтверждение установкой NS-записей и как-то странно её решили.
Я правильно понимаю, что после того, как домен был привязан к одному из аккаунтов, его уже нельзя подтвердить в другом аккаунте и таким образом перенести?
Вот в почте для домена от Яндекса, например, подтверждённый домен, на котором ещё нет созданных ящиков, можно подтвердить и перенести.
По поводу Яндекс.Почты хотел бы уточнить — владельцу домена можно через тех. поддержку перенести не только домен между аккаунтами, но и почту на нем (т.е. можно с почтой, можно без). Во-первых, подтвердят владельца домена. Во-вторых, для переноса почты спросят, какие именно ящики были заведены.
Тот, кто подтвердил домен, может передать права на него другому пользователю.
Если так случилось, что подтвердивший домен, не может/хочет предать права (например, обидевшийся сис. админ), владелец может получить доступ через тех. поддержку с подтверждение прав на него.
О! Это то, что нужно, особенно если будет API! (причем на добавление новых доменов тоже, не только записей — подумайте об этом)

Если еще остались промо — был бы очень признателен!
API обязательно будет, следите за новостями)
Промо-код отправил в личку
Взял бы промокод. Почта у вас хорошо получилась, интересно на ДНС-хостинг посмотреть.
Посмотрел пошаговые видеоинструкции, выложенные на сайте, есть одно замечание. Нигде не сказано, как сделать дефолтный ящик, куда сыпались бы все письма с неправильными адресатами. По моему опыту, этот вопрос всегда возникает, когда люди осознают, что вообще-то в написании почты можно и ошибиться. Начинают пугаться, а тут опа — и ответ есть. А сейчас его нет.
Профессионал разберется, но ведь эти инструкции не для профессионалов сделаны, правда?

Я бы тоже от кода не отказался, буду пробовать.
Дня доброго.
Тоже интересно было бы попробовать.
В частности как реализовано добавление прав на управление DNS для других пользователей.
На Яндексе, например, админа добавить только через API и получение токена…
Админов можно добавлять через веб-интерфейс.
Промо-код отправил в личку.
Судя по rtt, ns1.ens.mail.ru находится в Москве, а где расположен ns2.ens.mail.ru?
Будут ли авторитетные серверы доступны по IPv6?

От промо тоже не откажусь :D
Вопрос такого плана: могу ли я заранее(до реального переноса) вбить записи?
А то как-то не сильно хочется получать нерабочую зону и только тогда её конфигурировать
Кто нибудь знает как продлить домен полученный по этой акции? :-) Можно без переноса, просто продлить. Заранее благодарен!
Only those users with full accounts are able to leave comments. Log in, please.