Pull to refresh

Comments 34

Спасибо. Меня этот поставщик dyndns тоже начал напрягать) MikroTik сейчас стал бесплатно давать сервис аналогичный для своих устройств. Приятный бонус.
sudo /root/ddns/ddns.sh

Я как-то очень занервничал когда увидел это :-) А зачем тут вообще root? nsupdate, я так понимаю, через loopback с сервером общается.
Да, это совсем не обязательно, скрипту ненужны привилегии рута, поправил пути чтобы не смущали на /home/ddns
К сожалению совсем без sudo не получается. Не хочет у меня php из под www стартовать bash-скрипт, пришлось извернуться через обычного пользователя, о чем я поправил статью.
Так может у вас там хомяк был 0700? В этой задаче sudo не нужен (скрипт на баше, впрочем, тоже, все это можно было бы сделать сразу из PHP и не громоздить сущностей).
Согласен, но в php у меня меньше опыта чем в bash, и потому пока лишняя сущность. Хотя конечно Ваше замечание интересно, попробую.
Не буду спрашивать, зачем всё это, но на всякий случай напомню о нормальном dns-хостинге, умеющем, в том числе DDNS по подобному банальному протоколу: dns.he.net/
Не буду спорить на сколько он нормальный и качественный, не пользовал к сожалению. Свое решение позиционирую в первую очередь как решение для своей площадки. Интересно может быть тем, у кого свой dns-сервер. Кто-то может быть пользует свои почтовые сервера, кому-то может быть не нравится dropbox и он разворачивает owncloud. Считаю что всякое имеет право быть — если оно справляется со своей задачей.
Он замечательный, но, например, wildcard-домены у него заблокированы.
Блокировку в php-скрипте не забыли, чтобы два клиента, одновременно обратившиеся к скрипту, не мешали друг другу? Что будет, если сервер упадёт? Адреса у всех клиентов обновляться не будут? Это всё вещи, которые в dyndns продуманы и учтены.
уточните о какой блокировке идет речь?

понятно что я не рассматривал это в контексте отказоустойчивого кластера — это обычный виртуальный сервер на 30 клиентов. Ясно что если он упадет, будет заминка у клиентов, у меня отвалится еще пара сервисов. Хотя опять же забота хостера держать мой сервер по питанию и доступу в мир. Ни в коей мере это ведь не конкуренция dyndns, но в узких кругах моей мамы — мой сервис одержал победу ;)
Вы открываете и пересохраняете файл зоны из PHP-скрипта, так? Если два скрипта будут писать в один файл, это может кончиться плохо. Если один читает, когда второй в процессе записи, это ещё вариант сбоя. Если два прочитали, сделали изменения (каждый своё) и записали вместе, то может кто-то один «победить», затерев изменения другого и т.д. Проблем разных может быть много.

Покажите код, как вы это делаете. Я его поревьюю и скажу, если вы чего делаете не так.
Нет, зону обновляет сам bind через push. Там все атомарно, насколько я помню.
Так весь код в статье. Сам php-скрипт никоим образом не трогает файлы зон, он лишь использует интерфейс взаимодействую через rndc, я полагаю что ребята-разработчики bind'а должны были позаботиться здесь о блокировках при одновременном доступе к зоне.
О, пардон, я пропустил этот скрипт. С ним всё хорошо получается.
Тоже долго сидел на DynDNS.
В конец достал.
Благо альтернатив — пруд-пруди.
Правда не во всех роутерах можно указать желаемый.
Мне повезло что в моем есть поддержка https://www.dnsomatic.com/.
А уже к нему можно подключить много чего. Остановился на ChangeIP и уже второй год как забыл о том что где-то что-то может истекать.
Тоже пользовался динднс, пока он работал. Свет клином сошелся на нем потому, что он есть практически во всех роутерах, а во многих роутерах — только он один. Этот факт наверняка существенно увеличил их базу клиентов.

В итоге перешел на freedns. Его нету в роутерах, но свои плюсы сервис имеет. Обновление днс осуществляется http(s) запросом, по крону раз в 5 минут.
Когда-то тоже делал подобное решение, но менее хардкорное и менее прозрачное с точки зрения DNS. Насколько быстро в вашем случае обновляется запись? Браузеры честно каждый раз идут к вашему днс серверу смотреть, куда указывает поддомен, или есть нюансы?
Время жизни записи выставлено в 120 с. Теоретически должно обновиться в две минуты, но часто вызывает проблему именно кэш самого dns-клиента на той же windows-машине. DynDNS с этим решили хитро, при установке своего клиента предлагают также использовать свои dns якобы для ускорения. Т.е. если с такой машины выйти в инет, клиент быстро обновится и благодаря прописанным родным dns-серверам мы тоже очень быстро обманемся. Вообще конечно по статистике пока еще рано что-то писать.
freedns.afraid.org/

Надо заходить раз в полгода (иначе приостанавливается) и ограничение 5 доменов на учетную запись.
А так всё хорошо.
Я немного запарился и написал скрипт, отправляющий данные в cloudflare по их api.
Он и понадежнее будет, бесплатный, не упадет если надо, и клиенты не потеряются с адресацией.
Ставим rdns — утилиту управления демоном named.
Помещаем в /etc/namedb/rdnc.conf

Кто-то Вас однозначно за эти ляпы вспомнит «не злым, добрым словом»…

Не забывает chown ddns:ddns /home/ddns/ddns.sh

chmod не менее важен.

В целом статья, как мануал, рассчитана на довольно хорошо подготовленного юниксоида с уклоном во FreeBSD (Вы бы хоть в тегах указали, что статься писана под эту ОС), т.к. опечаток, недосказанностей и явных ляпов в ней, к сожалению, уйма. Т.е. для новичка-копипастера она, как минимум, вредна (в виду явных ошибок и того же копи-паста), а для опытных она как бы не сильно полезна, т.к. задача проста, а статья кишит ошибками.
Уж простите за критику.
Тогда вот еще добавки:
1. В 10-й фре bind убрали из базы -> нужно ставить и конфиги будут, соответственно, в /usr/local/etc
2. Утилита называется rndc, если bind открывает сокет для нее на лупбеке, то файервол для нее трогать ни к чему. Кстати, распространенная ошибка, связанная с ним, заключается в том, что открывают 53 порт только для udp, забыв про tcp.
3. Зачем выполнять команду rndc reload? Для проверки работоспособности лучше подойдет rndc status.
4. В настройках bind'а не замечено allow-update -> nsupdate работать не будет, т.к. динамические обновления отключены по умолчанию.
5. Использовать ключ для rndc в качестве tsig'а — мягко выражаясь, неправильно.
6. В конце концов, зачем писать скрипт на шелле, сомневаюсь, что для пыхи нет какого-нибудь днс модуля, через который можно соорудить дднс без костылей.
1. В статье указано что сабж раворачивается на freebsd 9/3
2. Файервол трогается в принципе чтобы dns-сервер не остался в вакууме и был виден миру, собственно зачем он иначе. Про tcp/udp не указываю, обычно это значит что надо указывать ip в целом.
3. дополнил статью
4. вместо allow-update используется update-policy — в статье указано, вполне себе работает.
5. поясните пожалуйста этот момент.
6. ну это один из вариантов, он изначально вырастал из скрипта, php появился позже. Farcaller выше уже упоминал лишние сущности. Можно конечно поспорить о том что модуль php тоже по своему костыль. Здесь хорошо бы напрямую через exec вызывать nsupdate, но пока крутится и так.
1. Это да, я прочитал, но обновляться-то нужно, не всегда ж на девятке жить, да и базовый bind тоже лучше поменять на какую-нибудь ESV.
3.
шепотом
там ошибочка :)

4. Да, я ее пропустил, пардон.
5. Вы используете один и тот же ключ для аутентификации rndc и для подписи динамических апдейтов, это немножко несекьюрненько. То есть можно сказать «Да что там может случиться? Зачем все усложнять?», но это тот случай, когда проще перебдеть и сделать раздельные ключи, чем думать об этом, когда кто-то скажет: «А давай я буду слать эти апдейты со своего компа?». Кстати, что вы будете делать в этой ситуации?
6. Вот вам в копилочку еще одна слабость вашего скрипта: он позволяет только один апдейт за раз, при том, что даже сама nsupdate умеет менять записи пачками.
1. обновлять конечно надо, вот 11 стабильный выйдет — перееду на 10 ку :)
3. спасибо, забегался с корректировками…
5. понял, про единый ключ размышлял, надо конечно переделать на отдельный ключ для моего сервиса, так конечно будет правильней
6. я не сказал бы что это слабость, все же ориентация скрипта именно такая — что каждому пользователю — один поддомен. Пусть это будет его силой :)
Что помешает клиенту Б изменить зону клиента А? никакой проверки как я понимаю нет, вы удаляете старую запись и добавляете новую.
читайте статью, для изменения нужен логин и пароль
читайте комментарий. я написал клиенту Б изменить зону клиента А. те в случае если у вас пользователей больше чем только вы, то защиты друг от друга никакой не предусмотрено?
У меня есть логин в системе (как пользователь), допустим, тогда я смогу изменить вашу зону (как я понимаю).
каждой зоне соответствуют свои учетные данные, которые прописаны в /usr/local/www/ddns/.htpasswd
т.е.
клиентА парольА
клиентБ парольБ

затем клиентА авторизовавшись — обновляет зону КлиентА.домен.ру, это заложено в скрипте, если он знает учетные данные КлиентаБ, он сможет обновить зону клиентаБ, если он знает пин-код от моей карты, он сможет забрать мои деньги )
Понял. немного тупанул, подумав что авторизуете в домене 2 уровня.
Sign up to leave a comment.

Articles