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

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

НЛО прилетело и опубликовало эту надпись здесь
Буду признателен если вы покажете «бесплатный аналог не хуже»?
К сожалению ничего нет и близко. Как все это поверхностные суждения заключающиеся в попытке сравнить только сервис DDNS. Но статья не про это…
Я не фанат Dyn, но для промышленных решений кроме пока них не предлагает никто.
ну почему же никто не предлагает?
существуют же коммерческие gslb продукты, которые можно купить в том aws marketplace.
да, это скорее всего не подойдет для мелких проектов. но, если бюджет позволяет, почему нет?
на dns запросы gslb решение всегда будет возвращать адрес из доступной локации, плюс можно динамически добавлять адреса серверов используя api балансировщика.

в общем, решения существуют. вопрос бюджетов.
Как говорил мой преподаватель философии — прежде чем спорить или высказываться, определитесь с предметом. Ivan_83 предлагал использовать «бесплатные аналоги», я же как раз за промышленный подход. Так что мы с вами zup на одной волне ;-)
Да, хотел добавить. gslb, насколько я понимаю, относится только к хостингу на базе Amazon, всем остальным придется решать вопросы самостоятельно.
ну здесь опять-таки есть gslb вендоры, которые продают виртуалки для самых разных гипервизоров.
поэтому, если не используете Amazon, можно взять другой хостинг (vmware, hyper-v, xenserver, kvm) и развернуть виртуальный gslb.
ок :) просто Ivan_83 писал про бесплатные, а я привязался к
Я не фанат Dyn, но для промышленных решений кроме пока них не предлагает никто.
Согласен ;-) Век живи, век учись
У меня с одной стороны проще, с другой — веселее:
docker-host при создании/(пере)запуске/удалении контейнера по шаблону имени контейнера скриптами регистрируется/обновляется/удаляется в связке powerdns + postgresql на внутренние зоны.
Вариант на коленке работает. Сам делаю так когда задача этого требует.
Но есть задачи когда «на коленке» не вариант. Скрипты выдержат 1000 серверов? А 10000? А встраивание в бизнес-приложение? А мониторинг? А 10 географических зон? И как синхронизировать все это будем? Создадим собственный Dyn? Но почему мы все время пытаемся быть кустарями-ремесленниками? Зачем все время повторяем одно и тоже, одни и те же ошибки?
Буду делать дальше, скорее всего архитектура поменяется, поскольку это не один docker-host и далеко не с одним контейнером
Есть теория, что NS-сервера для домена должны жить в разных TLD, так, чтобы даже при смерти/недоступности для мира части корневых серверов домер ресолвился через NS-ы в других TLD.

Это логично, и я как-то был свидетелем, как подобная предосторожность спасает нервы, когда, скажем, зоны .net или .com перестают ресолвиться, но, что удивительно, что Google, что DynDNS как компании живут на NS-ах в одной TLD. И вот Dyn я понять не могу — их работа как раз обеспечить работу доменов клиентов при любых проблемах в Интернете…
Не очень понятна теория — каждый из корневых серверов содержит полную информацию о всех корневых tld и способен ее ресолвить. NS сервера Dyn распределены по миру по десятку дата-центров. За 15 лет не было ни одного отказа, даже когда некоторые корневые сервера подвергались атаке. Так что свою задачу IMHO Dyn выполняет. К стати, Яндекс тоже имеет существенные мощности DNS, распределенные по стране, поэтому мы его и выбрали как бэкенд для своего DDNS.
Проблемы ресолвинга для tld, о которых вы говорите скорее всего связаны с проблемами общей маршрутизации с каком-то из сегментов сети.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории