Консорциум ISC после четырёх лет разработки представил (https://lists.isc.org/pipermail/bind10-users/2013-February/0...) первый стабильный выпуск DNS-сервера BIND 10 (http://bind10.isc.org), отличающегося кардинальной переработкой внутренней архитектуры. В отличие от ранее практикуемой модели реализации всей доступной функциональности в одном серверном процессе, в BIND 10 осуществлён переход к разделению функций по отдельным взаимосвязанным процессам, каждый из которых реализует свой сервис. Разделение по разным процессам позволило рационально использовать ресурсы многоядерных систем, расширило возможности масштабирования, обеспечило изоляцию отдельных функций и повысило надёжность.
Ключевые особенности BIND 10:
- Интеграция функций DHCP-сервера. В процессе развития продукта ISC DHCP разработчики столкнулись с необходимостью существенной переработки реализации DHCP-сервера, при этом основные мотивы и цели примерно совпадали с мотивами и целями разработчиков, взявшихся переписать BIND. С учётом того, что во многих ситуациях требуется обеспечение тесного взаимодействия DHCP и DNS-серверов, например, типичной является задачи синхронизации имен хостов и выделяемых через DHCP IP-адресов, разработчики решили объединить функции DNS и DHCP в рамках единого продукта;- Вынос в независимые модули таких компонентов, как резолвер, подсистема для хранения данных, система обслуживания DNS-зон, авторитативный DNS-сервер, динамический DNS-сервер, сервисы перенаправления запросов (forwarder), система накопления статистики, менеджер конфигурации, интерфейс для удалённого управления работой;
- Увеличение надежности, повышение стойкости к DoS атакам и способность работать до последнего, игнорируя возникающие ошибки (например, некорректные записи в DNS зонах);
- Поддержка акселерации выполнения запросов через схему бэкенд-фронтенд;- Не привязанность к конкретной модели хранения данных, подключение обработчиков хранилищ через модули. Включение в комплект модулей для хранения зоны в SQL базе, кеширования в памяти из файлов или использования встраиваемых БД;
- Возможность определять в процессе сборки, на основе каких частей будет сформирована бинарная сборка. Например, может быть собран только кеширующий или только авторитативный сервер, что позволит создавать компактные версии bind, подходящие для использования во встраиваемых устройствах с ограниченными ресурсами;
- Поддержка кластеризации: интеграция технологий, позволяющих организовать работу как единого целого нескольких копий BIND, размещенных на разных серверах;
- Средства для интеграции BIND в программную инфраструктуру пользователя. Если в BIND 9 базовая конфигурация оформлялась в текстовых файлах, то в BIND 10 добавлены специальные программные интерфейсы для управления конфигурацией и мониторинга BIND из сторонних приложений;
- Контроль в процессе выполнения. Реконфигурация BIND 9 производилась исключительно через чтение файлов и примитивные rndc команды. В BIND 10 реализована более изящная и интерактивная схему контроля и мониторинга. Например, обеспечена поддержка автоматического перезапуска компонентов в случае сбоя, без влияния на другие части системы. Представлены средства для изменения конфигурации и управления работой сервера на лету, без остановки и перезапуска;
- Специальный API (http://bind10.isc.org/wiki/NameClassDesign) и набор библиотек для интеграции функций для работы с DNS и средств для взаимодействия с DNS-сервером в сторонние приложения. Для разработки дополнений и новых модулей подготовлены C++ библиотека libdns++ и Python-биндинг.Из поддерживаемых в BIND10 1.0.0 функций отмечается поддержка передачи и приёма зон (IXFR и AXFR), бэкенд для хранения (кэширования) параметров зон в памяти с целью ускорения их отдачи, бэкенд для хранения параметров зон в БД SQLite3, реализация протокола DNSSEC для отдачи подписанных зон, реализация DDNS (Dynamic Updates), поддержка списков контроля доступа, поддержка TSIG для верификации DNS-сообщений и передаваемых зон. Подробные руководства по настройке и использованию BIND 10 можно найти на данной странице (http://bind10.isc.org/docs/).
Ключевым звеном BIND 10 является процесс msgq, используемый для организации обмена сообщениями между модулями. Функции авторитетного DNS-сервера выполняет модуль auth, а функциональность DHCP обеспечивается модулями dhcp4 и dhcp6. Модули auth, dhcp4 и dhcp6 для увеличения масштабируемости и балансировки нагрузки могут запускаться в нескольких экземплярах, например, для каждого CPU на сервере может быть запущена отдельная копия модуля auth, а запросы на 53 порт могут равномерно распределяться между процессами. Для обслуживания входящих и исходящих AXFR-запросов (трансфер зон целиком) представлены отдельные сервисы xfrin и xfrout. Функции динамического DNS-сервера выполняет модуль ddns, а управление зонами делегированы модулю zonemgr.
Для организации удаленного управления DNS-сервером подготовлен модуль cmdctl, поверх которого подготовлено несколько надстроек для управления конфигурацией, таких как утилита bindctl, web-интерфейс WebTool, GUI-интерфейс GuiTool и утилита для обеспечения совместимости с конфигуратором BIND9. Для разбора и хранения конфигурации задействован модуль cfgmgr. Для управления сервером и изменения конфигурации может использоваться RESTful-интерфейс, работающий поверх HTTPS. Отдельный интерес представляет модуль накопления статистики, который в сочетании с дополнительными надстройками может отдавать статистику по протоколам HTTP (в XML-представлении) или SNMP.<center><a href="http://bind10.isc.org/attachment/wiki/DesignDiagrams/Overvie... src="https://www.opennet.ru/opennews/pics_base/0_1361898271.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
<center><a href="http://bind10.isc.org/raw-attachment/wiki/DesignDiagrams/Ove... src="https://www.opennet.ru/opennews/pics_base/0_1361898295.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center><center><a href="http://bind10.isc.org/raw-attachment/wiki/DesignDiagrams/Ove... src="https://www.opennet.ru/opennews/pics_base/0_1361898323.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
URL: https://lists.isc.org/pipermail/bind10-users/2013-February/0...
Новость: https://www.opennet.ru/opennews/art.shtml?num=36235
>работать до последнего, игнорируя возникающие ошибки (например, некорректные записи в DNS зонахЧтобы их никто и не думал исправлять.
Хостеры и регистраторы с тысячами доменов были бы благодарны за такое "новшество".
Ошибки нормально ловятся при проблемах с конкретным доменом или из логов.
> С учётом того, что во многих ситуациях требуется обеспечение тесного взаимодействия DHCP и DNS-серверов, например, типичной является задача синхронизации имен хостов и выделяемых через DHCP IP-адресов, разработчики решили объединить функции DNS и DHCP в рамках единого продукта;Что-то ни слова про bootp/pxe.
А в остальном, конечно, круто, наверное.
В отличие от tftp/bootp между dhcp и dns есть вполне себе прямая связь, когда аренды первого нужно автоматически отображать в зоне второго, поэтому и есть смысл держать это в одном флаконе.
> когда аренды первого нужно автоматически отображать в зоне второгоА есть ещё хоть одна причина, кроме этой?
Для данной связи достаточно внести немного функционала в код isc-dhcp, чтобы он умел отправлять запрос на dns сервер.
И dns сервер - это не всегда bind.
А если у меня powerdns какой-нибудь?
Больше биндов, хороших и разных... чот про нсд ничего не слышно...
Хотел посмотреть что с opt82 здесь:
http://bind10.isc.org/docs/manuals/b10-dhcp4.8.html
смутил первая же строчка в описании:
=================
DESCRIPTIONThe b10-dhcp4 daemon will provide the DHCPv4 server implementation when it becomes functional.
=================
Чёй-то в последнее время, всех беспокоит opt82. Чем она так интересна?
ну наверно тем что с ее помощью часто реализуют ipoe
> ну наверно тем что с ее помощью часто реализуют ipoeТут сидит куча провайдеров?
В принципе для юзеров, да и для админов это удобно,
но безопасность проседает на порядок!
>> ну наверно тем что с ее помощью часто реализуют ipoe
> Тут сидит куча провайдеров?
> В принципе для юзеров, да и для админов это удобно,
> но безопасность проседает на порядок!ну я с провайдера )
а какая связь между opt 82 и безопасностью?
> ну я с провайдера )
> а какая связь между opt 82 и безопасностью?Спуфить сложно. А без спуфинга сразу видно кто злодей.
Если оборудование понимает opt82 то с безопасностью проблем нет. Знаешь что и откуда пришло, на оборудовании доступа автоматом выставляется ACL, которая разрешает ходить только тому трафику который выдал DHCP сервер.. не вижу вообще проблем безопасности, только удобство для всех.
чем наличие опции82 снижает безопасность в сравнении с ее отсутствием?
Все начитались эту статью, вестимо, хотя MiM-атака подходит почти к любому варианту авторизации.
> Все начитались эту статью, вестимо, хотя MiM-атака подходит почти к любому варианту
> авторизации.Ссылка не прилепилась, статья "Проблема IPoE" на хабре имелась ввиду
> Тут сидит куча провайдеров?
> В принципе для юзеров, да и для админов это удобно, но безопасность проседает на порядок!А True Admin'ы на своих сетях не используют свитчинг уровня выше второго?
>> Тут сидит куча провайдеров?
>> В принципе для юзеров, да и для админов это удобно, но безопасность проседает на порядок!
> А True Admin'ы на своих сетях не используют свитчинг уровня выше второго?А ты в курсях, сколь стоит свитч уровня 3?
>> А True Admin'ы на своих сетях не используют свитчинг уровня выше второго?
> А ты в курсях, сколь стоит свитч уровня 3?Копейки. Сейчас 2013 год, а не 2003.
>А ты в курсях, сколь стоит свитч уровня 3?от 10 тыс. руб. Например D-Link DES-3810-28.
А вообще железки с ipoe от 1000 руб, например mikrotik 750rb.
чтоб тебе в инет через такое L3 выходить...
нормальное L3 стоит других денег!
Я тут сижу.>безопасность проседает на порядок!
Каким образом?
Нам, например, option82 интересна тем, что позволяет выдавать юзверю IP динамически (с точки зрения юзверя) не нарушая нашу схему VLAN per user, при которой в принципе невозможна подмена IP. В данном случае - никаких проблем с безопасностью лично я не вижу.
> Нам, например, option82 интересна тем, что позволяет выдавать юзверю IP динамически (с
> точки зрения юзверя) не нарушая нашу схему VLAN per user, при
> которой в принципе невозможна подмена IP. В данном случае - никаких
> проблем с безопасностью лично я не вижу.при этом вы делаете mac-port-ip биндинг?
> при этом вы делаете mac-port-ip биндинг?Не так. Никаких привязок МАКов. На порт L2-свича вешается VLAN. На терминирующем L3 устройстве (циски) настроен роутинг IP-VLAN. Все. Если пользователь выставит ДРУГОЙ ИП - он просто никуда не попадет.
>> при этом вы делаете mac-port-ip биндинг?
> Не так. Никаких привязок МАКов. На порт L2-свича вешается VLAN. На
> терминирующем L3 устройстве (циски) настроен роутинг IP-VLAN. Все. Если пользователь выставит
> ДРУГОЙ ИП - он просто никуда не попадет./30 сеть на юзера?
или аннамберед?
> /30 сеть на юзера?
> или аннамберед?Второе. :) Вот в данной ситуации Option82 как раз еще больше упростила бы работу пользователей в сети. В том плане, что вообще исключалась бы ручная работа юзверя. Воткнул сетевой кабель - получил IP. А вот ручной работы (которой сейчас тоже хватает, базу VLAN тоже надо вести) станет больше, это да.
Например, тем, что с её помощью можно иметь один DHCP-сервер на несколько broadcast-isolated (как вариант -- свитчами третьего уровня) сегментов.
> Например, тем, что с её помощью можно иметь один DHCP-сервер на несколько
> broadcast-isolated (как вариант -- свитчами третьего уровня) сегментов.Это можно сделать и без опции, просто протащив вилан до акцесса.
И где тут свитчинг 3'го уровня тогда?
> Например, тем, что с её помощью можно иметь один DHCP-сервер на несколько
> broadcast-isolated (как вариант -- свитчами третьего уровня) сегментов.
> http://ru.wikipedia.org/wiki/DHCP_relayНе путайте "dhcp relay" и "опцию 82". Опция 82 не всегда нужна. Dhcp relay может запросто работать без нее.
как геоднс без патчей сможет десятая версия работать?
как оно по скорости по сравнению с unbound?
А ты сперва научи процессы unbound'а юзать один на всех кеш запросов. Вот тогда можно будет хоть как-то начинать сравнивать.
Бернштейн победил!
Я тоже подумал о qmail когда увидел новую архитектуру.
Ну, хоть кто-то задумывается о модульности и настраиваемости.
Что не домон, то со своим веб-сервером.
Остались только граб и уефи.
> Что не домон, то со своим веб-сервером.
> Остались только граб и уефи.Ничего, скоро красношапковский Гаррипоттер и их в свое сыстемд перетащит, а там веб-сервер уже есть :(
Хочешь поговорить об этом? Ну тогда расскажи чем же это плохо
Тут он гвоздями не прибит, данные получаются из message bus, так что все OK.
> объединить функции DNS и DHCP в рамках единого продуктаГуд!
> msgqПочему не D-Bus?
>> msgq
> Почему не D-Bus?Потому что не systemd!!!
