Объявлено (http://permalink.gmane.org/gmane.network.dns.bind.announce/141) о выходе новой ветки DNS сервера ISC BIND 9.5.0 (http://www.isc.org/sw/bind/view?release=9.5.0). Из новых возможностей можно отметить:
- Поддержка протокола аутентификации GSS-TSIG (RFC 3645 (http://www.ietf.org/rfc/rfc3645.txt) - Generic Security Service Algorithm for Secret Key Transaction);
- Поддержка DHCID (http://www.rfc-editor.org/rfc/rfc4701.txt), способа хранения идентификаторов DHCP клиентов в RR DNS записях;
- Встроенный экспериментальный http сервер для получения статистики в xml формате;
- Накопление более детальной статистики о работе DNS сервера;
- Увеличение производительности при обработке ACL;
- Для генерации внутренней документации использован пакет Doxygen (http://www.stack.nl/~dimitri/doxygen/) (система автодокументирования кода);
- Механизм эффективной чистки LRU кэша (без блокировки);
- Поддержка NSID (RFC 5001 (http://www.ietf.org/rfc/rfc5001.txt)), позволяющая опре...URL: http://permalink.gmane.org/gmane.network.dns.bind.announce/141
Новость: http://www.opennet.ru/opennews/art.shtml?num=16180
Клева... В 1с8 ест ьпочтовый клиент, в опенофис есть почтовый клиент, в винде и прочих ос, есть почтовый клиент... Это есть в оем кпк и мобильной телефоне...В mpd есть вебморда, теперь в named...
Дальше в named будет почтовый клиент верояно?
Поясните: ну почему нельзя следовать единому стандарту, единому софту...
PS: простите за депресняк
PPS: устал мучать зоопарк однообразного функционала...
>В mpd есть вебморда, теперь в named...Ну, тут вы явно преувеличиваете. нэймд просто заимел протокол передачи статистики. И чтобы не городить зоопарк, не стал изобретать велосипед, статистику решил отдавать в XML, а протоколом передачи выбрал гипертекстовый транспортный протокол - всеми понимаемый http, на восьмидесятом порту вероятно. Так что на мой взгляд - это как раз самый что не на есть курс единого стандарта и единого софта.
>Поясните: ну почему нельзя следовать единому стандарту, единому софту...Стандарты все едины. Что значит `следовать единому софту' я не знаю - вероятно это как `отвечать на мой ответ'. Читейте доки, просвещайтесь, пробуйте, и не будет возникать идиотских вопросов.
>[оверквотинг удален]
>оем кпк и мобильной телефоне...
>
>В mpd есть вебморда, теперь в named...
>
>Дальше в named будет почтовый клиент верояно?
>
>Поясните: ну почему нельзя следовать единому стандарту, единому софту...
>
>PS: простите за депресняк
>PPS: устал мучать зоопарк однообразного функционала...Вы видимо о POSIX. Думаю в этом плане можно расслабится, вряд ли они делали свою реализацию, а использовали готовую.
>[оверквотинг удален]
>>
>>Дальше в named будет почтовый клиент верояно?
>>
>>Поясните: ну почему нельзя следовать единому стандарту, единому софту...
>>
>>PS: простите за депресняк
>>PPS: устал мучать зоопарк однообразного функционала...
>
>Вы видимо о POSIX. Думаю в этом плане можно расслабится, вряд ли
>они делали свою реализацию, а использовали готовую.не п....те х...ю, а лучше прочтите http://en.wikipedia.org/wiki/POSIX
> Механизм эффективной чистки LRU кэша (без блокировки);Ну наконецта случилось щастя
Если нужно забирать данные о зонах из mysql базы, подойдет ли bind? Или в таком случае лучше воспользоваться другим сервером?
Нужно воспользоватся мозгом ))
Смысла в хранении зон в mysql никакого нет, только накладные расходы.
>Нужно воспользоватся мозгом ))
>Смысла в хранении зон в mysql никакого нет, только накладные расходы.Весьма даже есть =)
Приверженцы бинда всегда так говорят... печальноВ качестве альтернативы с БД можно использовать простой mydns(как мускулы, так и постгрес) или же powerDNS(и с ораклем умеет общаться), есть патчи под djbdns, дающие поддержку постгреса.
>Весьма даже есть =)Я весь во внимании слушаю :)
Зона в работающем DNS сервере ДОЛЖНА располагатся в оперативной памяти. Если на каждый запрос будет дёргаться реляционная СУБД - DNS умрёт на очень слабой нагрузке.
Использовать же СУБД как зранилище зоны на время выключения сервера (для однократной загрузки при запуске) - НИЧЕМ не лучше файла.
>>Весьма даже есть =)
>
>Я весь во внимании слушаю :)
>
>Зона в работающем DNS сервере ДОЛЖНА располагатся в оперативной памяти. Если на
>каждый запрос будет дёргаться реляционная СУБД - DNS умрёт на очень
>слабой нагрузке.
>
>Использовать же СУБД как зранилище зоны на время выключения сервера (для однократной
>загрузки при запуске) - НИЧЕМ не лучше файла.непрошибаемая логика =))
Сперва почитали бы как устроены эти демоны.Не правда ли, логичнее предположить, что разработчики не подкладывали себе свинью, а сделали кеш, в котором хранятся зоны, который обновляется тогда, когда есть новые данные в бд?
> Не правда ли, логичнее предположить, что разработчики не подкладывали себе свинью, а сделали кеш, в котором хранятся зоны, который обновляется тогда, когда есть новые данные в бд?Это именно тот случай, когда СУБД используется для хранения данных, загружаемых при старте DNS. Правда грузится не всё сразу, а размазанно, по требованию (ещё не факт что это эффективней).
Я слушаю ответ, где же смысл усложнения? Запуск СУБД, инвалидация кеша, ради чего эти выкрутасы?
>> Не правда ли, логичнее предположить, что разработчики не подкладывали себе свинью, а сделали кеш, в котором хранятся зоны, который обновляется тогда, когда есть новые данные в бд?
>
>Это именно тот случай, когда СУБД используется для хранения данных, загружаемых при
>старте DNS. Правда грузится не всё сразу, а размазанно, по требованию
>(ещё не факт что это эффективней).
>
>Я слушаю ответ, где же смысл усложнения? Запуск СУБД, инвалидация кеша,
>ради чего эти выкрутасы?А если подумать?Хранить всё в одном месте и в удобном виде, с лёгким доступом и изменением - думаю, ради этого.
>А если подумать?Хранить всё в одном месте и в удобном виде, с лёгким доступом и изменением - думаю, ради этого.Я-то подумал. И мне не понятно концепция "одного места". Почему если СУБД это одно место, то файловая система это не "одно место"? Как раз одно место это dns сервер, а тут вводится БЕСПОЛЕЗНАЯ СУБД.
Лёгкий доступ? Да dns сервер создан для того чтобы раздавать эти даные, почему бы не получать их у него самого? Зачем нужно лезть напрямую в хранилище, и ради этого делать хранилище способным ослуживать параллельно клиентов, утяжеляя и тормозя работу?
Лёгкое изменение? BIND ПОЗВОЛЯЕТ лёгкое изменение, называется динамические обновления, надёжно, безопасно(гибкий контроль доступа, цифровые подписи) и ЭФФЕКТИВНО.
Так что это вы лучше подумайте...
>[оверквотинг удален]
>
>Лёгкий доступ? Да dns сервер создан для того чтобы раздавать эти даные,
>почему бы не получать их у него самого? Зачем нужно лезть
>напрямую в хранилище, и ради этого делать хранилище способным ослуживать параллельно
>клиентов, утяжеляя и тормозя работу?
>
>Лёгкое изменение? BIND ПОЗВОЛЯЕТ лёгкое изменение, называется динамические обновления, надёжно, безопасно(гибкий контроль
>доступа, цифровые подписи) и ЭФФЕКТИВНО.
>
>Так что это вы лучше подумайте...И как на нем это сделать удаленно? :) руками и скриптами да, делается, но та же лишняя прослойка.
>В качестве альтернативы с БД можно использовать простой mydns(как мускулы, так и
>постгрес) или же powerDNS(и с ораклем умеет общаться), есть патчи под
>djbdns, дающие поддержку постгреса.Спасибо. Я планирую попробовать их. Говорят что mydns медленно работает при большом количестве зон и не поддерживается разработчиками.
Недавно видел его форк.
в журнале "системный администратор" была тема про mydns и балансировщик циски.
Плохих отзывов не слышал, покажи где есть данный по этой теме.
>Нужно воспользоватся мозгом ))
>Смысла в хранении зон в mysql никакого нет, только накладные расходы.смысл в том чтобы из софта рулить базой доменов.
>смысл в том чтобы из софта рулить базой доменов.Передеди на русский?
Можно конечно реализовать возможность редактирования зоны на низком уровне, обеспечив возможность прямого изменения хранилища другими программами.
Но это не не эффективно. Такие хранилища намного медленнее оперативной памяти.bind умеет менять данные быстро в памяти, сохраняя, по необходимести, изменения на диск.
>Нужно воспользоватся мозгом ))+1
В иных случаях рекомендуется пользоваться MS DNS Server. Там как угодно можно рулять. Даже из софта!!! ;-)
Bind умеет хранить зоны в LDAP, в чём проблема, если нужно рулить зонами, то храните их в LDAP...:)
http://www.freebsd.org/cgi/url.cgi?ports/dns/bind9-dlz/pkg-d...BIND version 9 Nameserver, with DLZ extensions
Add capabilities to Bind 9 that will allow Bind backend databases to support
adding and removing zones without interrupting normal server operation.WWW: http://bind-dlz.sourceforge.net/
"without interrupting normal server operation" -- может именно эта фраза является причиной того, чтоб хранить зоны в БД?
Чтоб зону добавить, надо сделать серверу reload.
Если там пару тысяч зон -- интересно, сколько времени этот reload будет происходить?
Этот функционал наверное нужен тем, кто делает веб-морды для клиентов, которые покупают домены и рулят ими сами... для хостеров всяких...
я так думаю...
> "without interrupting normal server operation" — может именно эта фраза является причиной того, чтоб хранить зоны в БД?У меня bind и так умеет добавлять новые зоны без перезапуска и загрузки старых.
rndc reconfigЭто функционал DNS сервера - обеспечить добавление и удаление зон без остановки сервиса. Самый глупый и не рациональный способ - поместить все данные в СУБД, и заставить её делать работу DNS сервера, принимая запросы и отвечая через DNS frontend.
>У меня bind и так умеет добавлять новые зоны без перезапуска и
>загрузки старых.
>rndc reconfig
>
>Это функционал DNS сервера - обеспечить добавление и удаление зон без остановки
>сервиса. Самый глупый и не рациональный способ - поместить все данные
>в СУБД, и заставить её делать работу DNS сервера, принимая запросы
>и отвечая через DNS frontend.Для добавления зон в bind нужнно поменять конфиг сервера и создать файл зоны. При этом конфиг мастера и слэйва отличается. После rndc reconfig добавит эту зону в кэш сервера.
Как добавить зону удаленно?
>Как добавить зону удаленно?Удалённо поменять конфиг сервера ))
Ничем не отличается от "удалённой смены данных в СУБД". Так же легко автоматизируется, доступны те же интерфейсы.
>>Как добавить зону удаленно?
>
>Удалённо поменять конфиг сервера ))
>
>Ничем не отличается от "удалённой смены данных в СУБД". Так же легко
>автоматизируется, доступны те же интерфейсы.А как быть тем, кто продаёт домены и хостинг веба и почты?
Как приделать веб-морду к бинду, чтоб клиенты сами могли там чёто менять?
Как быть с распределением прав на редактирование файлов?
Да ещё чтоб команда давалась rndc reconfig -- об этом тоже как-то надо позаботиться.
А так -- дал доступ к определённым элементам в базе -- и привет.
Хотя я не отрицаю, что можно как-то и без базы, но это надо уже быть "более опытным"
:-)
>Хотя я не отрицаю, что можно как-то и без базы, но это надо уже быть "более опытным":-)
Совсем без базы не обязательно. Главное чтобы bind работал без базы.
Можно скрипт периодический сделать, гененирующий включаемую часть конфига bind (с перечислением зон) данными из базы и перезагружающий его, если были изменения.
Ну а модификацию самих зон разумеется реализовать по протоколу динамических обновлений.
>>Хотя я не отрицаю, что можно как-то и без базы, но это надо уже быть "более опытным"
>
>:-)
>
>Совсем без базы не обязательно. Главное чтобы bind работал без базы.
>
>Можно скрипт периодический сделать, гененирующий включаемую часть конфига bind (с перечислением зон)
>данными из базы и перезагружающий его, если были изменения.
>
>Ну а модификацию самих зон разумеется реализовать по протоколу динамических обновлений.Попробуйте посмотреть на это с точки зрения больших масштабов.
БД решает многие проблемы, всплывающие у профессиональных dns хостерах.
Которуе держат, скажем, 100 000 зон.Здесь куда проще держать все в БД, которая обеспечит целостность данных, стабильность и быстроту доступа к ним.
Плюс безопасность (разграничение доступа), плюс легкость бекапов, плюс легкость получения любой статистики (sql запросами - самое то).Ну а для dns сервера с десятком зон, это естественно не нужно.