The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

05.10.2016 11:25  Релиз DNS-сервера BIND 9.11, перешедшего на новую лицензию

После двух с половиной лет разработки консорциум ISC представил первый стабильный релиз новой значительной ветки DNS-сервера BIND 9.11. Разработчики рекомендуют повременить с внедрением BIND 9.11 в промышленную эксплуатацию до первого корректирующего выпуска. Поддержка веток 9.9 и 9.10 сохраняется, например, обновления для BIND 9.9 будут выпускаться как минимум до конца 2017 года.

Ветка BIND 9.11 примечательна перелицензированием кодовой базы. Отныне код проекта распространяется под лицензией MPL 2.0 (Mozilla Public License), которая пришла на смену пермиссивной открытой лицензии ISC, созданной более 20 лет назад и являющейся аналогом 2-пунктовой лицензии BSD. Лицензия MPLv2 относится к категории слабого копилефта и требует открывать все внесённые в проект изменения, в то время как лицензия ISC предоставляла полную свободу по использованию кода в своих целях. При использовании MPL изменения требуется открывать только при поставке продукта, содержащего модифицированную версию кода. Для внутреннего использования изменения могут вноситься без их публикации. Лицензия MPL совместима с лицензиями GPLv2 и Apache, и выбрана проектом BIND как разумный компромисс между разрешительной лицензией ISC и жестким копилефтом GPL.

