^{* для нашего хостинга :)}

И решили мы это сделать потому, DNS нужно выделить в отдельный, самостоятельно разворачиваемый сервис и заодно напилить фичей.



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

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

Интерфейс

Однажды нам на горячую линию поступил звонок, сопровождавший тикет в OTRS. Звонил генеральный директор одной компании. По каким-то причинам его сервер перестал работать, организация встала, а его главный «программист» попал в аварию и ему самому была нужна помощь. Основную часть диагностики провели сотрудники на горячей линии прямо по телефону, вместе с генеральным директором. Разговор был записан и поступил на анализ.

Самый сложный момент для нашего клиента был, когда они с оператором дошли до диагностики сети. В Windows Server нужно открыть несколько окон и посмотреть в несколько разных мест, чтобы дойти до свойств сетевого адаптера. По мере открытия новых окон можно было почувствовать, как человек на том конце провода всё дольше «парсил» содержание новых окон. 

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

▍Минимизация технической сложности

Сложность любой системы состоит из:

1. Неизбежной сложности — сложности, связанной с предметной областью и фичами.
2. Побочной сложности — сложности, привнесённой реализацией этих фич.

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


^{Amazon Route 53 – это высокодоступный и масштабируемый веб-сервис системы доменных имен (DNS)}

Это хороший пример побочной сложности, связанной с особенностями бизнес-логики.

Мы убрали всю побочную сложность и оставили только неизбежную — вам останется только прописать страны, указать записи и придумать этому название.

▍Минимизация когнитивной сложности

Уменьшить когнитивную нагрузку можно либо уменьшением количества сущностей, с которой работает человек, либо абстракцией. Мы начали смотреть, как пользователи использовали предыдущую версию DNS. Примерно у 80% пользователей было всего пару записей, однако, были и настоящие киты.

У людей с самым большим количеством доменов самой популярной записью оказалась CNAME, а количество поддоменов доходило до 63. Люди указывали алиасы для разных служб (ftp, smb) и филиалов в разных городах (spb, msk). Поэтому мы объединили поддомены и дополнительную логику в одну сущность и назвали её сценариями. Возможно, это не лучшее название, но пока так.

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

Базовый сценарий (Simple), не имеет никакой логики и это просто DNS. 

Теперь пара слов о новых, вычурных сценариях.

---

Новые фичи

▍GeoIP

Иногда люди обращаются к нам в поддержку или в чат с просьбой оценить их идеи. Одна из самых горячих идей — собственный маленький CDN. 

Задумка в том, чтобы сделать инстанс для своих европейских клиентов и направлять их на него с помощью DNS или редиректом. Идея хорошая, поэтому мы сделали GeoIP-сценарий. Записи в нём будут разрешаться только в указанных странах.


Но тут не без ограничений. Если человек использует публичные DNS-серверы, вместо сервера, который получили по DHCP, он попадёт в страну, хостящую этот DNS. Например, если человек использует DNS Яндекса, независимо от того, где он находится, сервер будет определять его будто он всегда в России.

По нашим прикидкам GeoIP обладает точностью порядка 70–80%, что вполне юзабельно. Как можно улучшить точность — поймём после анализа журналов запросов. А пока — пробуйте.

▍LoadBalancing

Сценарий будет полезен, если у вас есть несколько копий вашего приложения на нескольких серверах, и одна из копий работает значительно быстрее всех остальных. В отличие от записей с весами, балансировка осуществляется не по адресам, а по областям, где вес присваивается группе записей, а не каждой поодиночке. То есть у разных серверов может быть указано несколько IP-адресов. Таким образом, если у вашего «сильного» сервера есть не только IPv4, но и IPv6-адрес, можно использовать и его.


Точность балансировки не такая высокая как у балансировщиков, но в отличие от HTTP-балансировщиков не является единой точкой отказа и не требует никаких вмешательств в инфраструктуру. Плюс он бесплатен.

▍TimeOfDay

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

▍GeoIPFilter

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

▍Другие

Также есть смеси всех вышеперечисленных фич. Мы посмотрим, насколько будет высок спрос на них, и удалим, если они окажутся никому не нужны.

Напоследок

Пользоваться нашими сервисами будем не только мы, поэтому, если у вас есть идеи, как сделать сервис лучше, удобнее, или (о ужас) вы владеете фотошопом, пишите свои мысли на support@ruvds.com и получайте бонусные баллы на баланс.

За каждую хорошую и уникальную идею мы начислим сумму на бонусный баланс, достаточную, чтобы арендовать маленький сервер на Linux или Windows Server Core.

Будем рады слышать критику с аргументами и ваши идеи.