Ключевые новшества BIND 9.11.0:

  • Представлен каталог зон ("Catalog Zones") - новый экспериментальный метод поддержания вторичных DNS-серверов. Суть метода в том, что вместо определения на вторичном сервере отдельных записей для каждой вторичной зоны, между первичным и вторичным серверами организуется передача каталога зон. Т.е. настроив трансфер каталога по аналогии с передачей отдельных зон, заводимые на первичном сервере зоны, помеченные как входящие в каталог, будут автоматически создаваться на вторичном сервере без необходимости правки файлов конфигурации (аналогично со вторичного сервера будут удаляться зоны, удалённые на первичном сервере). Сам по себе каталог зон оформляется в виде обычной зоны DNS, включающей список зон с настройками для каждой зоны, что позволяет применять штатные механизмы AXFR/IXFR для информирования другого сервера о наличии обновлений;
  • Реализован интерфейс DynDB (Dynamic Database), позволяющий организовать загрузку зон из внешних баз данных. DynDB выступает в роли альтернативы технологии BIND DLZ (Dynamically-loaded zones), но работает значительно быстрее и поддерживает расширенные возможности. DynDB позволяет создавать модули, которые загружают данных из внешних источников и позволяют работать с ними с той же производительностью и теми же возможностями, как при использовании обычных зон. Например, новый интерфейс задействован в модуле bind-dyndb-ldap, который может применяться для хранения зон в LDAP;
  • Добавлен Dnstap, новый быстрый и гибкий метод для захвата и журналирования трафика DNS. Dnstap позволяет организовать ведение лога как поступающих запросов, так и генерируемых сервером ответов. В отличие от штатных средств ведения логов BIND, новый метод не влияет на производительность и пропускную способность сервера. Собранные данные могут записываться в файл или передаваться другому приложению через unix-сокет. Поддерживается автоматическая ротация файлов с логами. Для приведения логов к читаемому виду предлагается утилита dnstap-read;
  • Включена по умолчанию поддержка DNS Cookies (RFC 7873). Обмен cookie между сервером и клиентом позволяет идентифицировать корректность IP-адреса и защитить сервер и клиента от спуфинга IP-адресов. Управление производится директивами require-server-cookie и send-cookie, для совместного использования ключа для cookie на нескольких серверах можно использовать директиву cookie-secret;
  • Команда "rndc delzone" теперь может применяться к зонам, настройки которых заданы в файле named.conf, а не только к зонам добавленным через команду "rndc addzone" (при этом настройки автоматически не удаляются из named.conf, что требует ручного вмешательства, иначе настройки вернуться после перезапуска named);
  • Возможность сохранения конфигурации зон, добавленных командой "rndc addzone" не в текстом файле, а в БД lmdb (Lightning Memory-Mapped Database). При использовании БД lmdb значительно возростает производительность операций "rndc delzone" и "rndc modzone", так как изменение базы в формате ключ/значение производится значительное быстрее чем переписывание текстового файла;
  • Команда "rndc modzone" теперь может использоваться для перенастройки зон, используя синтаксис, похожий на команду "rndc addzone";
  • В RNDC обеспечена возможность подключения обработчиков на языке Python. Функциональность реализована через модуль isc.rndc, позволяющий отправлять команды rndc из программ на языке Python;
  • Добавлена команда "rndc nta", позволяющая выставлять метки NTA (Negative Trust Anchors) для резолвера, отключающие проверку по DNSSEC для выбранных доменов. Подобная возможность может потребоваться для временного отключения DNSSEC для доменов, у которых возникли проблемы с настройками (например, просрочен сертификат). По умолчанию время действия метки - 1 час, максимальное время - 1 неделя;
  • Добавлена опция "minimal-any", при установке которой сервер генерирует ответ минимального размера на запросы ANY, которые при обычных условиях приводят к отправке большой порции данных и могут быть использованы для совершения атак. При установке опции "minimal-any" возвращается только одна произвольно выбранная запись RR, вместо вывода всех соответствующих запросу записей;
  • Добавлена новая утилита dnssec-keymgr (DNSSEC Key Manager), предоставляющая средства для автоматизации операций с ключами DNSSEC. Dnssec-keymgr может запускаться через cron и на основании заданных политик /etc/dnssec.policy создавать и обновлять ключи DNSSEC. При изменении политики ключи автоматически перестраиваются для соответствия новым правилам;
  • Добавлена новая утилита mdig, которая является вариантом утилиты dig, поддерживающим одновременную отправку нескольких запросов вместо отправки запросов один за другим;
  • В утилиту dig добавлена порция новых опций:
    • "dig +ednsopt" - выставляет произвольные опции EDNS для отправляемого запроса;
    • "dig +ednsflags" - выставляет определённые флаги EDNS для отправляемого запроса;
    • "dig +[no]ednsnegotiation" - включает/выключает согласование версий EDNS;
    • "dig +header-only" - отправляет запросы без вывода дополнительных секций;
    • "dig +ttlunits" - отображает значения TTL с суффиксами w, d, h, m, s для недель, дней, часов, минут и секунд;
    • "dig +zflag" - выставляет последний неназначенный битовый флаг в заголовке запроса DNS;
    • "dig +dscp=value" - устанавливает значение DSCP для исходящих пакетов;
    • "dig +mapped" - определяет использование маппинга адресов IPv4.


  1. Главная ссылка к новости (https://lists.isc.org/pipermai...)
  2. OpenNews: Утверждён переход DNS-сервера BIND на лицензию MPLv2
  3. OpenNews: Выпуск DNS-сервера BIND 9.10.4 и 9.9.9
  4. OpenNews: Сайт консорциума ISC, развивающего BIND и DHCP, подвергся взлому
  5. OpenNews: Релиз DNS-сервера BIND 9.10
  6. OpenNews: Выпуск DNS-сервера BIND 10 1.2.0 ознаменовал передачу проекта сообществу
Лицензия: CC-BY
Тип: Программы
Ключевые слова: dns, bind, named
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Линейный вид | Ajax | Показать все | RSS
 
  • 1.1, Аноним, 12:17, 05/10/2016 [ответить] [смотреть все]
  • +8 +/
    Новая лицензия это всегда так волнующе!
     
  • 1.2, Vee Nee, 12:25, 05/10/2016 [ответить] [смотреть все]
  • +1 +/
    Каталог зон, судя по всему, что-то вроде механизма SuperMaster в PowerDNS. Отлично просто!
     
     
  • 2.4, ., 13:31, 05/10/2016 [^] [ответить] [смотреть все]
  • +/
    сы одной стороны - оно, конечно, замычательно, что не прошло и пятнадцати лет, как появилась надежда избавиться от scp для раздачи слейвам списков того что им слейвить.
    Сы другой стороны - не открыть ли тотализатор на тему сколько remote shell, ddos, а то и root дыр обнаружится в этом месте?

     
     
  • 3.16, Аноним, 01:45, 10/10/2016 [^] [ответить] [смотреть все]
  • +/
    Лучше открыть перепись людей, разрешающих управление своим DNS с публичных интер... весь текст скрыт [показать]
     
  • 2.5, rt, 14:03, 05/10/2016 [^] [ответить] [смотреть все]  
  • +/
    Какие проблемы это решает?
     
     
  • 3.7, Денис, 14:59, 05/10/2016 [^] [ответить] [смотреть все]  
  • +1 +/
    Руками каждую slave не добавлять/удалять.
    Конфиг на slave пухнуть не будет.
     
  • 3.15, Аноним, 01:42, 10/10/2016 [^] [ответить] [смотреть все]  
  • +/
    Если ты спрашиваешь, то для тебя — никакие.
     
  • 2.11, rvs2016, 09:08, 06/10/2016 [^] [ответить] [смотреть все]  
  • +/
    А если на разные вторичные сервера надо передавать разные наборы зон, которые частично пересекаются? Тогда надо вытаскивать бубен? :-)
     
     
  • 3.17, Аноним, 01:56, 10/10/2016 [^] [ответить] [смотреть все]  
  • +/
    А если почитать документацию не задавать глупые вопросы ... весь текст скрыт [показать]
     
  • 1.3, Ph0zzy, 12:46, 05/10/2016 [ответить] [смотреть все]  
  • +/
    а как же Bundy?
     
     
  • 2.6, Stax, 14:10, 05/10/2016 [^] [ответить] [смотреть все]  
  • +4 +/
    Общественность пока дозревает до него. Она еще морально не готова к интеграции DNS с DHCP и питону в DNS-сервере..

    Хотя такая интеграция была бы очень полезна. Текущими средствами, к примеру, до сих пор нормально не решить регистрацию ipv4 и ipv6 адресов (выданных dhcpv4 и dhcpv6 соответственно) на одно имя :( Кривые хаки только.

     
     
  • 3.8, glebiao, 16:26, 05/10/2016 [^] [ответить] [смотреть все]  
  • +/
    >Текущими средствами, к примеру, до сих пор нормально не решить регистрацию ipv4 и ipv6

    dnsmasq.Всё штатно.

     
     
  • 4.9, Stax, 20:10, 05/10/2016 [^] [ответить] [смотреть все]  
  • +4 +/
    Так там интегрировано! Понятно, что на интегрированном можно сделать так, чтобы работало, у них же есть возможность обмениваться данными друг с другом. Проблема есть, когда dhcpv4 и dhcpv6 это разные сервисы и взаимодействовать друг с другом они могут только косвенно, читая и записывая записи в dns.

    В любом случае, не менять же bind на dnsmasq только потому, что там интегрировано.. Бывает, нужны фичи ICS'шных dhcp, которые фиг найдешь где-либо еще - или фиг поймешь, как сделать.

    В общем, надо переходить на технологии bind 10, но что-то общественность побаивается.

     
  • 1.10, rvs2016, 09:04, 06/10/2016 [ответить] [смотреть все]  
  • +/
    > Команда "rndc delzone" теперь может применяться к зонам,
    > настройки которых заданы в файле named.conf

    Если этой командой удалить зону на вторичном сервере, то он перекачает её заново с первичного сервера? Это получается вместо rndc reload? Или вторичный сервер удалённую зону перекачает с первичного только после своего рестарта?

     
     
  • 2.12, ойноним, 09:35, 06/10/2016 [^] [ответить] [смотреть все]  
  • +/
    Только после рестарта вторички.
     
  • 1.13, Аноним, 12:39, 06/10/2016 [ответить] [смотреть все]  
  • +/
    Из серии девушка наполовину беременна ... весь текст скрыт [показать]
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor